I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting.
It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and alternatives.
Note, this is explicitly not about the languages themselves, but rather the larger cult(ure) of mainstream programmers around them.
It feels extremely strange to see Go described as a "hype" language. It was somewhat hyped around seven years ago, which is when I started using it almost exclusively. Before that, it had a strong hype peak about fourteen or fifteen years ago, just after it was born.
However, it's not a young language any more. At this point I would actually submit the opposite criticism: it is a mature language which is perhaps starting to suffer from middle-aged spread, as the bored maintainers start to stuff in more features which the language doesn't genuinely need. (Example: Iterators. Sure they're nice, but does the language really need them?) If anything, I would say it's going more the way of Java than Rust or Node.
Well, it's a very usable language which is strongly typed (by any layman's definition), easy to pick up, easy to get stuff done in, relatively easy to live with and easy to maintain. If it's hyped then it's only in the same way The Beatles and Pizza are hyped.
I think the hype has already peaked for Go. When we switched to Go 8-9 years ago I already felt the hype had died down. We were late to the party. And I saw that as a good thing. To me it suggested Go was going to stick around.
And now, almost a decade later, we're still using it.
Note that at my company, we're a bunch of grumpy old guys with about 30 years of experience each. If you dangle a new and shiny language in front of us, our default instinct is to tell people to get lost. We don't do "fashionable". We tend to make investments in learning languages that we expect to get at least a decade out of.
And I don't think Go is succeeding Rust. From what I can tell, people are going in both directions.
Go and Node have some significant overlap, but Go and Rust are barely even competitors. Of course there's a lot of programs that you can use either to write. There's a lot of programs where it hardly even matters which language you pick at all because they're all perfectly acceptable solutions, though, so that really isn't saying much. But if you map languages out by the programs where language choice matters at least a little and where a given language is legitimately one of the top contenders, Go and Rust don't have a particularly strong amount of overlap in my opinion. They do, but again, lots of languages have overlap; I don't see the Rust/Go relationship being particularly heavily overlapping. (Go/Java or Rust/C++, now there's overlap, for comparison.)
> Go and Node have some significant overlap, but Go and Rust are
> barely even competitors.
Among the people I know Go and Rust seem to be at the top of their list. Almost all people I know who program Rust also know Go. Not as many Go programmers I know program in Rust as well, but some know Rust and even more want to learn it. Which probably isn't too peculiar because Rust is more of a kerfuffle to program in.
I'm not denying your observation. I'm just reporting that from where I am, things look a bit different.
I agree that it mostly doesn't matter that much which language you choose -- as long as it is a language that can meet certain minimum standards. In my view there is only about a handful of languages to actually choose from.
The first is that it must be possible to produce proper binaries. For instance, Python is unacceptable to me since it tends to place a large burden on the user. Next, it has to be a somewhat mainstream language with a sufficiently large community. With that sorted the more technical stuff needs to be evaluated. Like its standard library, how ergonomic the tooling, what quality software/libraries the community produces is etc.
I wasn't aiming for that. My point is more: I know Go already, it's good enough for my purposes, so I'm using that as my hammer. I could just as well have been Java or C# I learned eight years ago and used that for everything. :)
I just began using Go literally 2 days ago, but I could already see building most of my projects in it from here on out. It has the type system I'd need from Java or C#, while being almost as simple and readable as Python. I love the module system so far and enjoy not having to decide on my own formatter.
Go is perfectly boring and simple, and seems to get out of my way. At least, that's how it feels as a newcomer. I'm sure it will change over time, but I'm having a blast at the moment.
In modern Java applications, interfaces are favored much more heavily than OO designs relying on inheritance.
And Go has very nice support for interfaces. To the extent you don't even need to declare support for an interface. Go just figures it out if your type supports all the methods in the interface.
If you mean classical Smalltalk style OO, no Go doesn't support that, but neither do Java or C# or C++.
Interfaces and functions do pretty much everything inheritance does. It's just cut in a different direction. If you go in demanding that Go support inheritance you'll be in for a bad time; if you go in demanding that it have some good solution to those problems that you may not be used to, you'll find it generally has them.
Go has exceptions and exception handling in the form of panics and recovers, but go devs are discouraged from using them.
Go also supports most of the typical attributes of oo. It has polymorphism and encapsulation it’s just missing inheritance and uses composition instead. Most Java and C# code basis have stayed away from inheritance (for a long time) so there isn’t that big a difference.
This is my first time working with a language that exclusively uses errors as values, and I haven't had time to develop any strong feelings about it. So far it feels nice because it makes error handling crystal clear, but I could also see it becoming cumbersome over time.
> It's pretty bad, but it turns out that exceptions and inverting my entire program to pass into a Result's flatmap chain are even worse
Based on what? Exceptions do the sensible thing at all times: auto-bubbling up (no random swallowing), contain info about its origin, and a handler can be specified as tightly or widely as necessary.
It’s objectively superior to grepping for an error message, or straight up not doing anything which go is especially prone to do, as after a time all the if errs become just visual noise.
We have not been in the same codebases, apparently. The number of times I've come across (I'm paraphrasing):
try {
// some stuff that can fail
// bonus points if there's a comment explaining why it can't error in practice
} catch (Exception e) {}
Is hilarious. Especially when it happens in library code.
As verbose as `if err != nil { return nil, err }` is, the fact that it gets banged out so much means people default to it, and I find myself less likely to get into a weird partially initialized state in go than I have been in other languages.
> It’s objectively superior to grepping for an error message
I mean to this end, Go is more closer to Perl(C/Unix family) than to Python(Pascal? family).
But by now most programers are so very used to making the language do a lot of error handling kind of chores that having to do them manually kind of feels doing work that shouldn't be done(Like doing what the language should have been doing).
Of course you could bolt OO onto Go. In a way similar to how Perl provides kind of bare bones means assemble a OO system. But that is not the point, having syntax to this baked into the language just makes it easier and standardised to learn and use well.
Perhaps Go is Perl done right? Than a replace for Python.
But one has to see for how long it can maintain its minimalism. On the longer run code turns to be as complicated as the problem you are trying to solve. Removing the features doesn't make the code simple, it simply make it explicit(a.k.a Verbose)
? It doesn't have exceptions, so it doesn't need exception handling. It has an error system / standard that isn't based on exceptions.
I only know exceptions from Java myself, and in practice, what it calls exceptions are often... well, not exceptions at all. Files missing, SQL queries returning no errors, division by zero are not exceptional situations, but normal day to day events. And an exception generates a stack trace, which is an expensive operation.
I mean one way to avoiding that is defensive programming - check if a file exists, do a count on the SQL query first, do a pre-check or assertion before dividing - but that adds more and more code that you need to write, test and maintain.
OO has merit for what you describe, but Go's alternative works just as well (imo) for that purpose; you have struct types containing data, you can add methods to those types to encapsulate behaviour. Go doesn't have OO inheritance, but inheritance has been out of fashion for years now so it's not missed.
TL;DR, exceptions and OO are solutions to problems, Go has its own solutions to those problems, neither of which are difficult to understand.
Throwing prevents the caller's control flow from passing into code that assumes a useful value was returned and ready to be consumed when it wasn't. Handling a success or a failure with exactly the same code shouldn't be a default because it almost never makes sense.
A Java exception can suppress stack trace init if needed, letting an instance be created once and reused very cheaply (though logs will be less useful).
The whole idea of exception handling with try/catch comes from the fact that problems and error handling can all be standardised into one structure of patterns. Once you are here you can be sure the language(compiler) and tooling(IDE/Editor etc) will generate them for you and provide you with means to handle them.
Nothing much has changed in terms of problems and interfaces. So the errors will remain the same.
Now when you use go, you will have to write a lot of code that other wise the language+tooling could do automatically for you. This is just doing work that you shouldn't even be doing the first place and pointless verbosity.
Minimal is not always better. And some parts just feel like they were omitted because the language designer didn't want to do the work for you. Whereas the whole point of a programming language is that it does as much work for you as it possibly can and make it easier for you.
Just saying writing the same/similar code over and over again is waste work.
Of course, Go has try/catch, albeit under the keywords panic/recover. The whole idea of not using it, most of the time, except for the case of exceptions, comes from the fact that problems and error handling have shown to not in any way fit well into a standardized structure. Ruby, for example, came to the same realization even before Go. This is something that was already becoming understood before Go was conceived.
Sometimes it works out. Certainly encoding/json in the Go standard library shows that it's quite acceptable to use where appropriate – the programming tools are there to use, but it turns out that it is rarely appropriate. Which is also why most other languages are also trying their best to move away from the practice as a general rule, if it ever was adopted at all.
Just looking at Go after having experience with Erlang and Crystal, does it still have a narrow-minded view of what features language won't support?
Like I remember there was a whole drama about generics, errors being simple strings and always returned without being able to raise them, is this attitude still there or have things changed?
That attitude is still there because there is no compelling reason to move away from that. A lot of languages have been diseased by bolting on features for no other reason than different languages have them, and it's overcomplicated the languages and fragmented the codebases.
Example, if you ask ten Scala developers to solve a problem, you'll get ten different solutions. That number drops quickly for less feature-rich and more opinionated languages like Go.
I agree with that and Scala example, but also languages diseased by not evolving and not allowing new widely-accepted features. I wonder what would happen with Go if they never changed their mind and kept it without generics?
My point is not about bringing all features other languages have (its just not possible unless its a lisp), but rather creating a new language and not understanding how vital something like generics is for general purpose programming. That is an orange flag for me.
> I wonder what would happen with Go if they never changed their mind and kept it without generics?
Change their mind? What do you mean? Go always maintained it would get them, once the right design was found – which was echoed by Ian Lance Taylor actually working on them even before the first public release. He alone has, what, 8 different failed proposals?
The problem was always, quite explicitly, that nobody within the Go team had the full expertise necessary to create something that wasn't going to be a nightmare later. As you may recall, once they finally got budget approval to hire an outside domain expert, the necessary progress was finally made.
Being an open source project, you'd think the armchair experts on HN would have stepped in and filled in that gap, but I suppose it is always easier to talk big than to act.
> The problem was always, quite explicitly, that nobody within the Go team had the full expertise necessary to create something that wasn't going to be a nightmare later. As you may recall, once they finally got budget approval to hire an outside domain expert, the necessary progress was finally made.
This is a very interesting part and looks like you know about what happened. I wonder how come Go team had many super talented experts (Pike and Thompson for example) with a "power" of Google behind them and generics were an issue at all, while for example Crystal being a very similar language with native code generation, similar concurrency model and no big tech behind it managed to pull it off?
I've read some comments of devs who used both and they say Crystal is just plainly better.
This just doesn't make sense to me, the biggest tech company on the planet should create a language that is head above everything else, but ended up being just good.
And this is a perfectly reasonable approach. Frankly, the cost/benefit ratio of delving into another language is most often not appealing.
As a suggestion, you could have delved more into the "hammer" metaphor, mentioning that a hammer is a flexible tool: nail planks, remove nails, smash things and even as a defensive weapon! You shouldn't misuse it for drilling walls, but that is outside the required scope of your work etc.
But in the end it's a very personal post, and we typically crave here for universality and judge posts up high from a meta-perspective, haha. Often neglecting that we were not actually the intended audience.
> It strikes me that Go is riding the peak of hype languages.
Very much so. Also it seems to be a strange choice as a solo developer when its strengths are explicitly targeted at large organizations. And I think the tooling is actually a bit of a mess compared to some other options. God help you if as a solo developer you start building on top of protobufs (another basically default choice in the Golang world...).
I just don't understand why you wouldn't choose something faster and more expressive.
Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent here.
I wouldn't call its tooling "a mess" but these days it's nothing notable either.
Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case. It was also designed as a more modern and mature replacement for C, and I can't think of many application domains where C is still the better choice.
Python is at such a different point in the design space I don't think you can really compare the two. Same with PHP, Ruby, Javascript etc.
For OCaml, need to decide how strongly you want to commit yourself to functional programming. Also, didn't OCaml have weak support for concurrency? Has that changed recently?
Similarly with Rust, comes down how much you want to commit yourself to learning and conforming to the borrow checker.
Elixir is an interesting comparison, as it's another language that allows you to build highly concurrent back end services. The tradeoffs are that Elixir provides even more robust scaling due to the Erlang VM. But Go allows you to more easily understand and optimize the memory and CPU performance of your application.
Well regardless of the goals or intent of its creators, it has found success as a general purpose language suited to a broad set of unrelated tasks. And in fact that is exactly how it is being recommended here by the articles author: so within this context I don't think it makes sense to exclude these other languages.
But even aside from that we were just talking about tooling at the moment.
My understanding is there are more fundamental reasons for why Go compiles faster, like how it handles "includes". And not supporting the C++ templating system.
And some things that slow down compiles are not to improve optimization. But to support complex, higher level language features. Go seems to hit a sweet spot of being highly expressive without slow compile times.
I consider that a win too tbh; JS land has improved a lot with e.g. Prettier and now Biome, and those were inspired by Go's formatter and stance saying "shut the fuck up about code formatting already, this is how it's formatted, end of story, go worry about more important things".
Obviously but if you look at a lot of Go projects you tend to see it.
Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people.
And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainly wasn't my experience when solo contracting.
Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.
The opposite seems true (regarding Go being over-fitted to Google problems).
It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat.
Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does.
I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.
True for the early days of Go but I don't know about now. I think the switch started happening right after modules came out. Generics and the new range stuff seem more for the sake of growing the language than specific needs in Google.
Author here. Well, it has worked pretty well for me so far, so I don't know why I would switch. Go is fast and expressive enough for my use, and it's probably outweighed by being super familiar anyway.
(BTW, in my eight years of Go, I think I've used protobufs maybe once or twice. HTTP FTW!)
What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
I'm genuinely curious which language you see as having a better development time. I don't mean that as arguing, I'm actually curious. I don't know much about Go but I just began learning it 2 days ago. I'm already 50% of the way done through a really nice TUI app, and I haven't even touched the docs.
To me at least, it feels extremely productive so far.
When leaning on libraries pushing what's new in computer science, like certain facets of machine learning as a prominent example, which generally aren't found outside of the Python ecosystem, certainly. But head-to-head on well-trodden computer science paths, Python doesn't stand a chance.
My own experience (I'm not the author) is that the investment required to reach the point where Go can be a "hammer" as in this case is lower (usually significantly lower) than with "faster and more expressive" languages.
Only ergonomics, I do actually like most of it (maven central/repository model and gradle). It is one of two truly general build tools (other being Bazel), and being that generic/capable does mean that it can’t be as user friendly as a single-language build tool like Go’s or Rust’s. But these all break down the moment you introduce another language/build step/whatever, while Gradle can build the whole hodgepodge that is the Android platform just fine, which is quite a testament to its power.
What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
I think he could have chosen those alternatives just as well, he just happened to pick Go. His argument is that he strives to use his chosen tool in as many situations as possible instead of having a bunch of different ones.
I am someone with significant experience in Java, C#, C++, and JS/TS. I am a bit of a newbie to Go but have used it for a few things at work. So, I can give a bit of a comparison for you.
I really like the DevX and strong standard library of Go. Also I really like that the community around Go has a strong preference for just using the stdlib and not going crazy with third party libraries.
Languages are just tools but I have a strong preference for Go for backend services and CLI applications now. Just my 2cents.
Hey, thanks for the reply. That sounds really nice!
I wonder, which aspects of the "Go" std lib are considered strong? Would you say it is more like .net where the std-lib also comes with framework-grade capabilities such as REST-endpoints and setting up applications?
Because in the classical sense of a library, I think Java is fantastic (collections, strings, NIO, HTTP 2.0, etc.). But it misses framework-level out-of-the-box solutions.
So take this with a big mountain of salt as I am newer to Go and my experience with .Net is a bit dated but I do have 7 YoE with C#.
The C# stdlib is larger and more batteries included for sure. But, it feels less focused than Go to me. Over its history it has supported a ton of different styles of programming. Whereas Go’s maintainers have been, at least so far, more obsessive on keeping the language small.
As a result you get libraries and codebases that have a mix of legacy and modern flavors of .NET. That isn’t the fault of the language but more of its large history and wider scope. GoLang doesn’t have a rich UI library built in for example whereas .NET has 3 if I am remembering correctly.
I like the focus of Go but C# is a great language and .NET is an excellent framework.
Here are some things that I think Go does better though:
- TLS and x509 stdlib is fantastic
- Explicit error returns instead of Exception throwing
- A developer culture around idiomatic Go. It’s subjective but it sets a tone for a single coding style.
- Less “magic”. This is more of a sin of Java frameworks but .NET has lots of higher level abstractions the push lots of interactions behind the curtain.
- tiny docker images and super fast startup.
Here are some things I miss from C#:
- really nice Enums
- Better support for functional programming.
- LINQ to objects
- Annotations, specifically validation logic as annotations.
- JSON handling is more straightforward
.NET is super capable though. Nothing wrong with using it and it is much more broadly applicable than Go in my opinion.
But, I like the ergonomics of Go and for backend services and CLI tools I think it is a strong choice. But, I wouldn’t choose it to build a game or a desktop/mobile GUI application currently.
Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down.
It’s okay, hype cycles are good since it shakes up mainstream opinion and gets people to try stuff. Like a new trendy food. I don’t feel much in the ways about it.
How do you feel about Go outside of the hype cycle?
I think hype is more about trends than it is about age. PHP is going through a bit of a hype phase right now, for instance, mostly because of Laravel and the fact that the language has been silently improving a lot since the wordpress days, and developers are just now starting to realize it.
> Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down.
Sounds like my impression as well.
> How do you feel about Go outside of the hype cycle?
I think it's in a weird place, but I have a much higher opinion of the language ever since it got generics.
There is nothing which is inherently unique to Go, but it got some neat technical features: Static compilation, garbage collection, good model for multithreading, fast compilation times. With these qualities you can get pretty far and have good cloud readiness.
However, I'm a Java guy and the JVM is my working horse. I have seen how large projects (don't) scale once you have 8+ developers and there are shortcomings in Go for projects of this size. And I think the explicit nature of nominal typing (e.g. Java) absolutely wins over the implicit structural typing one (e.g Go).
You see this difference of philosophies by interface constraints: Java interfaces must be implemented explicitly and you can even limit who can implement them. Java is primarily a language designed for libraries & frameworks and the quality shows it.
With structural and open implementation of interfaces, your line of code-ownership becomes blurry. This is not nearly as problematic as dynamic typing, but in my mind an interface is a specification. And you there should be a contract between the provider and consumer. This also helps with understanding the connections inside/between code-bases.
Same about interfaces can be said about First Class Functions vs. Functional Interfaces. Functional Interfaces can be documented, domain-specific, extended and implemented. It feels like a perfect blend of FP and OOP, whereas with First Class Functions I feel like I am working with C-stylee primitives which don't help me express the nature of the solution I want to model nearly as much.
As for Java, I have an immeasurable amount of respect for the current language designers (can't say I have the same respect for Go Designers after the drama surrounding generics). I am an avid reader of their mailing list and time and time again, they have shown deep thought and tremendous foresight (their way of work is quite inspiring). Yes, they have to live with some nasty historical baggage, but they have a very high level of quality.
Then there are aspects such as the ever-evolving JVM, along with its choice of several garbage collectors and top-tier runtime analysis (Flight Recorder) & optimization (Hot Spot).
Sorry, this is entirely subjective but you asked me how I "feel" about it :-)
Summing it up, I'd say Go is a comfortable local maximum which can give you a whole lot, but ultimately is less flexible. But it's surely enough for 90% of applications. In this sense Go is like the big brother of PHP, which is a perfectly reasonable language if all you need in your backend are save/load database operations. Go can cope with that too, but also scale into non-trivial domains, the cloud and multi-threaded problems.
But Java is "corpoaraty" and not "trendy", so most people don't even consider it as an option. And there are enough bad devs who started their carreer in JS/TS and want to move towards something more performant, that is still as ad-hoc and don't mind sharp edges because they never learned to reason about their application in a more formal sense.
But looking at the work that is currently being done to the JVM, I'm looking forward to the near future when we can run Java-compatible bytecode on GPUs and AVX512.
The tools make a lot of decisions for you that are pretty arbitrary, like how to format code, freeing up brain cycles for other things.
It compiles very fast, so the iteration cycle is similar to a dynamic language with a REPL. Very little time between making a change, running and seeing the new result. The language is designed from the bottom up for fast compile times even in large projects, with features at odds with fast compilation rejected.
Decent sized community and library ecosystem.
The networking APIs are very simple and productive. More and more back end code is being written in Go for this reason.
The semantics are straight forward. The other programming environment I need to deal with at work is Spring Java, which is unjustifiably complex and obfuscated for what it does. Go allows you to read the code and run the program in your head understanding semantics and performance characteristics.
Builds single file executables that are simple to deploy.
Has just enough high level features to be productive without compromising above points about simplicity, fast compiles, and comprehensibility. Channels and go routines work very well to model concurrency across a wide array of problem domains.
Maintainers are careful about adding new features. Generics took a long time to arrive, but when it did was very well thought out and did not negatively impact performance very much.
It’s an unfortunate choice of “one hammer to rule them all” given Go does not offer necessary coverage at both low and high ends of abstraction (and performance) the way C# does. For me, it’s a similar kind of hammer.
The problem with C# is its created by Microsoft, even if its a good language its hard to look at it and not think how much its limited while used outside of Windows.
I understand its probably not the case today, just that C# shares some of the MS reputation and its hard to get rid of. Especially when there are dozens of open-source independent languages around.
I think phrasing with insistence that it is "probably not the case today" despite demonstrable evidence of certainty means that the motivation for this reply was not to learn something new or share something you know but to try to get a raise with low-effort bait. This is both tiresome and goes against guidelines.
Somehow we all can normally discuss programming languages without bringing practices of Google or Oracle into the picture and focus instead on programming language development initiatives that they drive and sponsor, that are themselves sufficiently independent. Let's keep it that way.
I phrase it this way only because I do not have enough knowledge to be certain. I've read the comments that you sent, but to be certain it requires much more in-depth investigation which I don't want to do simply because I have no plans on interacting with C# in any forceable future.
I only tried to explain how some people who are not directly involved with C# might see the language.
That's a shame. .NET does away with all the pain points you've grown to expect from Python or Java tooling, has arguably better support[0] story on the main platforms nowadays and extremely no-nonsense CLI tooling similar to Rust or Go:
sudo dnf/apt install dotnet-sdk-8.0
# or
brew install dotnet-sdk
dotnet new web
dotnet run
curl localhost:5050
[0]: Situations like https://blogs.oracle.com/java/post/java-on-macos-14-4 do not happen to .NET as it tries to use the platforms it is targeted at in a "canonical way". To be fair, not exactly a Java fault, but effort is invested to ensure that the runtime plays nicely with e.g. memory protection techniques.
I think it’s fine. Honestly I think there’s a lot more deep developers out there than broad developers. It’s just they don’t blog about depth the way broad developers blog about their shiny new toy.
Honestly it gave me the feeling of not arguing to use Go but instead arguing to use the full featured language you know the best. The caveat being that it is of you are a single developer making all the decisions and writing all the code. Seemed to make a good case for that
I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting.
It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and alternatives.
Note, this is explicitly not about the languages themselves, but rather the larger cult(ure) of mainstream programmers around them.