This kind of blog doesn’t lend itself to coming out and admitting that mistakes were made. It’s supposed to make the company look good. It’s supposed to attract new hires. It’s supposed to help us stay relevant.
Typically, scathing indictments of technologies come from individuals, who have simply decided that they, as a person, can afford making a lot of people angry. Companies typically cannot.
That’s an amazing point. They often say, if you want to learn about parents, ask their children about them. Programmers are the ones often subjected to technical decisions that are supposed to make the company overall look good, but then programmers often hate those technologies.
I think most people don’t realize how radical the “Bell Labs gang”’s conceptualization of simplicity is. It is rooted in a deep suspicion of any kind of abstraction and a defeatist attitude when it comes to building them:
The abstractions you build will always be leaky, and your users will be forced to understand the underlying system sooner or later, so don’t bother with creating a complete self-sufficient system of abstractions.
Any abstraction complicates the system, so build as few abstractions as possible, and make the abstractions themselves as simple as possible.
(It’s worth stressing that “making abstractions themselves simple” is about the concept provided by the abstraction, not the implementation. For example, the implementation of GC and goroutines are very complex, but the concepts they introduce are simple. In fact, GC doesn’t so much introduce new concepts than take away the concept of memory deallocation.)
This attitude has long been criticized for resulting in leaky, incomplete, “half-assed” (as called by the author in a previous article), because it does. The UNIX-HATERS handbook labelled it as “worse is better” (which ironically got reclaimed by the Bell Labs gang). These criticisms are based on the anticipation that high-level abstractions should form a coherent system that completely covers a low-level system, and not require the user to understand the low-level system. But the Bell Labs gang says “you won’t get it right, so don’t bother”.
Dennis Ritchie said that “UNIX is very simple, it just needs a genius to understand its simplicity”. I don’t think it would take a genius to understand the simplicity of Unix, but it does require you to have a mental model of the system Unix runs on and what Unix’s abstractions are actually abstracting over.
Instead of passing judgements on which one of the Bell Labs gang and its critics are right, I think that it’s important to think of the design of computer systems as the constantly revolving field it is, with movements and counter-movements, instead of a monotonic approach towards an ideal state. Indeed, Unix and C were created as reactions against Multics (and presumably PL/I). Go was a reaction against C++ and Java. Rust is still too young to have its “Bell Labs gang” style reaction, but it would be very interesting to see one in future.
(It’s worth stressing that “making abstractions themselves simple” is about the concept provided by the abstraction, not the implementation. For example, the implementation of GC and goroutines are very complex, but the concepts they introduce are simple. In fact, GC doesn’t so much introduce new concepts than take away the concept of memory deallocation.)
The “worse-is-better” philosophy described in Richard Gabriel’s essay [0] actually prioritizes implementation simplicity over interface simplicity. Maybe GC and goroutines don’t reflect this, but you wouldn’t expect every principle to be operative in every decision.
Thanks, you are right that it was Richard Gabriel who coined the term.
But I quibble with the characterization that the Bell Labs gang prioritizes implementation simplicity over interface simplicity. Unix’s fork() was not simple to implement (at least not a performant way) but it presented a simple interface for controlling process creation. Neither was a single-root filesystem at that time, but again the interface is relatively simple. C’s printf() is also not simple to implement but the API was nice and simple (for the time).
Yes it was. The systems that it was designed for had one resident process in core at a time. Context switch meant writing that process out and reading another one in. With fork, you just skipped the second step, keeping the existing one and just updating some kernel data structures to say that this is really a new instance. It only became difficult to implement on systems with MMUs and multiple resident processes, but that was a decade later, by which time it was ingrained.
His example in the essay is how interrupted system calls are handled. In the “better” OS, there is a bunch of tricky work to do state switching in the kernel so the userspace API sees a simple call-return API no matter what. In Unix, the OS just throws everything away, returns an EINTR error, and expects userspace to put a loop around every system call so it can retry.
BTW, in early Bell Labs Unix, I’m pretty sure the implementation of fork was quite simple and performant, because there was no virtual memory. The performance tricks arrived with BSD, if I recall correctly. So that actually is an example of choosing a worse interface (fork is really quite a bizarre API compared to “create a new process”) for implementation simplicity.
Guess what happens when you don’t test [fork] for failure? Yep, that’s right, you probably treat “-1” (fork’s error result) as a pid.
That’s the beginning of the pain. The true pain comes later when it’s time to send a signal. Maybe you want to shut down a child process.
Do you kill(pid, signal)? Maybe you do kill(pid, 9).
Do you know what happens when pid is -1? You really should. It’s Important. Yes, with a capital I.
…
Here, I’ll paste from the kill(2) man page on my Linux box.
If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init), …
See that? Killing “pid -1” is equivalent to massacring every other process you are permitted to signal. If you’re root, that’s probably everything. You live and init lives, but that’s it. Everything else is gone gone gone.
Abstraction and software in general is about creating a relatively simple interface with a relatively complex implementation. The philosophy of prioritizing implementation simplicity only makes sense within a spectrum of decision defined by other factors, so examples only make sense in comparison to some other system or group of engineers with similar goals and constraints.
These criticisms are based on the anticipation that high-level abstractions should form a coherent system that completely covers a low-level system, and not require the user to understand the low-level system.
I haven’t seen that happen in the years that I’ve been around, at least. My experience with ambitious systems of that sort is:
97% are trash.
3% are actually quite pleasant, and good enough that you can mostly use them on their own terms.
0% are so good that you never need to source-dive, monkey-patch, or start reading CPU-level performance counters.
“Having a mental model of the system it runs on and what its abstractions are actually abstracting over” will get you superior results 100% of the time.
In practice, I would generally rather have something that attempts less, that I can use as a solid part of the solution to my problem, than to use a library that attempts everything, which almost-but-not-quite solves my problem, and which has such an extensive vocabulary of its own special abstractions that interfacing it to something else to provide the missing part requires reverse-engineering the authors’ brains.
This is an understandable viewpoint, but Go’s design is not simple. I usually start with the numeric types – which hardware was it designed for, and what safety properties are its abstractions designed to protect?
I don’t understand what your point is, but I suspect you are using a more specialized definition of simple than the workman definition. In other words, talking past the Op.
I typically assume that “simple” and “complex” are relative to the speaker’s experience. Let me sharpen the point: on which hardware does Go’s assortment of numeric types make sense? Are they abstracting over the hardware? I might pick on e.g. complex128, which I don’t think is a native type of any hardware, or uintptr, which enables unsafe actions that undermine the GC’s safety guarantees.
Most modern CPUs have registers that can fit a complex128, can add or subtract them in a single instruction, and multiply them in a handful (maybe 4). Division is more complicated, but then again I’ve worked with CPUs that lacked instructions for dividing integers, but I don’t think many people claimed that int8 wasn’t a native type :)
for me, the most exciting thing about golang is that i can easily walk junior engineers through a codebase with 0 prep. i love accessible code that doesn’t require a krang-like brain to intuit. rust is so non-intuitive to me that i’ve bounced off of it several times, despite wanting to learn it - and i’m a seasoned engineer!
i didn’t go to school for CS, and i don’t have a traditional background - there are a lot of people like me in the industry. approachability of languages matters, and golang does a fine job.
it obv has warts. but between the inflammatory title & the cherry picked “bad things”, the article winds up feeling really cynical, and makes me feel like fasterthanli.me is probably cynical too.
continues to write fun, stable code quickly in golang
For me—and for most who choose Go—the fun lies in watching your ideas for software come to life. Go is so easy to think in; it enables building stuff without having to fight the language.
I’d rather work with a stable language, so that I can be creative in the approach to the problem (not the language expression) than a language where I have to spend significant valuable background mental effort on the choice of words
The Rust folks had a similar issue with returning Option and Result and fixed it with the question mark operator.
The Error type can be named anything, but the community very quickly settled on naming it err, following the convention started by the standard library. The language designers should have just made that the default, and created a similar construct to the question mark.
after the first few times, it comes naturally for me and i don’t really think about it much. In fact, in situations where it is unnecessary I often have to stop and think about it more.
bc go code mostly looks the same everywhere thanks to gofmt and a strong stdlib, i spend a lot less time thinking about package choice & a lot more time doing implementation. yesterday i wrote a prometheus to matrix alert bot from scratch in 30 minutes - i spent most of that time figuring out what the prometheus API layout was. now that it’s deployed, i have faith that the code will be rock solid for basically eternity.
what’s not fun is writing similar code in ruby/python and having major language upgrades deprecate my code, or having unexpected errors show up during runtime. or, god forbid, doing dep management.
part of that is thanks to go’s stability, which is another good reason to choose it for the sort of work i do.
having a binary means not having to worry about the linux package ecosystem either - i just stick the binary where i want it to run & it’s off to the races forever.
to me, that’s the fun of it. focusing on domain problems & not implementation, and having a solid foundation - it feels like sitting with my back against a wall instead of a window. it saves me significant time & having dealt with a lot of other languages & their ecosystems, golang feels like relief.
it’s a language created at a specific workplace for doing the type of work that those workers do. Do you think bricklayers worry about how to make laying bricks fun?
For those looking for the lies, they’re listed at the end.
While I don’t disagree with most of the article, I think it’s worth stating the contrapositive case: golang is a language optimized for cranking out web services at Google with moderate to low business logic complexity where correctness is generally pretty ill defined. Tasks very similar to that are also suitably cranked out in golang. It’s not perfect, and certainly there are certain kinds of error that you’d like to be able to prevent or predict (for example with integrated modeling). I think of it as a compiled python2, with the additional goal that there really actually should only be one obvious way to do it, and readability is achieved by explicitness even when that is very, very verbose. The further you get from that kind of work (need for rich data structures, non-networked boundary, crappy network, complicated concurrency, real-time and high performance work, numerical work or any other domain where expressiveness is a huge performance or productivity win), the worse golang will fit your needs.
I don’t consider golang a joy, but I think it is largely successful at fulfilling that mission. Not optimal, certainly, but successful. And there’s a lot of code to be written that largely slots into the golang shaped hole.
Somewhat ironically, it looks like Python is overtaking golang on the safety story with a much more expressive optional type system.
As a practical marker, I think the bugginess of kubernetes shows that writing kube bumps up and slightly over the complexity level that golang is fitted for.
This is largely what my view on Go has evolved to over the years since it fully addresses the problem domain that it’s designed for: make a language that’s as simple and explicit as possible with the goal of trivializing the individual programmer’s impact on the project. If any given Go programmer is just as useful as any other and the language is easy to pick up in the first place, people are entirely expendable. It addresses Google’s internal needs perfectly, it just so happens that people outside of Google also use it. However this doesn’t free the language from criticism as it’s still rather… shoddy in the design realm, but any of those criticisms would fall on deaf ears. A much more relevant (and concerning, in my opinion) criticism is on Google’s approach to people and the use of a language to commoditize them.
A much more relevant (and concerning, in my opinion) criticism is on
Google’s approach to people and the use of a language to commoditize
them.
This has been a corporate fever-dream for decades, at least. They tried
to do it with Java, too.
I had a professor who taught a software engineering course. This was a
dude who had worked in industry. He claimed that eventually,
programming would be similar to a food service job. A designer would
make some UML models and stuff, and then hand them off to highschool
kids who would write the code for minimum wage.
Among the guy’s other ludicrous claims: eventually we’ll be writing
programs in XML! I thought he was kind of a silly assclown. He did
teach an excellent course on databases however.
We kinda do! The actual technology is XMLs easier-to-type cousin YAML,
but we absolutely write programs in a data structure language.
Point well taken. I’ve written my share of ansible config.
In another sense, the “equivalence of code and data” sense, a data
representation language is just code for a very limited kind of
machine. We hope it’s limited, anyway! TCP packets are programs that
run on the machine of a TCP stack.
I don’t think that’s what he had in mind. I think he was imagining
something more like C++ but with XML tags and attributes to represent
the syntax.
Replacing scarce and hard-to-train programmers with easy-to-learn languages or tools has been a theme for as long as I have been in the commercial software development business (late 90s). The craze for ML-assisted development is just the latest iteration of that.
The opposite of this is if every programmer feels like an amazing magician and writes their own DSL in Common Lisp and uses macros everywhere.
This can be good for the self esteem of inidividual programmers, but is horrible for hireability, teamwork and being able to tell what a screenfull of code does without extensive digging.
This was always my suspicion about Go. The commoditization. On the positive end, that could be a strength for open source projects as it lowers the bar for participation. I can only imagine how CoPilot and the likes will amplify this over the next coming decades.
My strong intuition within a generation is that most ‘coders’ will only submit pull requests (or issues) for features, fixes, etc., along with some bots, and the new paradigm of social-driven automation (hybrid of human coders and AI bots) will update the PR by generating the code and even the tests. It will be as much an art as a science in submitting good issues or PRs that get the results you want. Whomever ‘fulfills’ the issue or PR (updating it to completion) will be rewarded for it, sorta like a bounty or something.
golang is a language optimized for cranking out web services at Google with moderate to low business logic complexity where correctness is generally pretty ill defined
Sounds like the same pitch as PHP and look where the public opinion of that language went, fractal of bad design and all that.
Sometimes it feels to me like Go is the place where people can follow all their old PHP practice at slightly better performance and legitimized by the fact that it’s “the language Google uses internally”
I wrote a book about Go around the time of the 1.0 release and, while it’s not the worst language in the world, I honestly don’t understand people who like (rather then merely tolerate it). The big thing that astonished me is summed up in the audience question near the start. For safe concurrent programming, you need to enforce one invariant: no data structure is both shared between units of concurrent execution and mutable. Erlang does this a very simple way: no data structures are mutable except the process dictionary (which can’t have a reference to it taken and so can’t be shared). Rust does this in a more complex way via Send and Sync traits to express ownership transfer or a relaxation of this rule for when you have some other mechanism to permit safe concurrent mutation. Go makes it trivial to accidentally share objects between goroutines and provides absolutely nothing in the type system to prevent accidental concurrent mutation. The ASPLOS paper a few years ago that showed large numbers of concurrency bugs in Go programs was absolutely no surprise.
I want a language that makes it hard to introduce bugs. If it must make some categories of bug easy to introduce, I want them to be ones that are easy to debug. Concurrency bugs are the hardest to debug because they often go away when you add any kind of instrumentation. You can avoid them entirely by avoiding concurrency (which is fine for a lot of use cases. See Python, for example), but if your language is going to encourage concurrency then you absolutely must have something in the type system that lets you statically avoid concurrency bugs.
Weighing the pro and con of something as multifaceted as a programming language is not the same as lying. Everyone, every team must learn, practice, decide, and reevaluate their decisions. I appreciate this author’s attempt to provide their own insight into this challenge even though I don’t share the many of the same concerns or conclusions.
This deserves a rant tag. Legit sucks that Amos felt like needing to go so hard on this topic, and when this first circulated months ago it generated so much of a mess.
This is a weird way to measure a language. Look at GitHub and how productive a single developer can be with Go. Some programs are editors, computer games or command line utilities. Not every program needs the type of defensive programming the article promotes.
Inherent complexity does not go away if you close your eyes.
This is true. But not all projects has this particular type of inherent complexity.
Successful projects, quick compile times, an ecosystem that lets you add a dependency that works, not having broken code just because 3 years has passed; these are also nice things.
One should not close the eyes to the quick development cycles and low cognititve overhead experienced Go developers can achieve, either.
No, you couldn’t, and there is no comparison. Look at active repos in Common Lisp, Scheme, Forth, Smalltalk, Ada, you know, the languages everybody talks about nicely. Then look at Go. If there’s 2 types of X, the ones everybody complains about, and the ones nobody uses, Go is certainly in the first group.
Go is very popular, and getting more popular, and there is no denying it: https://madnight.github.io/githut/#/pull_requests/2022/3.
Tons of people are learning go in their free time and using it to get stuff done, because it is easy to learn and easy to get stuff done with.
Now you’re arguing by popularity, which is a fallacious argument and a very different thing than “you can get stuff done with it”. Clearly you can gst stuff done with the other languages too.
Github and the popularity of the language in the platform proves that many single developers can and are getting stuff done with it. Which is a proof that you don’t get with other, unpopular languages. You might claim that they are just as good, but you are not getting proof of it from github.
Tobacco smoking and eating tide pods do not produce anything (well, except damage to the person doing it). I think corasara is implying that projects on github demonstrate that people get stuff done with Go. To put it differently, TikTok and Insta measure popularity. GitHub showcases code that actually does something (well, most of the time). And the fact that there are many repositories on GitHub implies that many people do get stuff done with Go. Now, there might be an issue that users of other languages do not advertise their work on GitHub…
My point is that the people that get stuff done with Go could be just as well getting stuff done with other languages, but most of them haven’t really tried many other languages besides the ones that are obviously worse for productivity, such as C.
I think this is wrong. I think developers that have tried many different programming languages are the ones that most appreciate the things that Go gets right.
Wow, look at the replies you’re getting. These people are coming out of the woodwork to defend their questionable career choices. One could base a whole career on Go criticism.
This is ridiculous. You are comparing a decade of individual’s spending their rarest resource, their free time, to a claim that a 4chan meme was real and chemical addiction.
Get over it, some people use go because it’s the best choice for them.
Quite good article, as usual from this author, but could probably use a slightly less aggressive title and tone. As it is it’s not quite a rant, but it probably won’t convince anyone whose mind isn’t already made up. But also whenever you keep hearing the same arguments about something it saves a lot of time to be able to put down all the responses in one place and just refer people to specific parts. Rehashing the same arguments all the time is tiring.
It also makes it extremely hard to integrate Go with anything else, whether it’s upstream (calling C from Go) or downstream (calling Go from Ruby). Both these scenarios involve cgo, or, if you’re unreasonably brave, a terrifying hack.
While indeed a terrifying hack… The linked article is also a pretty basic work-through of what it takes to make different calling conventions match up with each other. What do you think your compiler and linker do every day of the week? The only difference is they know what they’re doing before hand. The terror mostly comes from breaking Go’s calling conventions for its own good.
Uh, I am not sure if I disagree or not with that. I can see young, naive people reading this and saying, “omg I better not choose Go”, but if they ran into a pro-Go article first, they would do the opposite.
So yeah, if inexperienced are the target, it might work.
To me (not working with Go, but being experienced in other languages), it looks like a lot of cherry-picked straw-man examples. Not all of them, but many of these things are either one-sided or not relevant at all.
E.g. from the list at the bottom of the article:
Others use it, so it must be good for us too
Everyone who has concerns about it is an elitist jerk
What kind of argument, is that? Who, apart the aforementioned juniors, picks languages and technologies based on such arguments?
Its attractive async runtime and GC make up for everything else
Again, a lot of people picking go say “I like the async runtime”, but i don’t think people tell themselves, “GC will make up for things for me”. Basically all the points are mixed with some good examples and explanations, but the premises and assumptions, and the “we tell ourselves these lies so we can keep using Go” is simply not proven to me, and the lies are just made up to fit the narrative of bashing Go.
And this has in turn made me think that the author is clearly smart and good, but they are not writing anything for me, but to promote some agenda that they have.
So again, I’m not sure if the article can or cannot convince readers of anything, and what is it that it is convincing.
I don’t think the article is self sufficient, you need other sources to make up your mind. Personally, my mind was made since I learned Go didn’t have generics, which in my opinion is unacceptable for any garbage collected language conceived after Java added them. And sure enough, a couple other serious flaws came up, that showed that indeed, they did ignore the last few decades of PLT research.
As far as I can tell, Go’s legitimate niche is narrow enough that I wouldn’t use it for anything substantial. Same as Python, actually: I use Python often, but never for anything big. Either it has a library that does what I need and my program can stay very short, or I’m using its bignum arithmetic to prototype elliptic curves stuff.
Others use it, so it must be good for us too Everyone who has concerns about it is an elitist jerk
What kind of argument, is that?
It sneers at arguments by popularity. In fact, I suspect that Go would never have caught on if people couldn’t say “Google uses it”. Thing is, even if it’s good for Google, Google is an extremely singular company. Programmers are extremely unlikely to work in a similar enough setting that looking at what Google uses is a good heuristic.
Who, apart the aforementioned juniors, picks languages and technologies based on such arguments?
A good chunk of the great many people that use Go and came to regret it? As far as I know juniors don’t pick languages in the workplace, that decision is given to more seasoned devs. Senior folks still make mistakes, of course, but here I feel like many of the flaws that ended up biting them could have been anticipated:
No generics? We need to ascertain that maps & slices will be enough.
Peculiar error handling? We need to see how it works, what are the pros, and what could go wrong.
Poor C interoperability? We need to look at the FFI, and if we can’t reasonably talk to C we need to investigate alternatives (pipes, sockets…).
Few platforms are properly supported? We need to try all platforms we are likely to use.
I suspect corners were cut instead. Prototypes were written, and it went well enough that they found their way to production before the language could be properly evaluated (devs were stuck in honeymoon phase, management wanted to ship, deadlines were tight…).
i don’t think people tell themselves, “GC will make up for things for me”
Go’s GC has an unusual performance profile. If I recall correctly, it optimises latency at the expense of pretty much everything else. I guess that means it has more overhead than other GCs, but the low latency remains very useful for real time networking… which is precisely Go’s niche, so not only people could tell themselves the GC makes things up for them, if they use Go for its intended purpose they could even be right.
Quite good article, as usual from this author, but could probably use a slightly less aggressive title and tone. As it is it’s not quite a rant, but it probably won’t convince anyone whose mind isn’t already made up.
I would like to problematize the idea that an aggressive tone would prevent people from being convinced. Are our brains really that weak, that conclusions that we should derive from facts are actually a product of the tone with which the facts are presented?
Are our brains really that weak, that conclusions that we should derive from facts are actually a product of the tone with which the facts are presented?
Yes. People get defensive when they feel attacked. Unfortunately this is better documented in books about romantic relationships than any material directly relevant to software engineering.
Some people thrive in environments open to hostility. OpenBSD and the culture Theo de Raadt cultivates around it proves that. But most people aren’t like that.
This is tone policing, though. A less aggressive tone is usually ignored; it’s common knowledge in PLT/PLD circles that Go is unacceptable for typical tasks, but because it’s said politely, it is not taken seriously as a rationale for discarding Go.
Personally I think the original article is fine. My problem is with this nonsense notion that people who don’t respond well to aggression are weak-minded. In the software community that attitude is often used as a bad faith justification for being an asshole.
I’ve also seen people using the tone of the speaker/writer as a justification to ignore their core points, which is lazy at best. I’ve seen people dismissing well reasoned, level headed, professionally delivered arguments just because the same author used a more aggressive tone than they are comfortable with elsewhere. And sometimes, the aggressive tone is actually justified. Not as an argument unto itself, but as a way to stress the importance of the issue.
My problem is with this nonsense notion that people who don’t respond well to aggression are weak-minded.
Sure, people who are personally attacked can’t be expected to respond well. I know exactly how that feels. But I’ve also seen people responding poorly to other things. One striking example from a year ago went as follows:
Mr Aggressive gives constructive feedback to Team, suggests what ought to be a fairly easy fix. I perceived no aggression at this point.
Team dismisses the feedback, say the fix would be way too hard, and Mr Aggressive should tone it down.
Mr Aggressive gives up on Team, leaves the conversation.
Some time later, Mr Aggressive takes 4 days of their own time to write a proof of concept that quite thoroughly demonstrates that what they said was easy, is. Then he presents his work on YouTube. This time he’s not being kind to Team. He gave up on convincing them, now he’s using them as an example not to follow.
Quite a few bystanders respond poorly to that. Some say he’s too aggressive and use that as an excuse not to listen. Others rehash the same arguments Mr Aggressive explicitly addressed, and use those as an excuse to ignore Mr Aggressive’s counter-arguments.
Mr Aggressive delivers a level-headed, calm lecture explaining in detail how to implement the fix, why it works, and what’s the broadly applicable meta-reasoning that lead to the fix.
Some people respond poorly to that, because of the aggressive tone back in (4).
Sometimes, merely pointing out that there is no God will be perceived as an aggression from some religious people. It’s really not. It’s just an attack on their mistaken belief. Yet I’m pretty sure many religious readers would have flinched a little at my exact choice of words right now. Maybe perceived it as a too combative, perhaps even a little aggressive. But that perception should not be used as an excuse to respond poorly. That would be weak minded.
I hesitate to confirm or deny anything here, because it would shift the discussion to the particulars of whether this tone or those words were appropriate for these circumstances, and the technical discussion about whether you believe Team or Mr Aggressive.
I did forget point 8 though: about a year after the events (a couple months ago I think), Team ended up implementing the fix, or something similar enough that it achieved similar effects.
You did say “yes,” seemingly agreeing that being swayed by tone rather than facts is a weakness (at least on questions of engineering). And you seem to imply here that this is “not responding well to aggression,” which is about the same. Sure this observation can be used for ill, but I don’t see why anything said here warrants an aggressive response.
It is possible to make one’s statements aggressive, passionate and convincing without being a douchebag. Hurting people because it’s a convenient shortcut for getting attention is pure laziness.
No, it was a feeble and extremely transparent attempt to mock my position. It doesn’t even follow from anything I said, you’re just saying goofy things to paint me as “weak minded.” It’s absurd and childish.
Are our brains really that weak, that conclusions that we should derive from facts are actually a product of the tone with which the facts are presented?
If your objective is to try and convince pretty neutral people that something is “bad” you can just share what info you have. At one point implying people are stupid will indeed make the people whose stupidity you are implying feel annoyed at you!
Would you give the time of day to somebody calling you an idiot? This is obviously not as direct, but it’s on the scale.
humans suck at maintaining invariants. All of us. But we are capable of building tools that can help us doing that. And focusing our efforts on that has an upfront cost, but that cost is well worth it.
This ranges from the near invisible level of our languages providing functions and stack frames so we don’t live in a sea of gotos, to the micro level of not putting your data in a corrupt state to maintaining invariants of concurrent systems to substituting modules in different members of a program family seamlessly (e.g., I want to attach a toy implementation of X for local dev or testing instead of the full X without having to do lots of plumbing in my code).
I like Go. It’s a simple language, every project has a similar code style so it’s universally easy to read, it’s very easy to build production applications which have almost no dependencies, the list of positives goes on and on…
Every language has issues. I also like Ruby and that runtime has big issues too. Languages are tools and tool usage is always context specific.
But I have a commercial product written in Go and I’ve never had a large scale project like it that requires so little maintenance. It just continues to compile and work, year after year, without any effort on my part. This is the exact opposite of something like JS apps which need constant updating to giant dependency trees to keep them modern and working,
A lot of people seem to focus on the pros and cons of the Go language itself, which unquestionably does have some polarizing design choices. But to me the productivity people get with Go seems more to do with the system around the language: the standard library, module system, single-binary deployment, tooling, and most importantly stability as a core value.
In use it feels like a system built by hardened cynical engineers who want the tooling to “just work” and get out of the way of their code. The goal is not to present “simple” or “magical” facilities, but to build everything with understandable mechanisms so you always know what’s going on under the hood.
The oft-quoted comment by Russ Cox about how it’s to enable novice programmers makes no sense to me, as the assumption everywhere in Go seems to be that you will constantly be aware of the ways you can screw things up, and read every word of the documentation before using a library.
But to me the productivity people get with Go seems more to do with the system around the language: the standard library, module system, single-binary deployment, tooling, and most importantly stability as a core value.
This is my experience. While the language might not have every feature that I’ve dreamt for, everything I’ve built in it continues to work,easy to setup CI for, easy to debug, profile, and now fuzz too. The tooling is top notch.
There’s a lot of problems to solve in software engineering. The Go team have chosen a subset that are pragmatic.
They aren’t independent. If you look at the design of Go, there are decisions in the language that enable the tooling, and vice versa. As an obvious example, the namespace for modules is literally version control URL prefixes. As a counterexample thought exercise, imagine how you’d make “good tooling” in this sense for C++ without being able to modify the language.
(Whereas in a language like Rust, a channel closes when its Sender is dropped, which only happens when nobody can touch it again, ever. The same probably applies to C++ and a bunch of other languages, this is not new stuff).
Uh, what? This is something that almost no language with real users can enforce (Rust being the biggest notable exception). Even in C++, while you can get some safety improvements in this direction with dtors and some attention to which constructors you do or don’t provide, the compiler can’t actually tell when you’re done with something that has reference semantics, so there’s not really a scenario where “nobody can touch it again, ever.”
It gets very uncanny valley and into the territory of “I would sleep better at night if this would panic.” And at time of writing every other language that does this right is really, really obscure
sub-structural types very much were “new stuff” when these semantics were stabilized.
I agree with most of the article; I still like Go, but it is a deeply flawed language. And I think zero values are the worst thing about the language. But this was a weird assertion to make in the midst of all that.
I agree with that statement, and I think it’s a lie people tell themselves.. about Python.
I also agree with it regarding Go. There is way to many people that simply favor very different languages. One can see that by how so much Go code coming out of Google is C++/Java/Python style. Folks, don’t get Go jobs when you prefer to design software differently. You’ll be angry about how Go isn’t X and Go people well be angry that code isn’t idiomatic.
On a related note. If you want to program in a language cause Google, you should do Dart. and be happy with it. (/sarcasm)
Everyone who has concerns about it is an elitist jerk
If you feel the need to write about some language you simply don’t write and whose design choices you don’t understand or agree with, you aren’t elitist or a jerk, you just seem to be really bored and unsure about what to do with your time.
Its attractive async runtime and GC make up for everything else
That’s a really odd thing to say in my opinion. There’s quite a few other languages, also in the functional programming realm for example. I don’t really know many people that use Go for these reasons alone. Sure they pushed the concurrency/parallelism part a lot initially, maybe too much, but people stopped that, because everyone overused it. Overusing being use cases where it doesn’t make sense or even is counter-productive.
Every language design flaw is ok in isolation, and ok in aggregate too
I think something like this is often mentioned. It’s a general theme with languages that don’t try to copy C++ or Java (with nicer syntax or something). Having different view points/design decisions from you/the language you like isn’t a design flow. It’s the same with operating systems. They have different priorities and different design decisions or the are just yet and another “the next Linux/Windows” with little to no innovation.
We can overcome these by “just being careful” or adding more linters/eyeballs
I think that’s yet another topic that comes with using a language you don’t wanna be using. A lot of the “Odd thing about Go” articles mention something that is either very obvious even if you just started out (reading Effective Go or something done by the initial authors) or something highly un-idiomatic.
Because it’s easy to write, it’s easy to develop production software with
It is compared to most other languages. Production software is a lot harder than people tend to admit, which can be seen by pretty much every postmortem out there. When you develop something and it’s not a success or don’t have users communicating potentially big issues you might even know about issues.
Because the language is simple, everything else is, too
Huh?
We can do just a little of it, or just at first, or we can move away from it easily
Ah. Yup. Prototypes going into production. Not sure how it relates to Go.
We can always rewrite it later
Huh?
Go is closer to closed-world languages than it is to C or C++. Even Node.js, Python and Ruby are not as hostile to FFI.
And everywhere it comes with drawbacks, like software having issues it couldn’t have with the interpreted language. And things like libraries not compiling, so everyone is forced to use containers as a hacky workaround. Also all of these languages have lots of libraries proudly declaring “Pure Python/Ruby/JavaScript” as one of their main features. Don’t act like these issues don’t exist.
Evidently, the Go team didn’t want to design a language.
Or simply not a language the author would want to use. The team also did Limbo and Newquask. Languages with similar design choices, that didn’t end up being popular, because there was no big name company behind it.
And so they didn’t. They didn’t design a language. It sorta just “happened”.
Because it needed to be familiar to “Googlers, fresh out of school, who probably learned some Java/C/C++/Python” (Rob Pike, Lang NEXT 2014), it borrowed from all of these.
Isn’t that basically the story of Python, C, Linux, etc.?
Something I see in a lot of this articles as I mentioned is doing very strange things and then blaming the language. It’s the classic “JavaScript has === for comparison” argument, where one simply disregards the language, acts like it’s a different one and complains that it’s not. I think that’s a big problem with language design. So many new languages are C++ with syntax for something odd improved and some cruft removed. That’s fine, but in the end you are still doing C++. Even more often that cruft is replaced with some other cruft very, very rapidly.
For now now Go has mostly avoided that, even though I think Google is pushing there. Google seems to be the place where everyone would rather use Java or C++. Not to bash them, but they pretty much made the opposite design decisions on everything Go did, so it’s gonna be hard.
I get where that sentiment comes from though. Sometimes I feel like the only person developing in Go despite Google and not because of them. It’s really annoying that they seem to have taken a stronger grip on the project, which can most prominently be seen comparing go.dev with the old golang.org and some library stuff.
But basically that’s the response the author expected, minus the “large company” argument, which is silly in every context. Large company can also mean “they have three teams playing fire brigade for that project” and “nobody dares to write a better solution, because it might break something”.
If the author reads this: The link to the language designed isn’t working because of a bad certificate. Nice website though! :)
you just seem to be really bored and unsure about what to do with your time.
Alternative explanation: sometimes people try to vent complaints when they are exposed to something that they don’t like. When the complaints are rebuffed repeatedly they can build up and become more frustrating. The result is that the person isn’t just responding to the object of criticism, but also to the culture around it. People react strongly when they feel like they aren’t seen or heard.
The Go community comes off a little hard headed sometimes and I think this draws out sharper criticism.
I get that. However I don’t think it makes sense to criticize Go (or any language) to not be like another.
It happens way to often and what that leads to is that over time languages turn into the same kind of mess with tons of deprecated old style features.
That’s I think why things are seen as hard headed. Go developers (as in users) that actually like the language don’t want it to change, they like the trade-offs made. They recognize that the language has sharp edges, especially when using it wrong, but they like the fact that this makes it so that you can be aware of all the sharp edges.
In many languages there’s fewer sharp edges on the surface but you can’t to be aware of huge amounts of subtle details and importantly also their history. This means that even after years of development you will still learn new things about the language itself
I actually think that’s why some people enjoy very old and minimalist language. I think it’s also why developers actually enjoy new languages. Not because they bring that cool be feature, but because they don’t have that history of language changes you kind of have to know to really grasp the language. And that history is being created by good and smart ideas on how to make the language better.
Features even ones that make something easier do add complexity. There’s many talks about Go being “finished” from years ago. This is kind of a way to say that the authors won’t change it. That’s a feature of the language.
It’s fair to say you don’t mind it and it’s fair to say whatever shit the language, but wouldn’t a better way be to fit example use C# when that’s what you want out of a language instead of complaining that Go isn’t.
I think that hard headedness should show that these things are the way they are on purpose.
Personally I’m happier about “Go sucks because X, so don’t use it” articles than “Go sucks, this skills be changed” overs, because the first might tell you to not use it if you don’t like the design decisions, whereas the latter wants to ten the language into another.
I think there’s enough languages out there that would better suit the need of the author of the article. This is what I meant with the “bored” stuff you quoted. Work with languages you like more and if your boss forces you to use a language you fundamentally disagree with even after taking an actual close look on it consider changing to something you enjoy or potentially consider making your own thing. LLVM is great, everything is a HTTP API, WASM allows for interfacing with others to some degree so it’s relatively unlikely that you are really forced to use a certain language.
Sorry that was a lot of words, I just hope it helps to not misinterpret what I’m trying to say.
This is almost exactly what I feel about the article, the author is bored. You offered good questions to every argument there. Not saying Go is or isn’t this, just pointing out the things about the article that are weird.
The article may have a certain hidden purpose, but it’s really not showing what it’s claiming to show.
Indeed. I really only used those languages as example. They are matters of taste, philosophy, design choices and even culture to me. People are different in how they think and approach stuff so of course they’ll use different programming languages to work with even when the goals are identical.
Just how companies are successful with different ways of managing tasks, doing business, communicating, monetization models, editors, office suites and so on. And time and luck also play roles. I think people very much overestimate the role of technologies/products used for the success of a a product.
I’m learning Plan 9 at the moment (specifically, 9front) and it’s fascinating to see the philosophical similarities between Go and the Plan 9 dialect of C.
A better idea is to give the programmer the ability to handle any error that comes in without worry of losing standards compliance or clarity, and to generate any error without falling into a surfeit of possibility. So the designers of Plan 9 decided to use strings instead of numbers. Each program has an error string which is set by routines when an error occurs. And each program returns a string to the host environment with the exits system call. The value given to exits can be accessed from rc through the environment variable $status.
So with a string, how do you represent a lack of error? Why, with a null pointer or null string! Because the constant 0 turns into a null pointer, the statement
exits(0);
does everything already. Of course you can also say
The Go compiler can’t tell the difference between “I am saving some typing by letting b default to zero” and “I forgot to update the callsite to pass b”. This is because everything in a struct is optional, defaulting to the “zero value”, which may or may not be what you meant (or even be a meaningful or safe value).
As always with Go, the answer is “just be careful”.
The answer for me has become - write a NewFoo function that properly initializes the struct in a correct fashion, erroring if need be- never, ever, doing a direct struct init. Kinda crap, tbh.
This pattern is also encouraged in Rust, and one of the reasons it’s encouraged in Rust is because if you do choose to initialize a struct literal at its usage site, if you modify the struct the compiler will complain until you modify the struct literal initialization at every call site, rather than silently doing a possibly-incorrect thing like Go seems to do.
Always key-ing literals helps here. Not enough necessarily, but helps. I would not be adverse to a new Go version allowing some other default to be tagged to fields in a struct.
I think there is an argument to be made that what is and is not idiomatic Go is well known enough that checks from the vet linter could be moved into the compiler with a flag as a compile time error, and some of the uncontroversial lint checks that exist in the community be adopted into vet. The compiler could be helping more without language changes. I would be very happy for unkeyed literals to be a compile time error.
Wow look at how many comments are in this thread. Go criticism really strikes a nerve in some people, eh? As far as career-promoting blog posts are concerned, this is state-of-the-art. I’m sure OP will get a lot of clout from this.
I wonder how this can be reproduced? Because this clearly isn’t like, some air-tight case against Go. And OP is clearly heavily biased towards Rust which has its own share of problems. I won’t enumerate the reasons why because I don’t wanna debate within an upvote-ordered comment tree (pretty bad medium for deep discussion IMO).
Is this guy famous or something? Or is this type of rant simply a honeypot for commenters?
I shared this article because the content is interesting and germane, and the author is reputable. I suppose, if I have an ulterior motive as a language designer, that I shared it because I think that it is important to keep in mind that most programming languages are completely unsuitable for serious work; examples of bad programming-language design are important to discuss.
I am always amazed at exactly how vociferous the folks are when they choose to defend programming languages; our tribalism is intense and we have no idea how to moderate ourselves.
Not to mention that every language has a “sweet spot” — a product-market fit if you will — but there are always people who want to treat their favored language as universally superior. Go has an unusually pure cultural and technological sweet spot, and if it works for you to live in that spot, it is actually quite fun. But it’s far from universally applicable, from both a technical and personal perspective.
Go criticism really strikes a nerve in some people, eh?
I don’t think it’s Go criticism, it’s just unfounded, or at least, unexplained criticism. I’m not even using Go, and I think the article is part-rant, part-troll, because it’s not making sensible arguments to me.
What would you want to read on? Why not using bleeding-edge type system research results in a new language a bad idea? I don’t have a clue.
On the other hand, I can make that claim from the article even “stronger”. You can easily show that Go creators ignored research from before 1970 - Algol68 contains sum types/tagged unions.
@tt Types or no types is still in realm of holywars among my fellow developers - where everyone religiously defends their position. My interest is mainly to understand what research is saying about types in programming languages.
Incidentally, it occurs to me that playing badly with other languages is probably a design choice: it makes it much easier for google to rebuild the entire library supply chain from scratch if it’s all in one language.
This has the benefit that you can patch the source of a dependency and have all your software benefit from it, without needing to make dynamic linking work, and makes it easy to know if your deployed artifact came from a build that used the patched version.
Playing badly with other languages has been a big blocker to internal adoption at Google there are tons of libraries/systems that just don’t work in Go.
That’s an amazing point. They often say, if you want to learn about parents, ask their children about them. Programmers are the ones often subjected to technical decisions that are supposed to make the company overall look good, but then programmers often hate those technologies.
I think most people don’t realize how radical the “Bell Labs gang”’s conceptualization of simplicity is. It is rooted in a deep suspicion of any kind of abstraction and a defeatist attitude when it comes to building them:
The abstractions you build will always be leaky, and your users will be forced to understand the underlying system sooner or later, so don’t bother with creating a complete self-sufficient system of abstractions.
Any abstraction complicates the system, so build as few abstractions as possible, and make the abstractions themselves as simple as possible.
(It’s worth stressing that “making abstractions themselves simple” is about the concept provided by the abstraction, not the implementation. For example, the implementation of GC and goroutines are very complex, but the concepts they introduce are simple. In fact, GC doesn’t so much introduce new concepts than take away the concept of memory deallocation.)
This attitude has long been criticized for resulting in leaky, incomplete, “half-assed” (as called by the author in a previous article), because it does. The UNIX-HATERS handbook labelled it as “worse is better” (which ironically got reclaimed by the Bell Labs gang). These criticisms are based on the anticipation that high-level abstractions should form a coherent system that completely covers a low-level system, and not require the user to understand the low-level system. But the Bell Labs gang says “you won’t get it right, so don’t bother”.
Dennis Ritchie said that “UNIX is very simple, it just needs a genius to understand its simplicity”. I don’t think it would take a genius to understand the simplicity of Unix, but it does require you to have a mental model of the system Unix runs on and what Unix’s abstractions are actually abstracting over.
Instead of passing judgements on which one of the Bell Labs gang and its critics are right, I think that it’s important to think of the design of computer systems as the constantly revolving field it is, with movements and counter-movements, instead of a monotonic approach towards an ideal state. Indeed, Unix and C were created as reactions against Multics (and presumably PL/I). Go was a reaction against C++ and Java. Rust is still too young to have its “Bell Labs gang” style reaction, but it would be very interesting to see one in future.
The “worse-is-better” philosophy described in Richard Gabriel’s essay [0] actually prioritizes implementation simplicity over interface simplicity. Maybe GC and goroutines don’t reflect this, but you wouldn’t expect every principle to be operative in every decision.
[0] https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/Misc/Worse-is-Better.pdf
Thanks, you are right that it was Richard Gabriel who coined the term.
But I quibble with the characterization that the Bell Labs gang prioritizes implementation simplicity over interface simplicity. Unix’s
fork()was not simple to implement (at least not a performant way) but it presented a simple interface for controlling process creation. Neither was a single-root filesystem at that time, but again the interface is relatively simple. C’sprintf()is also not simple to implement but the API was nice and simple (for the time).Yes it was. The systems that it was designed for had one resident process in core at a time. Context switch meant writing that process out and reading another one in. With fork, you just skipped the second step, keeping the existing one and just updating some kernel data structures to say that this is really a new instance. It only became difficult to implement on systems with MMUs and multiple resident processes, but that was a decade later, by which time it was ingrained.
I stand corrected then, perhaps Go shifted a bit more in the direction of interface simplicity.
His example in the essay is how interrupted system calls are handled. In the “better” OS, there is a bunch of tricky work to do state switching in the kernel so the userspace API sees a simple call-return API no matter what. In Unix, the OS just throws everything away, returns an
EINTRerror, and expects userspace to put a loop around every system call so it can retry.BTW, in early Bell Labs Unix, I’m pretty sure the implementation of
forkwas quite simple and performant, because there was no virtual memory. The performance tricks arrived with BSD, if I recall correctly. So that actually is an example of choosing a worse interface (forkis really quite a bizarre API compared to “create a new process”) for implementation simplicity.I’m still not entirely sure it isn’t some sort of epic joke.
https://rachelbythebay.com/w/2014/08/19/fork/
Abstraction and software in general is about creating a relatively simple interface with a relatively complex implementation. The philosophy of prioritizing implementation simplicity only makes sense within a spectrum of decision defined by other factors, so examples only make sense in comparison to some other system or group of engineers with similar goals and constraints.
I haven’t seen that happen in the years that I’ve been around, at least. My experience with ambitious systems of that sort is:
In practice, I would generally rather have something that attempts less, that I can use as a solid part of the solution to my problem, than to use a library that attempts everything, which almost-but-not-quite solves my problem, and which has such an extensive vocabulary of its own special abstractions that interfacing it to something else to provide the missing part requires reverse-engineering the authors’ brains.
This is an understandable viewpoint, but Go’s design is not simple. I usually start with the numeric types – which hardware was it designed for, and what safety properties are its abstractions designed to protect?
I don’t understand what your point is, but I suspect you are using a more specialized definition of simple than the workman definition. In other words, talking past the Op.
I typically assume that “simple” and “complex” are relative to the speaker’s experience. Let me sharpen the point: on which hardware does Go’s assortment of numeric types make sense? Are they abstracting over the hardware? I might pick on e.g.
complex128, which I don’t think is a native type of any hardware, oruintptr, which enables unsafe actions that undermine the GC’s safety guarantees.Neither of those types are commonly used in production Go code.
uintptrdoes no such thing. You need to import theunsafepackage to do anything unsafe.Most modern CPUs have registers that can fit a complex128, can add or subtract them in a single instruction, and multiply them in a handful (maybe 4). Division is more complicated, but then again I’ve worked with CPUs that lacked instructions for dividing integers, but I don’t think many people claimed that int8 wasn’t a native type :)
for me, the most exciting thing about golang is that i can easily walk junior engineers through a codebase with 0 prep. i love accessible code that doesn’t require a krang-like brain to intuit. rust is so non-intuitive to me that i’ve bounced off of it several times, despite wanting to learn it - and i’m a seasoned engineer!
i didn’t go to school for CS, and i don’t have a traditional background - there are a lot of people like me in the industry. approachability of languages matters, and golang does a fine job.
it obv has warts. but between the inflammatory title & the cherry picked “bad things”, the article winds up feeling really cynical, and makes me feel like fasterthanli.me is probably cynical too.
continues to write fun, stable code quickly in golang
What to you makes the code written in Go’s monotonous style fun?
For me—and for most who choose Go—the fun lies in watching your ideas for software come to life. Go is so easy to think in; it enables building stuff without having to fight the language.
I’d rather work with a stable language, so that I can be creative in the approach to the problem (not the language expression) than a language where I have to spend significant valuable background mental effort on the choice of words
And you don’t mind having to spend valuable background mental effort on typing
if err != nilover and over?I do mind, but I think you can argue it produces low cognitive load
The Rust folks had a similar issue with returning
OptionandResultand fixed it with the question mark operator.The
Errortype can be named anything, but the community very quickly settled on naming iterr, following the convention started by the standard library. The language designers should have just made that the default, and created a similar construct to the question mark.after the first few times, it comes naturally for me and i don’t really think about it much. In fact, in situations where it is unnecessary I often have to stop and think about it more.
bc go code mostly looks the same everywhere thanks to
gofmtand a strong stdlib, i spend a lot less time thinking about package choice & a lot more time doing implementation. yesterday i wrote a prometheus to matrix alert bot from scratch in 30 minutes - i spent most of that time figuring out what the prometheus API layout was. now that it’s deployed, i have faith that the code will be rock solid for basically eternity.what’s not fun is writing similar code in ruby/python and having major language upgrades deprecate my code, or having unexpected errors show up during runtime. or, god forbid, doing dep management.
part of that is thanks to go’s stability, which is another good reason to choose it for the sort of work i do.
having a binary means not having to worry about the linux package ecosystem either - i just stick the binary where i want it to run & it’s off to the races forever.
to me, that’s the fun of it. focusing on domain problems & not implementation, and having a solid foundation - it feels like sitting with my back against a wall instead of a window. it saves me significant time & having dealt with a lot of other languages & their ecosystems, golang feels like relief.
it’s a language created at a specific workplace for doing the type of work that those workers do. Do you think bricklayers worry about how to make laying bricks fun?
That’s why I was asking why they found writing Go fun, it wasn’t out of nowhere. I have received some satisfactory answers to that question, too.
If it was possible for brick laying to be fun, I’m sure bricklayers would take it.
Fun fact, Winston Churchill took up brick laying as a hobby. He certainly seemed to think it was fun!
For those looking for the lies, they’re listed at the end.
While I don’t disagree with most of the article, I think it’s worth stating the contrapositive case: golang is a language optimized for cranking out web services at Google with moderate to low business logic complexity where correctness is generally pretty ill defined. Tasks very similar to that are also suitably cranked out in golang. It’s not perfect, and certainly there are certain kinds of error that you’d like to be able to prevent or predict (for example with integrated modeling). I think of it as a compiled python2, with the additional goal that there really actually should only be one obvious way to do it, and readability is achieved by explicitness even when that is very, very verbose. The further you get from that kind of work (need for rich data structures, non-networked boundary, crappy network, complicated concurrency, real-time and high performance work, numerical work or any other domain where expressiveness is a huge performance or productivity win), the worse golang will fit your needs.
I don’t consider golang a joy, but I think it is largely successful at fulfilling that mission. Not optimal, certainly, but successful. And there’s a lot of code to be written that largely slots into the golang shaped hole.
Somewhat ironically, it looks like Python is overtaking golang on the safety story with a much more expressive optional type system.
As a practical marker, I think the bugginess of kubernetes shows that writing kube bumps up and slightly over the complexity level that golang is fitted for.
This is largely what my view on Go has evolved to over the years since it fully addresses the problem domain that it’s designed for: make a language that’s as simple and explicit as possible with the goal of trivializing the individual programmer’s impact on the project. If any given Go programmer is just as useful as any other and the language is easy to pick up in the first place, people are entirely expendable. It addresses Google’s internal needs perfectly, it just so happens that people outside of Google also use it. However this doesn’t free the language from criticism as it’s still rather… shoddy in the design realm, but any of those criticisms would fall on deaf ears. A much more relevant (and concerning, in my opinion) criticism is on Google’s approach to people and the use of a language to commoditize them.
This has been a corporate fever-dream for decades, at least. They tried to do it with Java, too.
I had a professor who taught a software engineering course. This was a dude who had worked in industry. He claimed that eventually, programming would be similar to a food service job. A designer would make some UML models and stuff, and then hand them off to highschool kids who would write the code for minimum wage. Among the guy’s other ludicrous claims: eventually we’ll be writing programs in XML! I thought he was kind of a silly assclown. He did teach an excellent course on databases however.
We kinda do! The actual technology is XMLs easier-to-type cousin YAML, but we absolutely write programs in a data structure language.
Also XAML.
Yeah, and we absolutely hate it (looking at you, Ansible)
Indeed we do (looking at you, CI files)
Shit, that, too. Not only is it programming with yaml, is programming a sort of state machine you can’t test anywhere other than in production.
I don’t think I have a truly love-hate relationship with anything as much as I do with CI
Point well taken. I’ve written my share of ansible config. In another sense, the “equivalence of code and data” sense, a data representation language is just code for a very limited kind of machine. We hope it’s limited, anyway! TCP packets are programs that run on the machine of a TCP stack.
I don’t think that’s what he had in mind. I think he was imagining something more like C++ but with XML tags and attributes to represent the syntax.
Replacing scarce and hard-to-train programmers with easy-to-learn languages or tools has been a theme for as long as I have been in the commercial software development business (late 90s). The craze for ML-assisted development is just the latest iteration of that.
The opposite of this is if every programmer feels like an amazing magician and writes their own DSL in Common Lisp and uses macros everywhere.
This can be good for the self esteem of inidividual programmers, but is horrible for hireability, teamwork and being able to tell what a screenfull of code does without extensive digging.
This was always my suspicion about Go. The commoditization. On the positive end, that could be a strength for open source projects as it lowers the bar for participation. I can only imagine how CoPilot and the likes will amplify this over the next coming decades.
My strong intuition within a generation is that most ‘coders’ will only submit pull requests (or issues) for features, fixes, etc., along with some bots, and the new paradigm of social-driven automation (hybrid of human coders and AI bots) will update the PR by generating the code and even the tests. It will be as much an art as a science in submitting good issues or PRs that get the results you want. Whomever ‘fulfills’ the issue or PR (updating it to completion) will be rewarded for it, sorta like a bounty or something.
For better or worse, this describes a sizable percentage of software projects.
Sounds like the same pitch as PHP and look where the public opinion of that language went, fractal of bad design and all that.
Sometimes it feels to me like Go is the place where people can follow all their old PHP practice at slightly better performance and legitimized by the fact that it’s “the language Google uses internally”
PHP has it’s reputation, and still runs the majority of the web. For better or worse.
I wonder if in ten years people will look at Go like we look at PHP now.
I really don’t like go. For the reasons the OP lays out and more. But your contrapositive case is dead on.
When you have to crap out web services with stringy typing, json, and lack of abstraction - go is fine.
And for completeness - the go linker and it’s ability to ship static binaries trivially is fantastic.
Go is a good, productive language ¯\_(ツ)_/¯. The ease of deployment alone is extremely useful
I wrote a book about Go around the time of the 1.0 release and, while it’s not the worst language in the world, I honestly don’t understand people who like (rather then merely tolerate it). The big thing that astonished me is summed up in the audience question near the start. For safe concurrent programming, you need to enforce one invariant: no data structure is both shared between units of concurrent execution and mutable. Erlang does this a very simple way: no data structures are mutable except the process dictionary (which can’t have a reference to it taken and so can’t be shared). Rust does this in a more complex way via Send and Sync traits to express ownership transfer or a relaxation of this rule for when you have some other mechanism to permit safe concurrent mutation. Go makes it trivial to accidentally share objects between goroutines and provides absolutely nothing in the type system to prevent accidental concurrent mutation. The ASPLOS paper a few years ago that showed large numbers of concurrency bugs in Go programs was absolutely no surprise.
I want a language that makes it hard to introduce bugs. If it must make some categories of bug easy to introduce, I want them to be ones that are easy to debug. Concurrency bugs are the hardest to debug because they often go away when you add any kind of instrumentation. You can avoid them entirely by avoiding concurrency (which is fine for a lot of use cases. See Python, for example), but if your language is going to encourage concurrency then you absolutely must have something in the type system that lets you statically avoid concurrency bugs.
Weighing the pro and con of something as multifaceted as a programming language is not the same as lying. Everyone, every team must learn, practice, decide, and reevaluate their decisions. I appreciate this author’s attempt to provide their own insight into this challenge even though I don’t share the many of the same concerns or conclusions.
This article was submitted before, but was folded into another submission so it doesn’t show up as previously submitted:
Every incident makes me hate Golang a little more
This deserves a rant tag. Legit sucks that Amos felt like needing to go so hard on this topic, and when this first circulated months ago it generated so much of a mess.
This is a weird way to measure a language. Look at GitHub and how productive a single developer can be with Go. Some programs are editors, computer games or command line utilities. Not every program needs the type of defensive programming the article promotes.
This is true. But not all projects has this particular type of inherent complexity.
Successful projects, quick compile times, an ecosystem that lets you add a dependency that works, not having broken code just because 3 years has passed; these are also nice things.
One should not close the eyes to the quick development cycles and low cognititve overhead experienced Go developers can achieve, either.
You could apply this argument to literally any language.
No, you couldn’t, and there is no comparison. Look at active repos in Common Lisp, Scheme, Forth, Smalltalk, Ada, you know, the languages everybody talks about nicely. Then look at Go. If there’s 2 types of X, the ones everybody complains about, and the ones nobody uses, Go is certainly in the first group.
Go is very popular, and getting more popular, and there is no denying it: https://madnight.github.io/githut/#/pull_requests/2022/3. Tons of people are learning go in their free time and using it to get stuff done, because it is easy to learn and easy to get stuff done with.
Now you’re arguing by popularity, which is a fallacious argument and a very different thing than “you can get stuff done with it”. Clearly you can gst stuff done with the other languages too.
Github and the popularity of the language in the platform proves that many single developers can and are getting stuff done with it. Which is a proof that you don’t get with other, unpopular languages. You might claim that they are just as good, but you are not getting proof of it from github.
Popularity is not a good measure of anything. Tobacco smoking is popular. Eating Tide-Pods used to be popular.
Tobacco smoking and eating tide pods do not produce anything (well, except damage to the person doing it). I think corasara is implying that projects on github demonstrate that people get stuff done with Go. To put it differently, TikTok and Insta measure popularity. GitHub showcases code that actually does something (well, most of the time). And the fact that there are many repositories on GitHub implies that many people do get stuff done with Go. Now, there might be an issue that users of other languages do not advertise their work on GitHub…
My point is that the people that get stuff done with Go could be just as well getting stuff done with other languages, but most of them haven’t really tried many other languages besides the ones that are obviously worse for productivity, such as C.
I think this is wrong. I think developers that have tried many different programming languages are the ones that most appreciate the things that Go gets right.
This belief reveals a great deal about you and I’m not sure reflects anything true about Go programmers.
Wow, look at the replies you’re getting. These people are coming out of the woodwork to defend their questionable career choices. One could base a whole career on Go criticism.
This is ridiculous. You are comparing a decade of individual’s spending their rarest resource, their free time, to a claim that a 4chan meme was real and chemical addiction.
Get over it, some people use go because it’s the best choice for them.
This is not your schools debate club.
How do the people know whether it’s the best choice for them?
Quite good article, as usual from this author, but could probably use a slightly less aggressive title and tone. As it is it’s not quite a rant, but it probably won’t convince anyone whose mind isn’t already made up. But also whenever you keep hearing the same arguments about something it saves a lot of time to be able to put down all the responses in one place and just refer people to specific parts. Rehashing the same arguments all the time is tiring.
While indeed a terrifying hack… The linked article is also a pretty basic work-through of what it takes to make different calling conventions match up with each other. What do you think your compiler and linker do every day of the week? The only difference is they know what they’re doing before hand. The terror mostly comes from breaking Go’s calling conventions for its own good.
Few words ever do. The real target should be the undecided, and I felt the article did okay on that front.
Uh, I am not sure if I disagree or not with that. I can see young, naive people reading this and saying, “omg I better not choose Go”, but if they ran into a pro-Go article first, they would do the opposite. So yeah, if inexperienced are the target, it might work.
To me (not working with Go, but being experienced in other languages), it looks like a lot of cherry-picked straw-man examples. Not all of them, but many of these things are either one-sided or not relevant at all.
E.g. from the list at the bottom of the article:
What kind of argument, is that? Who, apart the aforementioned juniors, picks languages and technologies based on such arguments?
Again, a lot of people picking go say “I like the async runtime”, but i don’t think people tell themselves, “GC will make up for things for me”. Basically all the points are mixed with some good examples and explanations, but the premises and assumptions, and the “we tell ourselves these lies so we can keep using Go” is simply not proven to me, and the lies are just made up to fit the narrative of bashing Go.
And this has in turn made me think that the author is clearly smart and good, but they are not writing anything for me, but to promote some agenda that they have.
So again, I’m not sure if the article can or cannot convince readers of anything, and what is it that it is convincing.
I don’t think the article is self sufficient, you need other sources to make up your mind. Personally, my mind was made since I learned Go didn’t have generics, which in my opinion is unacceptable for any garbage collected language conceived after Java added them. And sure enough, a couple other serious flaws came up, that showed that indeed, they did ignore the last few decades of PLT research.
As far as I can tell, Go’s legitimate niche is narrow enough that I wouldn’t use it for anything substantial. Same as Python, actually: I use Python often, but never for anything big. Either it has a library that does what I need and my program can stay very short, or I’m using its bignum arithmetic to prototype elliptic curves stuff.
It sneers at arguments by popularity. In fact, I suspect that Go would never have caught on if people couldn’t say “Google uses it”. Thing is, even if it’s good for Google, Google is an extremely singular company. Programmers are extremely unlikely to work in a similar enough setting that looking at what Google uses is a good heuristic.
A good chunk of the great many people that use Go and came to regret it? As far as I know juniors don’t pick languages in the workplace, that decision is given to more seasoned devs. Senior folks still make mistakes, of course, but here I feel like many of the flaws that ended up biting them could have been anticipated:
I suspect corners were cut instead. Prototypes were written, and it went well enough that they found their way to production before the language could be properly evaluated (devs were stuck in honeymoon phase, management wanted to ship, deadlines were tight…).
Go’s GC has an unusual performance profile. If I recall correctly, it optimises latency at the expense of pretty much everything else. I guess that means it has more overhead than other GCs, but the low latency remains very useful for real time networking… which is precisely Go’s niche, so not only people could tell themselves the GC makes things up for them, if they use Go for its intended purpose they could even be right.
I would like to problematize the idea that an aggressive tone would prevent people from being convinced. Are our brains really that weak, that conclusions that we should derive from facts are actually a product of the tone with which the facts are presented?
Yes. People get defensive when they feel attacked. Unfortunately this is better documented in books about romantic relationships than any material directly relevant to software engineering.
Some people thrive in environments open to hostility. OpenBSD and the culture Theo de Raadt cultivates around it proves that. But most people aren’t like that.
This is tone policing, though. A less aggressive tone is usually ignored; it’s common knowledge in PLT/PLD circles that Go is unacceptable for typical tasks, but because it’s said politely, it is not taken seriously as a rationale for discarding Go.
Personally I think the original article is fine. My problem is with this nonsense notion that people who don’t respond well to aggression are weak-minded. In the software community that attitude is often used as a bad faith justification for being an asshole.
I’ve also seen people using the tone of the speaker/writer as a justification to ignore their core points, which is lazy at best. I’ve seen people dismissing well reasoned, level headed, professionally delivered arguments just because the same author used a more aggressive tone than they are comfortable with elsewhere. And sometimes, the aggressive tone is actually justified. Not as an argument unto itself, but as a way to stress the importance of the issue.
Sure, people who are personally attacked can’t be expected to respond well. I know exactly how that feels. But I’ve also seen people responding poorly to other things. One striking example from a year ago went as follows:
Sometimes, merely pointing out that there is no God will be perceived as an aggression from some religious people. It’s really not. It’s just an attack on their mistaken belief. Yet I’m pretty sure many religious readers would have flinched a little at my exact choice of words right now. Maybe perceived it as a too combative, perhaps even a little aggressive. But that perception should not be used as an excuse to respond poorly. That would be weak minded.
Terminals, eh?
I hesitate to confirm or deny anything here, because it would shift the discussion to the particulars of whether this tone or those words were appropriate for these circumstances, and the technical discussion about whether you believe Team or Mr Aggressive.
I did forget point 8 though: about a year after the events (a couple months ago I think), Team ended up implementing the fix, or something similar enough that it achieved similar effects.
You did say “yes,” seemingly agreeing that being swayed by tone rather than facts is a weakness (at least on questions of engineering). And you seem to imply here that this is “not responding well to aggression,” which is about the same. Sure this observation can be used for ill, but I don’t see why anything said here warrants an aggressive response.
It is possible to make one’s statements aggressive, passionate and convincing without being a douchebag. Hurting people because it’s a convenient shortcut for getting attention is pure laziness.
So a secret Google agent could easily psyop you into liking Go by writing an overly aggressive rant against it.
No, that’s absurd.
It’s a hypothetical.
No, it was a feeble and extremely transparent attempt to mock my position. It doesn’t even follow from anything I said, you’re just saying goofy things to paint me as “weak minded.” It’s absurd and childish.
I’m sorry you read it that way. I wasn’t the one who made personal insults though.
Neither did peter.
It’s right there…
Yes, without question.
(Edited out a glib intro)
If your objective is to try and convince pretty neutral people that something is “bad” you can just share what info you have. At one point implying people are stupid will indeed make the people whose stupidity you are implying feel annoyed at you!
Would you give the time of day to somebody calling you an idiot? This is obviously not as direct, but it’s on the scale.
I wonder if Go is an elaborate troll, the punch line of which is creating a successor called GoTwo.
<GoTwo is introduced.>
“Wait, this language doesn’t have generics either!”
Rob Pike: Go Fish.
The key point in this article, buried at the end:
This ranges from the near invisible level of our languages providing functions and stack frames so we don’t live in a sea of gotos, to the micro level of not putting your data in a corrupt state to maintaining invariants of concurrent systems to substituting modules in different members of a program family seamlessly (e.g., I want to attach a toy implementation of X for local dev or testing instead of the full X without having to do lots of plumbing in my code).
I like Go. It’s a simple language, every project has a similar code style so it’s universally easy to read, it’s very easy to build production applications which have almost no dependencies, the list of positives goes on and on…
Every language has issues. I also like Ruby and that runtime has big issues too. Languages are tools and tool usage is always context specific.
But I have a commercial product written in Go and I’ve never had a large scale project like it that requires so little maintenance. It just continues to compile and work, year after year, without any effort on my part. This is the exact opposite of something like JS apps which need constant updating to giant dependency trees to keep them modern and working,
A lot of people seem to focus on the pros and cons of the Go language itself, which unquestionably does have some polarizing design choices. But to me the productivity people get with Go seems more to do with the system around the language: the standard library, module system, single-binary deployment, tooling, and most importantly stability as a core value.
In use it feels like a system built by hardened cynical engineers who want the tooling to “just work” and get out of the way of their code. The goal is not to present “simple” or “magical” facilities, but to build everything with understandable mechanisms so you always know what’s going on under the hood.
The oft-quoted comment by Russ Cox about how it’s to enable novice programmers makes no sense to me, as the assumption everywhere in Go seems to be that you will constantly be aware of the ways you can screw things up, and read every word of the documentation before using a library.
This is my experience. While the language might not have every feature that I’ve dreamt for, everything I’ve built in it continues to work,easy to setup CI for, easy to debug, profile, and now fuzz too. The tooling is top notch.
There’s a lot of problems to solve in software engineering. The Go team have chosen a subset that are pragmatic.
Then what’s the point of creating a new language instead of creating good tooling for an existing language?
They aren’t independent. If you look at the design of Go, there are decisions in the language that enable the tooling, and vice versa. As an obvious example, the namespace for modules is literally version control URL prefixes. As a counterexample thought exercise, imagine how you’d make “good tooling” in this sense for C++ without being able to modify the language.
Uh, what? This is something that almost no language with real users can enforce (Rust being the biggest notable exception). Even in C++, while you can get some safety improvements in this direction with dtors and some attention to which constructors you do or don’t provide, the compiler can’t actually tell when you’re done with something that has reference semantics, so there’s not really a scenario where “nobody can touch it again, ever.” It gets very uncanny valley and into the territory of “I would sleep better at night if this would panic.” And at time of writing every other language that does this right is really, really obscure
sub-structural types very much were “new stuff” when these semantics were stabilized.
I agree with most of the article; I still like Go, but it is a deeply flawed language. And I think zero values are the worst thing about the language. But this was a weird assertion to make in the midst of all that.
I actually find go very useful
Lies…
Lmao
I agree with that statement, and I think it’s a lie people tell themselves.. about Python.
I also agree with it regarding Go. There is way to many people that simply favor very different languages. One can see that by how so much Go code coming out of Google is C++/Java/Python style. Folks, don’t get Go jobs when you prefer to design software differently. You’ll be angry about how Go isn’t X and Go people well be angry that code isn’t idiomatic.
On a related note. If you want to program in a language cause Google, you should do Dart. and be happy with it. (/sarcasm)
If you feel the need to write about some language you simply don’t write and whose design choices you don’t understand or agree with, you aren’t elitist or a jerk, you just seem to be really bored and unsure about what to do with your time.
That’s a really odd thing to say in my opinion. There’s quite a few other languages, also in the functional programming realm for example. I don’t really know many people that use Go for these reasons alone. Sure they pushed the concurrency/parallelism part a lot initially, maybe too much, but people stopped that, because everyone overused it. Overusing being use cases where it doesn’t make sense or even is counter-productive.
I think something like this is often mentioned. It’s a general theme with languages that don’t try to copy C++ or Java (with nicer syntax or something). Having different view points/design decisions from you/the language you like isn’t a design flow. It’s the same with operating systems. They have different priorities and different design decisions or the are just yet and another “the next Linux/Windows” with little to no innovation.
I think that’s yet another topic that comes with using a language you don’t wanna be using. A lot of the “Odd thing about Go” articles mention something that is either very obvious even if you just started out (reading Effective Go or something done by the initial authors) or something highly un-idiomatic.
It is compared to most other languages. Production software is a lot harder than people tend to admit, which can be seen by pretty much every postmortem out there. When you develop something and it’s not a success or don’t have users communicating potentially big issues you might even know about issues.
Huh?
Ah. Yup. Prototypes going into production. Not sure how it relates to Go.
Huh?
And everywhere it comes with drawbacks, like software having issues it couldn’t have with the interpreted language. And things like libraries not compiling, so everyone is forced to use containers as a hacky workaround. Also all of these languages have lots of libraries proudly declaring “Pure Python/Ruby/JavaScript” as one of their main features. Don’t act like these issues don’t exist.
Or simply not a language the author would want to use. The team also did Limbo and Newquask. Languages with similar design choices, that didn’t end up being popular, because there was no big name company behind it.
Isn’t that basically the story of Python, C, Linux, etc.?
Something I see in a lot of this articles as I mentioned is doing very strange things and then blaming the language. It’s the classic “JavaScript has === for comparison” argument, where one simply disregards the language, acts like it’s a different one and complains that it’s not. I think that’s a big problem with language design. So many new languages are C++ with syntax for something odd improved and some cruft removed. That’s fine, but in the end you are still doing C++. Even more often that cruft is replaced with some other cruft very, very rapidly.
For now now Go has mostly avoided that, even though I think Google is pushing there. Google seems to be the place where everyone would rather use Java or C++. Not to bash them, but they pretty much made the opposite design decisions on everything Go did, so it’s gonna be hard.
I get where that sentiment comes from though. Sometimes I feel like the only person developing in Go despite Google and not because of them. It’s really annoying that they seem to have taken a stronger grip on the project, which can most prominently be seen comparing go.dev with the old golang.org and some library stuff.
But basically that’s the response the author expected, minus the “large company” argument, which is silly in every context. Large company can also mean “they have three teams playing fire brigade for that project” and “nobody dares to write a better solution, because it might break something”.
If the author reads this: The link to the language designed isn’t working because of a bad certificate. Nice website though! :)
Alternative explanation: sometimes people try to vent complaints when they are exposed to something that they don’t like. When the complaints are rebuffed repeatedly they can build up and become more frustrating. The result is that the person isn’t just responding to the object of criticism, but also to the culture around it. People react strongly when they feel like they aren’t seen or heard.
The Go community comes off a little hard headed sometimes and I think this draws out sharper criticism.
I get that. However I don’t think it makes sense to criticize Go (or any language) to not be like another.
It happens way to often and what that leads to is that over time languages turn into the same kind of mess with tons of deprecated old style features.
That’s I think why things are seen as hard headed. Go developers (as in users) that actually like the language don’t want it to change, they like the trade-offs made. They recognize that the language has sharp edges, especially when using it wrong, but they like the fact that this makes it so that you can be aware of all the sharp edges.
In many languages there’s fewer sharp edges on the surface but you can’t to be aware of huge amounts of subtle details and importantly also their history. This means that even after years of development you will still learn new things about the language itself
I actually think that’s why some people enjoy very old and minimalist language. I think it’s also why developers actually enjoy new languages. Not because they bring that cool be feature, but because they don’t have that history of language changes you kind of have to know to really grasp the language. And that history is being created by good and smart ideas on how to make the language better.
Features even ones that make something easier do add complexity. There’s many talks about Go being “finished” from years ago. This is kind of a way to say that the authors won’t change it. That’s a feature of the language.
It’s fair to say you don’t mind it and it’s fair to say whatever shit the language, but wouldn’t a better way be to fit example use C# when that’s what you want out of a language instead of complaining that Go isn’t.
I think that hard headedness should show that these things are the way they are on purpose.
Personally I’m happier about “Go sucks because X, so don’t use it” articles than “Go sucks, this skills be changed” overs, because the first might tell you to not use it if you don’t like the design decisions, whereas the latter wants to ten the language into another.
I think there’s enough languages out there that would better suit the need of the author of the article. This is what I meant with the “bored” stuff you quoted. Work with languages you like more and if your boss forces you to use a language you fundamentally disagree with even after taking an actual close look on it consider changing to something you enjoy or potentially consider making your own thing. LLVM is great, everything is a HTTP API, WASM allows for interfacing with others to some degree so it’s relatively unlikely that you are really forced to use a certain language.
Sorry that was a lot of words, I just hope it helps to not misinterpret what I’m trying to say.
This is almost exactly what I feel about the article, the author is bored. You offered good questions to every argument there. Not saying Go is or isn’t this, just pointing out the things about the article that are weird.
The article may have a certain hidden purpose, but it’s really not showing what it’s claiming to show.
And Rust. And C. And C++. Etc…
Indeed. I really only used those languages as example. They are matters of taste, philosophy, design choices and even culture to me. People are different in how they think and approach stuff so of course they’ll use different programming languages to work with even when the goals are identical.
Just how companies are successful with different ways of managing tasks, doing business, communicating, monetization models, editors, office suites and so on. And time and luck also play roles. I think people very much overestimate the role of technologies/products used for the success of a a product.
I’m learning Plan 9 at the moment (specifically, 9front) and it’s fascinating to see the philosophical similarities between Go and the Plan 9 dialect of C.
http://doc.cat-v.org/plan_9/programming/c_programming_in_plan_9
At the example with Params struct author lost me. This argument seems really odd.
The Go compiler can’t tell the difference between “I am saving some typing by letting
bdefault to zero” and “I forgot to update the callsite to passb”. This is because everything in a struct is optional, defaulting to the “zero value”, which may or may not be what you meant (or even be a meaningful or safe value).As always with Go, the answer is “just be careful”.
The answer for me has become - write a NewFoo function that properly initializes the struct in a correct fashion, erroring if need be- never, ever, doing a direct struct init. Kinda crap, tbh.
This pattern is also encouraged in Rust, and one of the reasons it’s encouraged in Rust is because if you do choose to initialize a struct literal at its usage site, if you modify the struct the compiler will complain until you modify the struct literal initialization at every call site, rather than silently doing a possibly-incorrect thing like Go seems to do.
Always key-ing literals helps here. Not enough necessarily, but helps. I would not be adverse to a new Go version allowing some other default to be tagged to fields in a struct.
I think there is an argument to be made that what is and is not idiomatic Go is well known enough that checks from the vet linter could be moved into the compiler with a flag as a compile time error, and some of the uncontroversial lint checks that exist in the community be adopted into vet. The compiler could be helping more without language changes. I would be very happy for unkeyed literals to be a compile time error.
Wow look at how many comments are in this thread. Go criticism really strikes a nerve in some people, eh? As far as career-promoting blog posts are concerned, this is state-of-the-art. I’m sure OP will get a lot of clout from this.
I wonder how this can be reproduced? Because this clearly isn’t like, some air-tight case against Go. And OP is clearly heavily biased towards Rust which has its own share of problems. I won’t enumerate the reasons why because I don’t wanna debate within an upvote-ordered comment tree (pretty bad medium for deep discussion IMO).
Is this guy famous or something? Or is this type of rant simply a honeypot for commenters?
I shared this article because the content is interesting and germane, and the author is reputable. I suppose, if I have an ulterior motive as a language designer, that I shared it because I think that it is important to keep in mind that most programming languages are completely unsuitable for serious work; examples of bad programming-language design are important to discuss.
I am always amazed at exactly how vociferous the folks are when they choose to defend programming languages; our tribalism is intense and we have no idea how to moderate ourselves.
Not to mention that every language has a “sweet spot” — a product-market fit if you will — but there are always people who want to treat their favored language as universally superior. Go has an unusually pure cultural and technological sweet spot, and if it works for you to live in that spot, it is actually quite fun. But it’s far from universally applicable, from both a technical and personal perspective.
What is “serious work”, though?
But anyway, I think people are not being vociferous here, the article seems to be. To me at least.
How? Nobody who decides over people’s careers likes a troublemaker, not even when he causes trouble in a blog post about a programming language.
I’m going to link my comment from elsewhere in the thread:
https://lobste.rs/s/deni6q/lies_we_tell_ourselves_keep_using_golang#c_21wyay
I don’t think it’s Go criticism, it’s just unfounded, or at least, unexplained criticism. I’m not even using Go, and I think the article is part-rant, part-troll, because it’s not making sensible arguments to me.
This article mentions research about type systems. Anyone can recommend a good read on this topic?
What would you want to read on? Why not using bleeding-edge type system research results in a new language a bad idea? I don’t have a clue.
On the other hand, I can make that claim from the article even “stronger”. You can easily show that Go creators ignored research from before 1970 - Algol68 contains sum types/tagged unions.
@tt Types or no types is still in realm of holywars among my fellow developers - where everyone religiously defends their position. My interest is mainly to understand what research is saying about types in programming languages.
Have you seen https://danluu.com/empirical-pl/ ?
Incidentally, it occurs to me that playing badly with other languages is probably a design choice: it makes it much easier for google to rebuild the entire library supply chain from scratch if it’s all in one language.
This has the benefit that you can patch the source of a dependency and have all your software benefit from it, without needing to make dynamic linking work, and makes it easy to know if your deployed artifact came from a build that used the patched version.
Playing badly with other languages has been a big blocker to internal adoption at Google there are tons of libraries/systems that just don’t work in Go.