-
Every incident makes me hate Golang a little more twitter.com
Lies we tell ourselves to keep using Golang fasterthanli.me
via
msfjarvis
11 months ago
via
msfjarvis
11 months ago
Am I the only one being completely tired of these rants/language flamewars? Just use whatever works for you, who cares
You’re welcome to use whatever language you like, but others (e.g. me) do want to see debates on programming language design, and watch the field advance.
Do debates in blogs and internets comments meaningfully advance language design compared to, say, researchers and engineers exploring and experimenting and holding conferences and publishing their findings? I think @thiht was talking about the former.
I’m idling in at least four IRC channels on Libera Chat right now with researchers who regularly publish. Two of those channels are dedicated to programming language theory, design, and implementation. One of these channels is regularly filled with the sort of aggressive discussion that folks are tired of reading. I don’t know whether the flamewars help advance the state of the art, but they seem to be common among some research communities.
Do you find that the researchers, who publish, are partaking in the aggressive discussions? I used to hang out in a couple Plan 9/9front-related channels, and something interesting I noticed is that among the small percentage of people there who made regular contributions (by which I mean code) to 9front, they participated in aggressive, flamey discussion less often than those that didn’t make contributions, and the one who seemed to contribute the most to 9front was also one of the most level-headed people there.
It’s been a while since I’ve been in academia (I was focusing on the intersection of PLT and networking), and when I was there none of the researchers bothered with this sort of quotidian language politics. Most of them were focused around the languages/concepts/papers they were working with and many of them didn’t actually use their languages/ideas in real-world situations (nor should they, the job of a researcher is to research not to engineer.) There was plenty of drama in academia but not about who was using which programming language. It had more to do with grant applications and conference politics. I remember only encountering this sort of angryposting about programming languages in online non-academic discussions on PLT.
Now this may have changed. I haven’t been in academia in about a decade now. The lines between “researcher” and “practitioner” may have even become more porous. But I found academics much more focused on the task at hand than the culture around programming languages among non-academics. To some extent academics can’t be too critical because the creator of an academic language may be a reviewer for an academic’s paper submission at a conference.
I’d say that about half of the aggressive folks have published programming languages or PLT/PLD research. I know what you’re saying — the empty cans rattle the most.
You are definitely not the only one. The hide button is our friend.
So I was initially keen on Go when it first came out. But have since switched to Rust for a number of different reasons, correctness and elegance among them.
But I don’t ever say “you shouldn’t use X” (where ‘X’ is Go, Java, etc.). I think it is best to promote neat projects in my favorite language. Or spending a little time to write more introductory material to make it easier for people interested to get started in Rust.
I would go further, filtering for
rant,metaandlawmakes Lobsters much better.rantis basically the community saying an article is just flamebait, but short of outright removing it. You can choose to remove it.I think this debate is still meaningful because we cannot always decide what we use.
If there are technical or institutional barriers, you can ignore $LANG, such as if you’re writing Android apps, where you will use a JVM language (either Kotlin or Java) but if you are writing backend services, outside forces may compel you to adopt Go, despite its shortcomings detailed in this post (and others by the author).
Every post of this kind helps those who find themselves facing a future where they must write Go to articulate their misgivings.
I take this blog post as a response to personal criticism. He wrote something a couple years ago, it resurfaced, people say he doesn’t know what he’s talking about and he writes a new blog post to show he knows what he is talking about. It’s got some moments that go a little far (e.g. saying go was not designed) and it’s got some interesting criticism (e.g. the behavior of nil channels).
It’s important to remember that being in the public eye can be stressful and sometimes people lash out under stress.
Edit: Actually these tweets are pretty inflammatory.
It is unfortunate that these two Lobster posts were merged together, as I agree that the twitter thread is an uninteresting rant, but I actually found the blog post informative, even if it is also a rant. I would like to upvote the blog post but now I have to upvote both, I guess.
A lot of people seem really bent out of shape that some people like Go. There are all of these academic, theoretical reasons why Go should suck, but at the end of the day, a lot of people just want to get things done and many of us find that Go is the least obtrusive (and not all of us are mere neanderthals who simply haven’t been exposed to the Civilizing Light of Rust either).
The author describes Go as full of pitfalls that only Go experts know in advance how to avoid, but this is backwards. Go has far fewer pitfalls than just about any other language, and certainly the risk adjusted costs of those pitfalls is lower than, say, Rust (because this is the author’s preference).
The author also quips:
I’ve heard this claim a couple of times, but I’m not sure what it’s referring to? I would guess it’s talking about the resource type system, but that’s inherently a dynamic type system from the compiler’s perspective. Regardless, because you’re not Google, so you’re not building a project as complex as Kubernetes in the first place.
this is just a tweet
well, to be more specific, it’s a thread; not just the title tweet
Ok so go isn’t rust, scala, or haskell. Pretty much all these criticisms could be leveled at Python or ruby (at least without their optional type checkers).
I don’t think it’s coincidental- golang is a c flavored language that targets much the same programmer use cases as Python and ruby. Lots of programming has a lot of io, a lot of iteration over requirements that are completely ill defined, and needs to be easy to read. Yes this potentially lets bugs hide and requires that you run the code to achieve reasonable certainty that it works, but there’s a reason we’re not all programming in agda.
I think your comment is an interesting intermediate phase which precedes the point in the discussion where Go is directly compared to Rust alone.
In the first part of the article, we are linked to two case studies for Go’s unsuitability as a low-level systems language. In the first case study, a standard library structure is mutable and large. In the second case study, the standard linker and GC have large footprints. Scala and Haskell are no better than Python and Ruby at managing runtime footprints or structure size, because none of them are low-level systems languages. This leaves Rust as the lone contender in the discussion.
I don’t really believe that the majority of Go programs have much overlap with the majority of Rust programs. Sure there are cases where both Go and Rust are legitimate candidates for the same software, but I think Go is much more often competing with Java and Python than Rust, and Rust is more often competing with C++/C than Go.
Go was intended to replace C++. This is a well-cited motivation; Wikipedia says, “[Go’s] designers were primarily motivated by their shared dislike of C++.” I was at Google when Go was ascendant, and it was internally pitched as a replacement for C++, which was (and still is) one of the main pillars of Google code.
It was a curious turn of events when many Python and Java programmers switched to Go; it had not been anticipated. Go lacked the powerful dependency-injection tooling available to Java programmers, and also the flexible metaprogramming of Python; it wasn’t intended to be a compelling alternative for them.
In fairness, go is a good replacement for the use case of “I want C++ because it’s compiled and I’m not especially interested in safety or latency”.
This sounds conspicuously close to the Unix philosophy, and considering Go’s heritage, it doesn’t come as a surprise.
It sounds like golang is not good for whatever it’s being used for, but even in the guy’s 4 blog posts there isn’t a ton of detail.
Golang is good (perhaps not great) for things where you’re mostly doing io on unixoid platforms and there are no really complicated algorithms. It also discourages cleverness by verbosity (unlike Java encouraging both cleverness and enforcing verbosity). Concurrency is less painful than most other languages.
Not every programming language is great for every use case.
He said on Twitter he was professionally using it for networked services on *Nix.