It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.
It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use.
Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies.
Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an adult and deal with your errors (it's a feature)... That minimalist no bullshit language semantics that force you not to be lazy is a feature not a bug.
There was a thread here the other day where a rust dev pointed out that "Rust is the language tokio ate"... https://nullderef.com/blog/rust-async-sync/
Rust is a lot of overhead when go is "good enough" for 99% of what needs to get done. That doesn't mean go is good for everything. I would still rather write Rust than C or C++ or bunch of other languages. Look at a project like Pingora, from cloud flair. Perfect Rust project, bad Go project. Rust is in the kernel, rust is what im looking at for a USB driver. I would not shove go in either of these places.
Now thanks to Docker and Kubernetes adoption success, we're stuck with it.
At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.
Go is stone cold simple to pick up. ITs simple to reason about. I can decompose a project and spoon feed it to a JR engineer and they can get through it.
Rust is none of those things.
Its great for low level stuff, it is in the kernel right next to C and go will NEVER be there. Why, because that is what rust is good at.
> At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.
Again I like rust. Crates being colored (as in functions), the shitty compile and tests times... these are things that are holding back rusts adoption in more places... None of this stuff is on the road map to get fixed, it's quite the glass house you have.
Go is going to replace a fair bit of python/ruby in the next few years... Is it going to be rust or zig that eats into c/c++? If the rust community keeps on the way it has been, zig will eat all the core apps we depend on.
Zig is a Modula-2 (1978), with C like syntax, with added compile time, still has use-after-free, and a community that seems ideologically against binary libraries.
Good luck making it relevant, I am not buying into Bun ever taking over node.
Your right, it does not. I will _ =: an error in a throw away script all the time.
I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.
[0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd...
EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.
Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh
You can ignore errors in Rust.
Which is a flaw in Borgo, at least when interfacing with Go code, as in Go both T and E should independently valid states.
on error goto nextI did not post your parent comment.
Easy to learn: you can be productive in go in a day or two.
Strong standard library.
Complies to binary. (you dont need to drag a run time around) And this is fast!
Easy dependency management.
Linting is built in. (No arguing over tabs vs spaces)
First class testing. (and its fast)
"good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it.
-----------------------
Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism.
As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....
I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support.
In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.
I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
1. a given interface is provided via a DI module 2. said modules are included in a binary
With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search.
I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc
There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car.
If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point are your experienced devs being productive or being babysitters?
I think I would rather babysit a bunch of jr devs working in Go where correcting their issues is educational, rather than dealing with babysitting JR devs and high speed stupidity in something like rails...