Anyway, I like seeing this slight reversion in favor of simplicity, I think it's the right call for where Go's targeted: being a better Java for teams of mid-tier engineers.
Anyway, I like seeing this slight reversion in favor of simplicity, I think it's the right call for where Go's targeted: being a better Java for teams of mid-tier engineers.
It's easy to get things simple and wrong, and hard to get things simple and right. And sometimes complexity is there for a good reason, but if you don't work hard to understand, you'll fall into the "simple and wrong" camp often.
Brainfuck the language is simple to use and implement. It has only 8 commands. Brainfuck programs are virtually unreadable, unless you can get your head around it.
The advantage of trying to solve complexity is that if you can solve it, you've solved it once and exactly once for everyone involved.
My friend tells me the primary use case for go are microservices no more than one page worth of code deployed in kubernetes.
I think that's correct. Anything larger is just masochism.
There will be a revolt at some point, the question will be to what? Rust? Probably not. Maybe a C++ resurgence...
Why would anybody choose C++ over Rust in 2025? The biggest (valid) criticisms against Rust are that it is difficult to learn and use, but C++ is like 1000 times harder. When people say Rust is complicated they’re comparing it to modern GCed languages, not to C++.
1. There is a lot more experienced C++ devs around.
2. There are a lot more libraries that are readily usable from C++ but would need to be wrapped to use in Rust.
3. The tooling (IDEs etc) around C++ is more mature.
I actually disagree with this specific take. I do agree that iota is an unnecessary bit of cleverness (especially with that name) but I’d much rather a langage have nothing than the pile of lies and garbage that are C enums. At least then it’s not pretending.
The only godsend of C is that code written in the 1970's can still be compiled today -- half a century later. You can write code in your 20's in C and still be assured it will still work a half century later in your 70s. (as long as you don't use system libraries which might change.... etc.)
A lot of people complain about Rust compile times. But honestly, I'd rather work in a language that is trying to solve complexity rather than push it off on to the user.
As I wrote at the time on Lambda The Ultimate back in 2012,
There’s a very high probability that something like Cockroach would use C++ if Go had never existed, so Rob Pike was sort of right, if you squint. On the other hand, if Cockroach were started today it would probably be written in Rust.
In fact, tell them to write a brainfuck transpiler in brainfuck to transpile go lang to brainfuck to make it easier for you communicate with their native tongue directly.
https://stackoverflow.com/questions/16836860/how-does-the-br...
But honestly if you're a professional programmer, you should constantly be asking yourself how do I reduce complexity for others first, not myself. And that's where golang gets it wrong. Golang asks very specifically first and foremost how do they get their compiler right -- even if it comes at the potential expense of the users.
I mean golang is not brainfuck by any margin, and it is reasonable for what it tries to do. But, in my experience, if you're writing code longer than a page, golang is probably the wrong language.
But it sure looks good on your resume!
I work in C# and C++ day to day now, and in $PREV_JOB I used Go and C++. my go builds on a similar size project were quicker than the linter in my C# project is right now. Go's killer feature IMO is that it's _almost_ scripting level iteration speed.
Basically, the mental model required for coding in go is low load. That's a great feature.
Sorry, it wasn't clear. I could run `go build && ./myapp` and have my application running quicker than `dotnet format` finishes. Linting in .net is slower than compiling in go.
Agree on everything else. It has it's share of footguns, for sure, but so does every language.
Overall, the tooling could be faster but because it is JIT-based and performs heavy unbound reflection, it's not very amenable to the NAOT compilation in its current form if you are used to frequently running 'dotnet build' and 'dotnet run' where startup latency imposed by JIT is most noticeable. Also keep in mind that both invoke the full build-system. It's closer to what Cargo does than what Go tooling does. Are you using .NET 9 SDK? Another feature I suggest looking at is hot-reload with 'dotnet watch'. It can shorten iteration cycles for doing the back-end work substantially.
It does not matter on CI, it matters locally where you should be using something else.
And of course if you are looking for an excuse to use Go (which is a worse language), fixing this or any other "issue" will not help - there will always be another reason.
AOT is pretty good when it works.
StackOverflow survey (self reported) for 2024 shows it at #5 leaving out HTML/CSS, and SQL[0]
DevJobsScanner shows it at #4 via scraping job postings[1]
It definitely has heavy adoption; well above Rust and Go despite what we see here on HN.
> Does it have any actual advantages over Java?
The language evolves faster and is more akin to Kotlin than to Java, IMO. The DX is fantastic and there are a few gems like LINQ, Entity Framework, and Roslyn source generators. Modern C# can be very dense yet still highly legible.C# switch expressions with pattern matching (not switch-case), for example[2], are fantastic.
[0] https://survey.stackoverflow.co/2024/technology
[1] https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
[2] https://timdeschryver.dev/blog/pattern-matching-examples-in-...
For a quick comparison, check out https://typescript-is-like-csharp.chrlschn.dev/
Sure. For me the best thing about dotnet is that you most likely find an official solution to most "basic" things needed to develop microservices (I intentionally call these basic because you don't want to worry about lots of things at this level). Go on the other hand excels at cross-cut and platform development.
Probably not. Why learn C# if you already know Java? Similarly, why learn Java if you already know C#?
It is also generally less nice to work with - Maven and Gradle are a way bigger PITA than .NET CLI (which is similar to Cargo and Go CLI), NuGet and MSBuild. Base C# syntax lends itself to more streamlined expression of business logic (e.g. with pattern matching, tuples, records and their deconstruction).
In Java, there are odd issues and resulting method gymnastics caused by generics with type erasure, and many of its base containers don't unify nicely as the ones in C# do to IEnumerable<T> or Span<T>.
Writing highly concurrent + parallelized code is way more cumbersome (and generally less efficient) with the current rendition of virtual threads, completable futures or even upcoming structured concurrency API than doing so with .NET 'Task<T>'s and their composition.
ASP.NET Core is much faster and more focused than Spring Boot. EF Core is way more powerful and significantly terser to use than Hibernate, JPA or, to an extent, JOOQ.
You can also relatively easily ship fully self-contained and relatively compact (with trimming) applications, often as a single file. With additional effort, NativeAOT provides native compilation and smaller-than-Go binaries while having much wider support across ecosystem than GraalVM Native Image within JVM space (e.g. it's one command away to get a gRPC-based ASP.NET Core microservice template which compiles to fully native binary, it also does not use any special tricks - just regular code).
They are very much not 1:1 languages. Depending on the domain, there may very large differences in developer productivity, level of comfort and effort required to achieve a competitive implementation.
Java strengths lie in its comparatively larger and more diverse ecosystem in enterprise space alongside certain high-profile projects, predominantly by Apache foundation. On technical merits it does have less to offer.
The main technical exception - Java has superior GC implementation(s).
I'd say if your goal to expand your horizons, then it's more important to pick a problem that can't be nicely solved with Java. In that case, C# will offer more pleasant and moderately familiar experience over C, C++ or, to an extent, Rust (which is another great language to learn).
Yes JVM currently sucks in value types and low level C++ like coding, .NET is great there, but not everyone needs those capabilities, and when they do, most don't shy away of doing some JNI.
On the technical level, .NET doesn't have GraalVM like tooling (it is a whole compiler framework not a plain AOT compiler), the MSR Phoenix project was canceled, Longhorn was canceled so nothing Android like, no real time GCs and bare metal deployments like PTC, Aicas and microEJ, no VMs for M2M, copiers, telephone switches.
In what concerns EF, I keep my point of view that I rather use Dapper with SP.
I definitely liked writing Kotlin code in the past, but we had a medium sized Kotlin web api at a previous job, and a very large c++ app. The c++ app was quicker to compile than the Kotlin app on many many occasions, and the toolchain and IDE integration situation reminded me (not in a good way) of working with eclipse - even with intellij
Compile times might be an issue, I know it was an issue in the past.
C++ can actually be quite fast to compile, if the right decisions how to approach the build infrastructure and code styles were taken, which usually is not the case, hence its fame to slowness.
Its also popular in Game dev mostly due to Unity, but you have other good options to use C# in game dev as well. I can't think of another kind of software company that uses it a lot other than ones that integrate deeply into the microsoft stack.
As a language, it was far, far ahead of Java for many years (the long dark tea-time of Java 7).
Here's some data of 12M scraped job offerings:
https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
JavaScript: 31.42%
Python: 19.68%
Java: 18.51%
C#: 11.90%
C/C++: 8.29%
Go: 2.38%
Rust: 0.39%
I was a bit shocked about the Rust numbers. I'd expected it to be slightly above Go. Anyway. C# is strong. Java even more.
Also, "job openings" is not the same as jobs, my organization isn't currently hiring engineering roles, yet we employ ~60 engineers, of whom most write Rust. And we're just a tiny startup.
Why's that?
Go was designed explicitly to serve the particular needs of a particular area of software development that allegedly sees more than average development activity. In fact, its designers have expressed some surprise that people found it useful in other areas of programming. Rust, on the other hand, tries to be much more general purpose. Being a jack of all trades master of none, so to speak, is a great technical quality, but without particular focus it is much harder to get the numbers up.
It is quite similar to why Javascript blows all of the other languages out of the water. It would be surprising if Rust had more usage like it would be surprising if C had more usage than Javascript.
It’s more what you must implement along with your new data structure to make it usable in the language that was the cry of the generics advocates.
The language reserves syntax for itself; you can't overload a[b] to mean anything other than either array/slice indexing or indexing into a map. You have to write methods like ".Get" or something, there's no __getattr__ or anything.
It's not just types, either. Look at the signature for the built-in sort, which is amazingly cumbersome to use. A generic wrapper around it hides all the ugly.
EDIT: Had to check, yeah I had to implement the iter.Seq type to do it
In fact I created a struct that you can range over just a couple of days ago.
I can’t say I love the way Go implemented it though. But it does work.
But I suspect they meant a struct which contains/encapsulates data which can be ranged over.
Why not?
1. How it should be implemented “correctly”
2. The resulting code isn’t clear how it works at first glance (particularly with the yield command, it has “magical” properties that take a little effort to grok)
3. Requires calling a method
Example code: https://github.com/lmorg/Ttyphoon/blob/321738f289e4791e9674d...
I did write this at something like 11pm so it’s entirely possible I’ve done this completely wrong though.
Also please ignore the weird use of mutexes here too.
I’m also aware that sync.Map could/should have been used here. This struct was more of an experiment than anything that will ultimately find its way into production code.
That cuts me right to the bone.
I do like to dabble in F# still.
I think the ultimate goal of making a programming language is to cause the least friction for a programmer trying to get real work done, and in my experience Go's great from that point of view. Language bells and whistles may be exciting, but often don't pay their way in terms of real world productivity, IMHO.
I used Go for most of my own projects and as I got deeper into it began to realize its warts, but the worst was that you can't get performance by "share memory with communicating"--channels are slow. Reading the non-idiomatic stdlib implementation shows the difference of who it's made by vs who it's for (which isn't the authors).
What's the difference? The opposite, so to speak, of system is script, and I don't think system management falls into the scripting category. A system management system is a system too. But that isn't what they were talking about anyway. They were talking in the context of building servers (think like a HTTP server). That was clearly spelt out.
I understand that the Rust crowd has reimagined system to mean something akin to kernel, much like they have reimagined enums to be akin to sum types. Taking established words and coming up with entirely new meanings for them is what they like to do. But that reimagining has no applicability outside of their little community. This is not how the industry in general considers it.
There was a sort of misunderstood dream in the early days of go that it would make fanning out and using your 24 cores easy as empowered by channels: this is still not easy in go, although it may be easier and less error prone than c.
In the intervening decade, python has made say a parallel for loop immensely easier.
It is this condescending attitude that I feel many golang advocates (online) share that makes me shiver.
What are you implying, that devs using other languages don't get "real work" done?
Let's wait until Go has the same history, maturity and reach of e.g. Java and then let's see how well it will hold up in comparison.
In the time you get everyone on the team to agree whether you should use Maven or Gradle, which testing framework to use, or figure out how to autoformat your code, your Go program will be done.
* everyone agrees to use Cargo
* everyone agrees to use `cargo test` (what even is a “testing framework”)?
* everyone agrees to use `cargo fmt`
What’s the advantage of go here?
By the way, the formatting situation is actually worse in Go because there are both gofmt and gofumpt used in the wild, at least gofmt has different behavior depending on different flags, and there are additional linters people use to e.g. ban long lines that for some reason the formatters don’t cover.
I don't know why we're talking about Rust in the first place, but an obvious advantage would be compilation time and iteration speed in general.
Let's wait another 15 year and then compare the new languages at that time against golang. Then let's see how golang is doing in comparison.
Abstractions make large systems easier to understand, not harder. Each line of Go is easy to understand, but whole programs are not.
I raise you AbstractSingletonFactoryProxyBean.
Well, in the real world a lot of people have to work on teams where many of their co-workers never grow beyond beginner level. So anything that can be done to reduce the burden of having to deal with them is welcome. Not everyone gets to sit in the Silicon Valley ivory tower beside the greats.
> your career lasts 40 years
40 years is a peculiar number. If it is your passion, you should easily be able to see 60-70 years (assuming you live to an average age), and if you are only in it for the paycheque the comparatively high salary offers you retirement long before 40 years comes around.
IMO it is better said that Go is designed as being a good language for Senior and Junior developers, where mid-tiers will probably hate it.