We are already seeing the transition happening, e.g. Deis Labs:
https://deislabs.io/posts/still-rusting-one-year-later/
> Given the team’s background in many Go projects, we often hear something like this: “Well, what about Go? Do you regret moving to Rust? What do you miss from Go?” Addressing this in the context of our discussion of Rust felt like a smart decision.
Since I feel like educating you,
> Nothing really, Rust's killer application are domains where using a language with automatic memory management and support for value types isn't an option, trying to use it elsewhere, while possible is sacrificing productivity.
https://news.ycombinator.com/item?id=30391431
That doesn't change the fact that many relevant projects in CNCF are now adopting Rust in their reboots.
Deis Labs, which you also don't know who they are.
Linkerd2 proxy was written in Rust, despite Linkerd 2 being written in Go.
The famous rewrite from Go into Rust done by Discord for their microservices.
The Amazon Bottlerocket uses Rust for large part of the user space, as does Fuchsia nowadays.
Any language can be a systems programming language, even Go, as ARM and F-Secure do with their bare metal Go deployments for microcontrollers.
Go's future is assured, no need to panic.
Why would anyone here have any idea who you are? Your username is not informative, and you don't say who you are in your profile. That's perfectly fine, of course, but you can't then expect people to recognize you as being a particular individual.
You either need the low overhead of no-GC or you don't. If you don't, choosing Rust is a mistake.
---
As for your examples, I'm familiar with the Discord rewrite and I looked up the Linkerd2 proxy. Both programs are low-level services that are designed to handle as much load as possible, so yeah they should be written in a non-GC language.
---
> Linkerd2 proxy was written in Rust, despite Linkerd 2 being written in Go.
From [2]:
"The decision to use Rust came down to several factors. First, a service mesh proxy has some pretty stringent requirements: because it’s deployed as a sidecar on a per-pod basis, it has to have as small a memory and CPU footprint as possible. Because most or all of the application’s network traffic flows through the proxy, it needs to have minimal latency overhead, especially worst-case tail latency."
This should obviously be written in a non-GC'd language.
---
> The famous rewrite from Go into Rust done by Discord for their microservices.
> microservice**s**
Nope, just one microservice; at least according to the article ([1]).
From the article:
"In order to get quick atomic counter updates, each Read States server has a Least Recently Used (LRU) cache of Read States. There are millions of Users in each cache. There are tens of millions of Read States in each cache. There are hundreds of thousands of cache updates per second."
So again, the same exact story - stringent latency/speed requirements.
---
[1]: https://blog.discord.com/why-discord-is-switching-from-go-to...
[2]: https://linkerd.io/2020/07/23/under-the-hood-of-linkerds-sta...
People also use JavaScript, Python and Ruby for use cases that ask for AOT compiled languages
Thankfully no one is going to jail for using a language where it doesn't belong.
That said, Kubernetes isn’t a monolith so it doesn’t need to be all-or-nothing, and one component that would likely be well-suited to Rust is etcd.
Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.
.NET was released with AOT compiler, although it only did dynamic linking (NGEN).
Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.
"just"
Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere.
Open source compilers got popular for a reason.
Now we have graalvm, but getting something running with graalvm is not always straightforward. Even with a full framework like quarkus I have had to use escape hatches @RegisterForReflection. Usability matters. And Go was built from day 1 with AOT in mind.
And lastly Go has better built-in / first-party supported APIs for file I/O, networking etc.. Subjective thing, I guess. When I want to make a database backed website, I reach for spring boot or vert.x; But Go wins for CLI stuff.
I don't know much about C# because I primarily work on Linux.
And, to reiterate, usability matters, defaults matter. Cannot compare 'there existed some obscure vendor who sold an obscure feature in an obscure corner of Europe or Canada', with a mainstream programming language sponsored by a big tech having a good-enough default toolchain adopted by many companies and has lot of jobs;
Then again, maybe things changed in 20 years.
The technology for doing JIT caches on OpenJDK comes from J/Rockit, while OpenJ9 comes from IBM Websphere.
From 2000 to 2009, Red-Hat used to have an Eclipse version compiled with gjc.
Hardly obscure vendors.
Commercial offerings are quite obviously not comparable to free ones.
Seems like Java can't really do AOT, even in 2022: https://news.ycombinator.com/item?id=30444454
Now, I say "really", because this is not about whether you can technically compile Java AOT or not. It's about the level of support - in Go AOT compilation is first-class. In Java, you're stuck looking through multiple second party options, some paid, some with caveats, bugs, etc.
First-class vs second-class support makes a massive difference.
As an example, this is like seeing "Go's advantage over java is its autoformatter - gofmt" and responding "Well, Java has autoformatters too!". Technically true, but irrelevant - in the real world, gofmt is used on 90%+ Go projects. The few Java projects that do use autoformatting each use a different formatter with different sets of rules. First-class vs second-class.
Performance just isn't the problem people say it is. I've done a lot of Python development over the last 12 years, and in that time, I've run into lots of performance problems, but none that would have been easier to solve in Go and none that were particularly hard to solve in Python. In most cases you're just offloading onto libraries (i.e. Pandas or MPT). I've dipped into C a handful of times, but that was more of a "could" than a "had to".
I'll give you a point on tooling--Go's tooling is pretty good. There are a bunch of languages with good tooling these days, but compiling easily to a single binary blob is still a pretty winning feature. But usually that sort of stuff is automated out in the first week of development anyway--is that really enough to justify choosing a language?
Ecosystem? I'm not impressed. There are like 10 languages with healthier, more active ecosystems.
"Simplicity" is generally a pretty bad argument, because what's simple is so subjective. My observation is that simple problems are simple in Go, which makes it a great language for demos, but if you actually try to solve complex problems with it, the language completely lacks features with sufficient abstraction to make complex problems simpler. Where other languages you end up spending 20% of time solving 80% of problems, and 80% of time solving 20% of problems, with Go it's more like you spend slightly less, 15% of time solving 80% of problems because of the simplicity, and then you spend 300% of time solving the other 20% because the actual hard stuff is much harder in Go.
Readability: this sort of goes back to the simplicity thing. Sure, go has less boilerplate than some languages, but that only matters for the simple stuff. If you get into, say, a complex networking algorithm, Go code is going to get lost in all the nonsense of making sure threads share memory properly. I won't argue that, for example, Erlang's syntax isn't a bit ugly, but I can explain my networking code in Erlang to someone who doesn't know Erlang fairly easily because of message passing.
Learning curve: beating a dead horse here, but just because it's easier to learn to solve simple problems in go, doesn't mean it's easier to learn how to solve professional-level problems with go, let alone industry-leading problems which actually constitute the competitive advantage of a business.
Go steals the mindshare because people saw Google were using it and mistakenly thought that if Google were using it, it must be good, even though almost nobody has the same problems as Google.
> So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand.
Just to be clear, I didn't call anyone stupid: on the contrary, I think the developers fell into a trap that is particularly dangerous to smart people: we think that because we're smart, we already know the best way to do things. That's not stupid, it's ignorant. I don't mean that to be insulting although I'm sure you'll take it that way, but I'll say that ignorance is fixable.
It's telling that in your post you just spit out a bunch of buzzwords without any comparison to any other languages, which is pretty much how Go got here: Go developers generally only think Go is great because they've never used other decent languages. If you're coming from C, then you can be forgiven for thinking Go is the bees knees, but that's comparing a 50 year old programming language with a 10 year old one--C has lots of problems, but there are historical reasons for those problems. Go has problems that Gophers don't even know are problems, because they've never spent enough time working in a language that actually solves those problems. And there's no excuse for it, because Go has no historical reason for not solving those problems: a lot of them were solved by other languages before Go existed, and the developers were either ignorant of the existing solutions or thought they knew better (and definitely didn't, in my experience).
I strongly disagree. I've been doing professional Python development for the last ~15 years, and there are some cases where you can call out to C/Pandas or multiprocessing or something, but overwhelmingly you end up spending more time marshaling to C data structures or pickling than you save. Specifically, I've had to port services to use a Spark cluster to offload the processing because even Pandas was inadequate (80th percentile requests would take more than 60s for a CPU intensive task, and they were also blocking the async event loop). This just isn't a problem in Go because (1) single threaded execution is often 100x faster than in Python and (2) parallelization is trivial and (3) you can easily optimize Go by moving allocations out of a tight-loop (no such thing in Python).
> But usually that sort of stuff is automated out in the first week of development anyway--is that really enough to justify choosing a language?
No, I don't think this is a make-it-or-break-it feature, but it's nice. Moreover, there's a lot to good tooling besides static binaries--reproducible dependency management, no need to set up CI to build/publish packages and docs, build systems that don't require scripting or extensive configuration (any Go developer can jump into almost any Go project), dead simple cross-compilation, standard formatters, etc.
> Ecosystem? I'm not impressed. There are like 10 languages with healthier, more active ecosystems.
The way that I think about it is that you're either in the top 5 languages or you're not; it doesn't matter much where you rank in that tier because once you're in that tier you're pretty much guaranteed to get first-class support for APIs. For example, Kubernetes, Docker, AWS, GCP, etc are pretty likely to support API clients in JS, Python, and Go. Java would probably be next and perhaps C# eventually. For the foreseeable future, Rust will probably have to rely on the community to maintain these kinds of packages. The salient point is that Go is in the top tier of languages which get first-class support, not that its ecosystem is head and shoulders above everyone else.
> "Simplicity" is generally a pretty bad argument, because what's simple is so subjective. My observation is that simple problems are simple in Go, which makes it a great language for demos, but if you actually try to solve complex problems with it, the language completely lacks features with sufficient abstraction to make complex problems simpler.
I agree that "simplicity" is subjective, but I disagree that Go is only well-suited for demos. Solving complex problems is pretty simple with Go; however, Go doesn't do well for eliminating boilerplate (local repetition) which is fine because boilerplate isn't where your bugs come from and in most cases trying to DRY up boilerplate leads to code which is much harder to understand (e.g., while a single map()/filter()/fold()/etc is pretty easy to understand, long chains get convoluted fast while a single for loop remains pretty easy to grok (even in Python, we tend to frown on complex list comprehensions in favor of nested for loops). The real value add for Go's kind of simplicity is that anyone can jump into a Go project and write basically the same kind of code that anyone else would write--there isn't much room for personal flourishes, everything is bog standard. Go is bad for "code as art" or flexing your cleverness, but it's great for developing software.
> Readability: this sort of goes back to the simplicity thing. Sure, go has less boilerplate than some languages, but that only matters for the simple stuff.
Per my previous paragraph, Go's readability isn't in reducing boilerplate (Go is famously criticized for failing to reduce boilerplate) but because everyone writes the same code and the code is fairly simple (e.g., no "inheritance vs composition" debates). Further, the ubiquity of gofmt is also pretty amazing. Some languages are catching up with the "standard formatter" idea (Python, Rust, etc), which is great, but nowhere is it as ubiquitous as in Go.
> Learning curve: beating a dead horse here, but just because it's easier to learn to solve simple problems in go, doesn't mean it's easier to learn how to solve professional-level problems with go, let alone industry-leading problems which actually constitute the competitive advantage of a business.
It's much easier to onboard developers to Go than to Java or C++ or even Python. Being able to bring on a new developer without spending days configuring their developer environment, etc is pretty great. Open source projects can attract contributors immediately and businesses don't need to restrict their hiring pool to people with previous Go experience.
> Go steals the mindshare because people saw Google were using it and mistakenly thought that if Google were using it, it must be good, even though almost nobody has the same problems as Google.
This is lazy argumentation, and trivially disproven. If this were the case, people would give up on Go and return to whatever language they came from. Instead, people who use Go for real projects tend to enjoy it or at least have more thoughtful criticisms than "Go is only popular because of Google".
> Just to be clear, I didn't call anyone stupid: on the contrary, I think the developers fell into a trap that is particularly dangerous to smart people: we think that because we're smart, we already know the best way to do things. That's not stupid, it's ignorant. I don't mean that to be insulting although I'm sure you'll take it that way, but I'll say that ignorance is fixable.
I agree, but I think this applies more to Go's critics than to Go proponents. Notably, Go proponents overwhelmingly have experience with other languages, while Go's critics fixate on how Go doesn't let them program in the idioms of their previous language. The people who try Go for more than a few weeks tend to be able to levy more thoughtful criticisms than "Go is stuck in the 1970s"--they can talk about the advantages of standardization even if they still prefer more expressive power, for example.
> It's telling that in your post you just spit out a bunch of buzzwords without any comparison to any other languages
Yes, it tells you that I was commenting from a phone onto an Internet forum and didn't want to make a huge comparison chart in ascii. :) I'm happy to debate the tradeoffs of Go relative to other languages, but it wasn't necessary to make my points.
> which is pretty much how Go got here: Go developers generally only think Go is great because they've never used other decent languages.
This is another lazy criticism. Overwhelmingly Go developers have previous experience in other languages (per the annual Go survey results). In my case in particular, I've used Java, C#, C++, C, and Python professionally and I've dabbled in other languages (e.g., Rust, OCaml, Haskell, etc) on the side. I regularly have thoughtful and articulate debates about the tradeoffs of Go relative to the aforementioned languages, and many of the other Go proponents who post here do as well. Further, I hope you wouldn't criticize Go developers for lacking experience with other languages without yourself having extensive experience with Go.
Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem
In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness.
That said, for me it's not so much Go itself, but the mindset that comes with it of writing dumb and verbose but obvious code. I've reduced 15-line for loops into clever functional oneliners, but maybe all I needed was a `range` instead of a `for i = 0` style loop all along, because I need a lot more time and mental energy to understand the functional oneliner than a `for x in range` loop.
Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.
> Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions
Repetition is not a big deal in a local context (e.g., error handling or for loops), and Go is rarely repetitive in larger contexts. Gratuitous abstraction is a much greater danger than extra keystrokes IMHO.
Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice.
Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.
what I don't understand are the fans who are really trying to overglorify go as "language of the future" that could be a C replacement.
Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readability, learning curve, etc. Much important software has been built in fully dynamic languages (never mind a 99% type-safe language like Go), but it’s a lot harder to build in a language that lacks important libraries or is prohibitively slow or for whom it is hard to find/train developers, or whose tooling is poor, or which is difficult to read/maintain, or etc.
So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand.