Why do so many go devs feel the need to make statements like this. Go has issues, the are well known and easy to work with/around. Every language has these, every single one.
Also GO, and rust (and zig for that matter) have all sort of found their lanes at this point. Candidly the constant comparisons between the two (when they are much more complimentary) is getting tired.
- Acknowledge the common criticism
- Defeat it with appropriate common retort, or make a small concession
- Proceed with the meat of the argument with your most common opponent "disarmed"
Is it? Because I dont see JS or python apologists? Did I miss a corresponding lament about rust compile times in the article?
Also bring up the GIL, and you'll be told how Python is implementation-agnostic.
At least for Python it's some combination of: I know Py3 was a nightmare and packaging in general is a dumpster fire, testing is a constellation of incompatible tools and practices, MyPy and progressive typing is an embarrassing half-baked mess, and deployment is only really possible when you bundle an entire system image into a container— but hey, developer productivity right?
Like with Python and ML.
The optimal amount of bullying towards Go and its proponents is always “more”.
1. Team uses some interpreted language. This language is fine for most of their work, but causes performance problems and/or the team needs to do something performance sensitive.
2. Someone on the team proposes Go, often because it solves the performance problem - and is very simple to use. This proposal invites suggestions from the organizations programming language experts leading to "let's use lang X" suggestions. Often these suggestions have recommendations based on advanced programming language features such as high-order types, functional paradigms etc.
As Rust has been somewhat popular for backend services, you will find many suggestions of "let's use Rust." These discussions can often be less than civil. As I've aged - I've moved closer to the advanced language features camp - but I'd doubt that this is actually beneficial for productivity. It took me 3 attempts to learn the language and 5 years for Rust to feel productive - now it's my preferred language for side projects. Go took less than a day to pick up.
This is the bit people keep overlooking (maybe intentionally). Yes you, polyglot coder who knows 15 different programming languages and has 15 years of experience on the field can learn Rust in an afternoon and do a flawless solution on Advent of Code with it while learning.
But 99% of the people working in software (you know, all of the people outside FAANG and F500 companies) know exactly one language and have no interest in learning a new one, especially one that's really complex and full of fancy features they don't know what to do with.
Rust, on the other hand, is a borderline research language that was built to support Servo, a web browser backend— literally among the hairiest of sofware engineering problems in existence. It gives you a lot of "safety" but at the cost of having to consider issues that most developers never think about.
This is not to say that Go is for dumb programmers and Rust is for smart ones or anything of that sort— just that despite years of evolution, both carry the DNA of their inception, and it shows.
Go ahead and say it; I don't mind being the dumb programmer who gets shit done.
After all,
> Rust, on the other hand, is a borderline research language
It's ironic that the "smart" programmers are using their new and novel language to mostly rewrite existing stuff, while the "dumb" programmers were delivering new and novel shit using the "dumb" language.
As a very experienced engineer, I like the idea of Rust being a go to for all problems. 10 years ago - I would have hated its complexity and cursed the TL who forced it on my project.
If you stop learning just because you've mastered a language and learning the language was not your actual goal, you've failed. You should continue learning by applying the language to solve problems, which, unless you solve the same things over and over again, offers plenty of opportunities for continued learning.
At this time, due to the social integration of technology the number of people who interact with development has far out paced the number of people who enjoy development.
> they are much more complimentary
If you hate writing code but do it for your job, then you are going to really hate writing code in two different languages with their own syntax and paradigms.
Also, nearly all programming language projects want to be the “everything language” so essentially any language is a fine choice and what it really comes down to is the people who enjoy the work develop “tastes” and “preferences” that they treat as dogma when defending their language of choice.
Imagine bob ross with only one color could still make something magnificent, but what could he do with two colors? You can't have Burnt Umber without some Phthalo Green..
Turing completeness is about computational equivalence. That, fundamentally, any Turing complete language can perform the same classes of computations as any other. It says nothing about substitutability of one language for another within any other context.
I don't wish for this, but sometimes I wonder how different the industry would be today if dev salaries had remained in "respectable but nothing amazing" territory.
Maybe it's just nostalgia goggles, but when I was getting started ~35 years ago, I think it was rare to run into someone who hated writing code but did it for their job. There were other much more profitable jobs for people who were looking to be paid as well as possible for work they hated.
This is a common conceit when writing for the sort of audience who might, for example, nitpick something as utterly uncontroversial as an author's disclaimer acknowledging common criticisms of a language they enjoy working with.
tl;dr: Literally because of people like you :)
Go brilliantly borrowed ideas from Limbo, Oberon-2 and Newsqueak. Throwing that away by polluting with async/await would be reason for riot imo.
Also, was Googling how you execute two things at once then wait on both in Golang, and https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_... came up. This is honestly how I judge ease of use, how simple are answers to simple questions. The agreed-upon response was to use a library.
What you may be getting at is that in an environment like Node.js, where everything runs in a single OS thread and there is no parallelism, there's a reduced need for coordination features like channels (or mutexes), because it's safe to mutate shared memory. But that too is orthogonal to `async/await`: the Python library gevent, for example, uses ordinary blocking function calls while running concurrent code in a single OS thread, making it safe to mutate shared memory; and conversely, C# allows `async/await` to be executed across multiple OS threads, making it unsafe to mutate shared memory.
One implication of async/await is that you need some kind of greenthreading or thread pool because you really don't want to spawn OS threads for it. In JS it's an event loop, Python and (I think) Rust have that too now as a lib, and Golang already has its own greenthreads.
And btw, the reason JS doesn't have threading is because for those applications, you don't need fast communication between parallel tasks like the things Golang is made for. NodeJS supports subprocessing, and the tasks will probably not talk to each other at all, though there's IPC if you really want it.
They wanted to do it in a way that's useful and practical for the use-cases Go is best suited for.
(Still haven't needed generics in any of my Go projects)