|
comedyblissoption posted:a golang enthusiast wrote a very detailed article about why you should basically never use go channels lol Go is so bad, my work refuses to let me connect to that domain, for security reasons!
|
# ? Apr 3, 2018 22:56 |
|
|
# ? Jun 4, 2024 23:05 |
|
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 |
|
Sapozhnik posted:batteries included stdlibs are bad. 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 |
|
Sapozhnik posted:batteries included stdlibs are bad.
|
# ? Apr 3, 2018 23:11 |
|
they had community package managers in the 70s?
|
# ? Apr 3, 2018 23:15 |
|
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. 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
hmmm. ambiguous edge cases.
homercles fucked around with this message at 23:54 on Apr 3, 2018 |
# ? Apr 3, 2018 23:50 |
|
pseudorandom name posted:it has static linking so does java if i give you a jar file
|
# ? Apr 4, 2018 00:21 |
|
DELETE CASCADE posted:so does java if i give you a jar file except for requiring, you know, java
|
# ? Apr 4, 2018 00:28 |
|
"C doesn't have a runtime! Nevermind that DLL file that stands for 'C runtime'"
|
# ? Apr 4, 2018 00:40 |
|
btw did you see that go-routines are getting *cough* full preemption
|
# ? Apr 4, 2018 01:26 |
|
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 |
|
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 |
|
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 |
|
rjmccall posted:why would anyone who's not writing like a kernel or a bootloader care about static linking 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 |
|
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 |
|
homercles posted:Should net/http be removed and instead be implemented as a third party import from github.com/jrandomfuckwit/myhttpimpl ? 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 |
|
rjmccall posted:why would anyone who's not writing like a kernel or a bootloader care about static linking 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 |
|
Sapozhnik posted:yes, unironically. this opinion actually makes me angry. 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 |
|
is one of those systems the timestamp ordering code for loving imessage
|
# ? Apr 4, 2018 03:53 |
|
Sapozhnik posted:yes, unironically. this opinion actually makes me angry. 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 |
|
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 |
|
Sapozhnik posted:yes, unironically. this opinion actually makes me angry. shooting from the hip here so possible bad opinion incoming 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 |
|
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 |
|
clojure is one of the best languages. simply tip top mate
|
# ? Apr 4, 2018 04:07 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
that was a really good post thank you
|
# ? Apr 4, 2018 05:21 |
|
i've used go seriously and this is the fairest assessment of the language i've seen.
|
# ? Apr 4, 2018 05:28 |
|
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 |
|
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 |
|
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 |
|
|
# ? Jun 4, 2024 23:05 |
|
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 |