p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

CPColin: Sep 9, 2003; Big ol' smile.

comedyblissoption posted:

a golang enthusiast wrote a very detailed article about why you should basically never use go channels lol
https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/

Go is so bad, my work refuses to let me connect to that domain, for security reasons!

# ? Apr 3, 2018 22:56

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 12:13

pseudorandom name: May 6, 2007

rjmccall posted:

in what sense exactly does go, a language with a segregated threading model and a gc, not have a runtime

it has static linking

# ? Apr 3, 2018 23:02

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

Sapozhnik posted:

batteries included stdlibs are bad.

there are very very few things that belong in an stdlib instead of a community package manager.

it's because go is too broken to implement basic features, so they have to be implemented in the standard lib where they can do things the plebs can't like overload make and range, create generic containers, and use operators.

see the section "Third-party libraries are second-class citizens" here http://sitr.us/2017/02/21/changes-i-would-make-to-go.html

# ? Apr 3, 2018 23:10

homercles: Feb 14, 2010

Sapozhnik posted:

batteries included stdlibs are bad.

there are very very few things that belong in an stdlib instead of a community package manager.

an opinion from 1970

# ? Apr 3, 2018 23:11

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

they had community package managers in the 70s?

# ? Apr 3, 2018 23:15

homercles: Feb 14, 2010

HappyHippo posted:

it's because go is too broken to implement basic features, so they have to be implemented in the standard lib where they can do things the plebs can't like overload make and range, create generic containers, and use operators.

see the section "Third-party libraries are second-class citizens" here http://sitr.us/2017/02/21/changes-i-would-make-to-go.html

That's not the stdlib, that's the core language. A first class citizen of the language is not something that can be written in that language (at least, not in Go).

# ? Apr 3, 2018 23:19

homercles: Feb 14, 2010

HappyHippo posted:

they had community package managers in the 70s?

Should net/http be removed and instead be implemented as a third party import from github.com/jrandomfuckwit/myhttpimpl ?

Get those common cases into the standard library and let the titans of the industry do it right. Batteries included is the way to go.

# ? Apr 3, 2018 23:22

MononcQc: May 29, 2007

homercles posted:

Should net/http be removed and instead be implemented as a third party import from github.com/jrandomfuckwit/myhttpimpl ?

only if you don't have good third party imports

# ? Apr 3, 2018 23:34

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

homercles posted:

Should net/http be removed and instead be implemented as a third party import from github.com/jrandomfuckwit/myhttpimpl ?

considering how much net/http breaks basic http poo poo, yes, probably

# ? Apr 3, 2018 23:42

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

practical example i have run into "irl": go's http server has opinions about slashes in URLs. this breaks proxies: https://github.com/bitly/oauth2_proxy/issues/179

# ? Apr 3, 2018 23:45

homercles: Feb 14, 2010

hmmm. ambiguous edge cases.

homercles fucked around with this message at 23:54 on Apr 3, 2018

# ? Apr 3, 2018 23:50

DELETE CASCADE: Oct 25, 2017; i haven't washed my penis since i jerked it to a phtotograph of george w. bush in 2003

pseudorandom name posted:

it has static linking

so does java if i give you a jar file :shrug:

# ? Apr 4, 2018 00:21

pseudorandom name: May 6, 2007

DELETE CASCADE posted:

so does java if i give you a jar file

except for requiring, you know, java

# ? Apr 4, 2018 00:28

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

"C doesn't have a runtime! Nevermind that DLL file that stands for 'C runtime'"

# ? Apr 4, 2018 00:40

tef: May 30, 2004; -> some l-system crap ->

btw did you see that go-routines are getting *cough* full preemption

# ? Apr 4, 2018 01:26

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

why would anyone who's not writing like a kernel or a bootloader care about static linking

and why would you talk about it like it's some sort of impressive hack instead of just not running the extra linker command to turn a .a into a shared library

# ? Apr 4, 2018 01:30

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

tef posted:

btw did you see that go-routines are getting *cough* full preemption

what not even cooperative "preemption", like actual no-such-thing-as-a-critical-section preemption

that's really not a good idea for a gc language

# ? Apr 4, 2018 01:31

akadajet: Sep 14, 2003

rjmccall posted:

in what sense exactly does go, a language with a segregated threading model and a gc, not have a runtime

maybe he's confusing runtime for vm

# ? Apr 4, 2018 01:46

pseudorandom name: May 6, 2007

rjmccall posted:

why would anyone who's not writing like a kernel or a bootloader care about static linking

and why would you talk about it like it's some sort of impressive hack instead of just not running the extra linker command to turn a .a into a shared library

a statically linked binary that has no dependencies other than the OS kernel is appealing to a certain subset of people who are bad at software development & deployment

# ? Apr 4, 2018 01:58

DELETE CASCADE: Oct 25, 2017; i haven't washed my penis since i jerked it to a phtotograph of george w. bush in 2003

hey rjmccall idk if you've made an effortpost about this before but i'm wondering, as a developer of a yospos officially recognized goodlang, what are your thoughts on go? i'm assuming you think it is bad, but is there anything redeemable in there at all?

# ? Apr 4, 2018 02:58

Sapozhnik: Jan 2, 2005; Nap Ghost

homercles posted:

Should net/http be removed and instead be implemented as a third party import from github.com/jrandomfuckwit/myhttpimpl ?

Get those common cases into the standard library and let the titans of the industry do it right. Batteries included is the way to go.

yes, unironically. this opinion actually makes me angry.

i don't care how good a programmer you are, if you set out to write a library then the odds are that it'll be poo poo. those odds go up tremendously if you write a library in a language whose idioms and best practices you are not familiar with. and if you are starting an stdlib for a language you just invented then those idioms and best practices don't even exist yet.

so maybe you'll do a good job, but you probably won't. and now everybody is stuck with this poo poo, and no matter how much hazard tape you use to cordon off that section of the stdlib you'll get zero-effort stack overflow jerkoffs continuing to copy paste code samples that refer to it so it's never going to go away.

if jrandomfuckwit writes an http library it will probably suck. but if a few dozen jrandomfuckwits write http libraries then chances are one or two of them will come up with an actually good design, if only by accident. and then that library will accumulate users. it's almost as if it gets selected... naturally. somehow. then later on it can be discarded and replaced with something else altogether in new projects. this is crucially important: outdated third party libraries can be gradually discarded (apache commons, jquery). crappy stdlib modules are forever (sprintf, java.util.Properties, python http.client).

the things that belong in the stdlib belong to three different categories:

1. things that the overwhelmingly vast majority of programs need, and that don't have horribly open-ended requirements. you need a way to print formatted messages to the console if only for quick debugging purposes, and gently caress adding a third party dependency to do that. you need some sort of associative array; anything that's not running on bare metal will not really care what kind of associative array it is exactly, but chances are it's going to need one, as long as users can define their own key types by supplying their own hashing function or operator-less-than you're golden. same for dynamic arrays, sorts, searches. but even though a lot of programs need an http client, it is not true that the overwhelmingly vast majority of programs do; also there's quite a few different kinds of http client with a bunch of different complexity trade-offs.

2. the basic vocabulary, which a lot of point 1 is going to slot into. iteration protocols, associative array protocols, error signalling protocols (Maybe, your base Exception, Result, that sort of thing), to-string and from-string protocols. format string syntax. your library ecosystem needs a few (!) basic conventions like this so that things can actually slot together without pointless glue code everywhere. probably some sort hierarchical logging framework is good to have too, since we know roughly what one of these needs to look like now. config file formats are still being endlessly bikeshedded though unfortunately.

3. system calls, typically concerning io. you don't want to have third party solutions involving os-specific native code in your shitlang's package manager, so yeah you do need a way to open async sockets and then harvest events built into your stdlib (or your runtime, if you've got some magical m:n threading or high-level language concurrency primitives thing going on). ffi is good too; we've established the rough shape of what this needs to look like, provide it in the stdlib for your shitlang so that the community doesn't have to.

it is better to err on the side of too little stuff in the stdlib than too much. too few critical utils like #1? well, somebody will write a library that becomes a de-facto standard (e.g. lodash. guava, hilariously, because java's stdlib is a gigantic trash barge and about the only useful part of it is java.util.*, which is actually not too bad but it made a few important and not-even-that-major mistakes that thankfully the whole industry seems to have learned from. but yeah, see the java stdlib? don't end up like the java stdlib).

too few protocols per #2? well, this is going to increase inter-library friction dramatically, so this is bad (worst case: you end up with the es5 situation where nobody even agrees on how to declare a loving class or import a loving module). C lacks even a standardized iteration protocol beyond a vague pattern of "supply a callback and a void* context" but then C's third party library ecosystem and build story is a goddamn mess to the point where loving javascript has its poo poo together by comparison. otoh C was invented in the 1970s and a whole bunch of shitlangs have come and gone between then and now, so C gets a pass. java kinda sorta standardized on slf4j for logging because java.util.logging sucked and also didn't come along fast enough (but mostly it sucked), but the java.util.List and java.util.Map interfaces are universal.

loving up #3 means you end up with a community package manager that casually calls gcc to compile native C code downloaded on the fly from gently caress knows where, so this is also bad. but then modern shitlangs are typically used to fling http poo poo, so make sure you have usable built-in wrappers for async socket syscalls and yer sorted.

# ? Apr 4, 2018 03:34

crazypenguin: Mar 9, 2005; nothing witty here, move along

rjmccall posted:

why would anyone who's not writing like a kernel or a bootloader care about static linking

and why would you talk about it like it's some sort of impressive hack instead of just not running the extra linker command to turn a .a into a shared library

it means you get 10 MB containers instead of having to blob together something bigger, basically.

I think another part of the appeal is that, because the language is statically linked, all the libraries are basically designed around it. So you don't end up distributing a statically linked binary that still thought it'd find its data files installed in hard-coded path /usr/share/whatever/ because nobody does that, culturally.

I don't think there's anything to praise about go the language (a big shame really) but go the tool isn't something I'd mind much. It builds fast, performs well, okay with memory usage, gets me tiny containers, low latency GCs... not the worst, really.

# ? Apr 4, 2018 03:36

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

Sapozhnik posted:

yes, unironically. this opinion actually makes me angry.

i don't care how good a programmer you are, if you set out to write a library then the odds are that it'll be poo poo. those odds go up tremendously if you write a library in a language whose idioms and best practices you are not familiar with. and if you are starting an stdlib for a language you just invented then those idioms and best practices don't even exist yet.

so maybe you'll do a good job, but you probably won't. and now everybody is stuck with this poo poo, and no matter how much hazard tape you use to cordon off that section of the stdlib you'll get zero-effort stack overflow jerkoffs continuing to copy paste code samples that refer to it so it's never going to go away.

if jrandomfuckwit writes an http library it will probably suck. but if a few dozen jrandomfuckwits write http libraries then chances are one or two of them will come up with an actually good design, if only by accident. and then that library will accumulate users. it's almost as if it gets selected... naturally. somehow. then later on it can be discarded and replaced with something else altogether in new projects. this is crucially important: outdated third party libraries can be gradually discarded (apache commons, jquery). crappy stdlib modules are forever (sprintf, java.util.Properties, python http.client).

the things that belong in the stdlib belong to three different categories:

1. things that the overwhelmingly vast majority of programs need, and that don't have horribly open-ended requirements. you need a way to print formatted messages to the console if only for quick debugging purposes, and gently caress adding a third party dependency to do that. you need some sort of associative array; anything that's not running on bare metal will not really care what kind of associative array it is exactly, but chances are it's going to need one, as long as users can define their own key types by supplying their own hashing function or operator-less-than you're golden. same for dynamic arrays, sorts, searches. but even though a lot of programs need an http client, it is not true that the overwhelmingly vast majority of programs do; also there's quite a few different kinds of http client with a bunch of different complexity trade-offs.

2. the basic vocabulary, which a lot of point 1 is going to slot into. iteration protocols, associative array protocols, error signalling protocols (Maybe, your base Exception, Result, that sort of thing), to-string and from-string protocols. format string syntax. your library ecosystem needs a few (!) basic conventions like this so that things can actually slot together without pointless glue code everywhere. probably some sort hierarchical logging framework is good to have too, since we know roughly what one of these needs to look like now. config file formats are still being endlessly bikeshedded though unfortunately.

3. system calls, typically concerning io. you don't want to have third party solutions involving os-specific native code in your shitlang's package manager, so yeah you do need a way to open async sockets and then harvest events built into your stdlib (or your runtime, if you've got some magical m:n threading or high-level language concurrency primitives thing going on). ffi is good too; we've established the rough shape of what this needs to look like, provide it in the stdlib for your shitlang so that the community doesn't have to.

it is better to err on the side of too little stuff in the stdlib than too much. too few critical utils like #1? well, somebody will write a library that becomes a de-facto standard (e.g. lodash. guava, hilariously, because java's stdlib is a gigantic trash barge and about the only useful part of it is java.util.*, which is actually not too bad but it made a few important and not-even-that-major mistakes that thankfully the whole industry seems to have learned from. but yeah, see the java stdlib? don't end up like the java stdlib).

too few protocols per #2? well, this is going to increase inter-library friction dramatically, so this is bad (worst case: you end up with the es5 situation where nobody even agrees on how to declare a loving class or import a loving module). C lacks even a standardized iteration protocol beyond a vague pattern of "supply a callback and a void* context" but then C's third party library ecosystem and build story is a goddamn mess to the point where loving javascript has its poo poo together by comparison. otoh C was invented in the 1970s and a whole bunch of shitlangs have come and gone between then and now, so C gets a pass. java kinda sorta standardized on slf4j for logging because java.util.logging sucked and also didn't come along fast enough (but mostly it sucked), but the java.util.List and java.util.Map interfaces are universal.

loving up #3 means you end up with a community package manager that casually calls gcc to compile native C code downloaded on the fly from gently caress knows where, so this is also bad. but then modern shitlangs are typically used to fling http poo poo, so make sure you have usable built-in wrappers for async socket syscalls and yer sorted.

It's hilarious you're trumpeting guava as an ideal library because we have three different systems that can't integrate anymore because guava can't stop making breaking changes between versions and each thing is stuck in a different version.

# ? Apr 4, 2018 03:49

DELETE CASCADE: Oct 25, 2017; i haven't washed my penis since i jerked it to a phtotograph of george w. bush in 2003

is one of those systems the timestamp ordering code for loving imessage

# ? Apr 4, 2018 03:53

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Sapozhnik posted:

yes, unironically. this opinion actually makes me angry.

i don't care how good a programmer you are, if you set out to write a library then the odds are that it'll be poo poo. those odds go up tremendously if you write a library in a language whose idioms and best practices you are not familiar with. and if you are starting an stdlib for a language you just invented then those idioms and best practices don't even exist yet.

so maybe you'll do a good job, but you probably won't. and now everybody is stuck with this poo poo, and no matter how much hazard tape you use to cordon off that section of the stdlib you'll get zero-effort stack overflow jerkoffs continuing to copy paste code samples that refer to it so it's never going to go away.

if jrandomfuckwit writes an http library it will probably suck. but if a few dozen jrandomfuckwits write http libraries then chances are one or two of them will come up with an actually good design, if only by accident. and then that library will accumulate users. it's almost as if it gets selected... naturally. somehow. then later on it can be discarded and replaced with something else altogether in new projects. this is crucially important: outdated third party libraries can be gradually discarded (apache commons, jquery). crappy stdlib modules are forever (sprintf, java.util.Properties, python http.client).

Nobody uses http.client though...

i mean...they did, but after awhile good third party libraries appeared and then people used them

# ? Apr 4, 2018 03:55

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

DELETE CASCADE posted:

is one of those systems the timestamp ordering code for loving imessage

Lol I don't work on ios but I'm pretty sure that it's not programmed in java

# ? Apr 4, 2018 04:00

jony neuemonic: Nov 13, 2009

Sapozhnik posted:

yes, unironically. this opinion actually makes me angry.

shooting from the hip here so :siren:

possible bad opinion incoming :siren:

but i think maybe clojure got this right? the language proper is tiny, and when they want to extend it they just ship a library like everyone else. turns out that idea sucked or someone else came along and did it better? deprecate the thing and move on.

# ? Apr 4, 2018 04:01

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

I just don't get this attitude at all. C# is awesome primarily because of its robust stdlib and the only thing holding it back is windows.

# ? Apr 4, 2018 04:05

AWWNAW: Dec 30, 2008

clojure is one of the best languages. simply tip top mate

# ? Apr 4, 2018 04:07

AWWNAW: Dec 30, 2008

c# is also a good language, and the .net framework is awesome but...

cis autodrag posted:

I just don't get this attitude at all. C# is awesome primarily because of its robust stdlib and the only thing holding it back is windows.

what do you think is behind all that standard lib? it�s windows

the .net core poo poo is a smart move but 10 years late

# ? Apr 4, 2018 04:11

Plank Walker: Aug 11, 2005

a robust stdlib + a package manager gets you a bunch of packages that do useful poo poo that all are using the same lower level dependencies

like, the alternative is literally an ecosystem where a package to implement string padding exists, and its removal from the package manager breaks a shitload of applications

# ? Apr 4, 2018 04:11

jony neuemonic: Nov 13, 2009

cis autodrag posted:

I just don't get this attitude at all. C# is awesome primarily because of its robust stdlib and the only thing holding it back is windows.

i don�t necessarily agree with Sapozhnik but i can appreciate where they�re coming from. c# rules and has lots of good stuff in the stdlib, but it also has a bunch of cruft that�s going to hang around forever and accomplish nothing but misleading newbies and discouraging third party alternatives.

then again js is the poster child for an anemic stdlib and blech, pass.

# ? Apr 4, 2018 04:13

Arcsech: Aug 5, 2008

AWWNAW posted:

clojure is one of the best languages. simply tip top mate

Clojure is the best a dynamically typed language can get, basically

cis autodrag posted:

It's hilarious you're trumpeting guava as an ideal library because we have three different systems that can't integrate anymore because guava can't stop making breaking changes between versions and each thing is stuck in a different version.

I dunno if they were saying guava was ideal, or just that its a de-facto standard library for java, which it is. but yeah guava version conflicts loving blow rear end

isn't that what java 9 modules are supposed to solve tho? idk maybe not, I should probably learn how those work at some point

# ? Apr 4, 2018 04:44

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

akadajet posted:

maybe he's confusing runtime for vm

this really gets into what you mean by vm, i guess. it's not a virtualized architecture with like a jit or anything, and that is a certainly an important distinction to make, and it implies a lot about the size and complexity of its runtime, its start-up costs, and so on. on the other hand, it has a isolated heap and isolated execution � it's not c++ or rust or swift where it's ultimately embedded into the c world with maybe some minor extensions/modifications in terms of extra thread-local state or calling conventions

DELETE CASCADE posted:

hey rjmccall idk if you've made an effortpost about this before but i'm wondering, as a developer of a yospos officially recognized goodlang, what are your thoughts on go? i'm assuming you think it is bad, but is there anything redeemable in there at all?

i think i have effortposted about this before but i don't mind answering again because it's probably evolved. note that this is all tempered by having never used the language

go is really dedicated to language simplicity. that's commendable in some ways, and i'm sure it has a lot of upsides. like picking up go is probably really easy because as a basic language it's just not that big (although i am skeptical that learning the basic language rules is ever really the limiting factor here; and there are things about go's syntax etc. that just do not feel intuitive to me at all). and different go programmers probably tend to solve things in structurally similar ways because that's just how go makes you approach the problem, as opposed to: alice loves to do everything with maps and filters and folds, and bob writes loops, and mallory is a point-free fanatic. the go world is self-moderating in complexity in part because of the constrained focus of the language

but of course that simplicity comes at a cost, or rather a bunch of costs, often substantial ones. there are usually good reasons other languages embrace complexity in places where go forsakes it, and it's not just feature lust. i think you can break this down into two groups:

1) sometimes you can look at something and say, ok, this is a big complexity trade-off and you made a decision that i think is respectable even if i disagree

generics are a seriously complicated feature. actually "feature" is not the right word, it's a whole intertwined system of features, and it's always trying to grow because there are things you can't express under the current rules that you could with just this one extension. and it infects everything else; almost every feature in your language becomes harder in some way because of generics. and a lot of the people asking for generics features are morons, the worst kind of morons, thoughtful and excited and highly-educated morons who are positive that there's something really deeply significant that they would be able to discover and convey if only they could express the equality of certain higher-kinded types. i don't agree with not having a general generics system but i do understand why a language designer might be ambivalent gun-shy

nullability is another thing like that. i think optional types are the right thing to do, but there's a real static vs. dynamic trade-off there. optionals types can be a big pain for users, and they don't usually have a good intuition for how to handle them, and if they're handled badly it just blows up into a huge simmering problem, and the programmer just feels frustrated. i understand why a language designer would choose to accept ubiquitous nullability instead

2) sometimes you can say, i get it, you didn't want to add complexity just for this, but you really should've. and there's just a bunch of stuff like this

like error-handling in go is an afterthought. i'm sure people talked about it but then somebody said that it could be done with multiple return values and that was the end of that. but it just sucks. i'm not going to get into this, it's well-trodden territory

but multiple return values are themselves basically an afterthought, it's a real, fleshed-out language mechanism but a lot of things don't use it that probably should. like when that blogpost was going on about channels. creating a channel is an intrinsic operation, and it gives you both ends of the channel back as a single value. and it's totally tempting to pass around that channel as a single value, but probably you actually ought to always pass it around as separate input/output channels. why does that intrinsic not just return two separate values? why have the unpolarized channel type in the language at all?

access control by capitalization. it's not like nobody has ever thought of this before, it's that we all saw it was a really bad idea. you want access control to be easy to change so that people can take sloppy code and start breaking it down into better abstractions without tearing their hair out. also it's not really important to know at the use site whether something is private. also it is probably too limiting to assume that you will never want more than two levels of access control. also maybe you shouldn't make core language decisions that only work in latin-1

i'm sure someone who actually uses the language could go on

overall i think it's interesting, like it is a statically-typed language and that means a lot. there are a lot of programs like build scripts and little servers that always start as little hacked-up scripts in e.g. python, and they usually very quickly outgrow the complexity-taming capabilities of their language but it's too late because it's literally 10,000 lines already. if those scripts were written in go instead then the world would be a nicer place. but it would be even nicer if they were written in a better language

# ? Apr 4, 2018 05:08

DELETE CASCADE: Oct 25, 2017; i haven't washed my penis since i jerked it to a phtotograph of george w. bush in 2003

that was a really good post thank you :shobon:

# ? Apr 4, 2018 05:21

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

rjmccall posted:

i've used go seriously and this is the fairest assessment of the language i've seen.

# ? Apr 4, 2018 05:28

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Notorious b.s.d. posted:

they could not even use the golang type system to implement the golang compiler -- shouldn't that have been a warning sign?!

not really, no. i don't think that anyone would argue that go is a particularly good language to write a compiler in, and that's certainly not something it's ever strived for. making your language really good for implementing your language's compiler is a common trap that languages fall in to which results in them overfitting to being good at something that no one else in the world will ever use your language for.

# ? Apr 4, 2018 06:11

Notorious b.s.d.: Jan 25, 2003; by Reene

Plorkyeran posted:

not really, no. i don't think that anyone would argue that go is a particularly good language to write a compiler in, and that's certainly not something it's ever strived for. making your language really good for implementing your language's compiler is a common trap that languages fall in to which results in them overfitting to being good at something that no one else in the world will ever use your language for.

golang was quite literally marketed as the next big thing in systems programming

it's cool to move the goalposts though, i guess. you made python, but worse than actual python, so naturally you cannot expect to make a useful thing like a compiler?

# ? Apr 4, 2018 06:26

Notorious b.s.d.: Jan 25, 2003; by Reene

rjmccall posted:

why would anyone who's not writing like a kernel or a bootloader care about static linking

it's worth noting that golang output isn't really static -- all C libraries are loaded as DLSOs

golang just has no well-specified calling convention to handle libraries. at all. as a thing. golang's compiler assumes you will build all golang libraries from source with your project, and only C dependencies are dynamic

it is the worst of all possible worlds: you still have dll hell, except for golang code, where you have github imports lol

# ? Apr 4, 2018 06:29

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 12:13

Notorious b.s.d.: Jan 25, 2003; by Reene

rjmccall posted:

generics are a seriously complicated feature. actually "feature" is not the right word, it's a whole intertwined system of features, and it's always trying to grow because there are things you can't express under the current rules that you could with just this one extension. and it infects everything else; almost every feature in your language becomes harder in some way because of generics.

rjmccall posted:

overall i think it's interesting, like it is a statically-typed language and that means a lot.

these two points in your long-rear end post are in fundamental tension

generics are hard as all hell to implement. i'm with you on that. it requires a language designer to solve a lot of hard problems and cut some particularly ugly knots

however, you can't have a meaningful type system without parameterized types, whether those are generic or not. the golang type system cannot express anything useful, which leads to the conclusion that while it is statically typed, that does not mean a lot. it's loving useless. it is an extra layer of bullshit

the reason we put up with compilation steps and the lack of native repls is that compilation catches important errors based on program invariants defined via the type system

golang robs us of the ability to define any invariants. the type system is poo poo. the compilation stage is just a needless indirection to inconvenience users.

# ? Apr 4, 2018 06:33

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »