A lot of very smart stuff is written in Go by programmers who just want the language to get the hell out of their way. Go is some ways very good at that. Rough though if you want your programming language to model your problem domain or your algorithmic approach! TANSTAAFL.
Having used go in anger I don’t necessarily agree with this, could you point out an example. Maybe I just accepted it and work around it without paying much attention.
If you are referring to interface types being able to be null, well they are allocated on the heap and have dynamic dispatch, this isn’t particularly a surprise if you have worked in a lower level language but might be a surprise if you come from a language where that isn’t the case.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I'm curious to know why you think so, I thought it was a great article, showcasing how simplicity in the language doesn't make complexity go away, it just moves it to programs written in it.
And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written from multiple writers, maybe this gets discussed in the next article. I can understand why it is confusing and you consider it unintuitive.
The read situation is literally not understanding or even looking up the interface, there is another return value that will tell you the channel is closed.
Nil channel reads make sense for it to do what it does if your familiar with the interface but at the same time you are literally holding it wrong. Vs a language where that would be UB its an improvement. Compared to a language like rust sure the information isn’t available at compile time but on the same not you would need to be developing in rust, and no offence but if you think golangs concurrency story is difficult to grasp just wait until you meet async rust…
These are the unintuitive, these are generally complaints of you failed to even begin to read the documentation and then complain when things aren’t doing what you expect, leave your preconceived notions at the door and you will be fine.
The faster than lime take needs to be updated, comparing golang from 5 years ago to modern golang is about as useful as comparing rust fron 5 years ago to rust now.
And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing.
Because you don’t know how doesnt mean it’s unintuitive, it means you don’t know how.
Not having to call into ffi/c libraries to modify files is the normal use case. Windows is the largest used operating system.
> Because you don’t know how doesnt mean it’s unintuitive,
Do you know what the definition of unintuitive is? If it was intuitive you wouldn’t be able to “hold it wrong”.
A “systems” language designed by some smart people that is mostly targeted at the most deployed os in the world “cough not windows”, definitely does not need to make windows the default.
> If it was intuitive you wouldn’t be able to “hold it wrong
No unintuitive means if you understand the domain and idioms yet the interface still does not make sense. Returning multiple values when reading and passing context around (even in a wrapper) is normal intuitive golang.
So is allocating complex object instead of simply instantiating them, sure this point is slowly moving out of idiomatic golang but at the same time the history is important.
Not understanding CSP and not liking explicit return values does not mean it is unintuitive.
I can see this conversation will go no where though. This is the typical conversation with Go users when you point out any criticism of the language. Cheers man.
You don’t. Normal operation like reading writing modifying and creating works just fine in windows.
The only thing that doesn’t is explicitly permissions where windows is the outlier and uses (imho a better) method of managing permissions. However they are the outlier and it is an uncommon operation. Why would the stdlib cater for that?
If you need to alter permissions at a more granular level on windows than is possible using golangs interface then call into the ffi, but in general you don’t need to to that.
If that is your only criticism then I agree we will not agree on this point, it is however also trivial to make ffi calls using go
Of the few technical advantages Go had for us is that we don't need a single dependency outside of the standard library, which can't live in isolation. We use SQLC and Goose, both are run in containers that only have rights and access on the development side of things.
I'm not sure I would say that Golang has a lot of weird, pointless quirks, but it has opinions and if you happen to dislike them, well... that sucks. I hate the fact that they didn't want runtime assertions as an example, so it's not like I don't understand why people dislike Go for various reasons. I've just accepted that those strong opinions is the reason Go is so productive.
The challenge for us is that it's not exactly as productive as Python. So while you'll need to do a lot of toolchain work to get Python anywhere near Go's opinionated stucture, that is often a better choice if you're not a hardcore software engineering team. At least for us, it's been much easier to get our business intelligence people to adopt UV, pyrefly, ruff and specific VSC configs for their work than to have them learn Go.
I suspect that is why Rust is also doing so well. Go is a better Java/C# for a lot of places, but are you really going to replace your Java/C# with Go if you have dacades worth? If you're not coming from Java/C# will you really pick Go over Rust? I'm not sure, but I do know, Go failed to become a Python replacement for us. It did replace our C#, but we didn't have a lot of C#. Eventually we'll likely replace our Go with C/Zig and Python to keep the language count lower.
So you hate writing:
if (something != 1) {
panic("oh no!")
}
assert(something != 1, "oh no!")
You're taking it out of a context of me praising Golang, however, and while I do hate the fact that they didn't just do runtime assertions, it's not like I dislike Go as a whole because of it.
So compared to... very niche languages? Go has exceptionally few quirks compared to mainstream languages.
This isn't meant to be allegorical or anything specific. I guess it's just an observation that sometimes your lunch can be cheaper than you thought.
Rust is more appropriate for areas where the problem boundaries are relatively fixed and slow-moving: libraries, backend services, and infrastructure.
By better allowing you to model your program domain, Rust actually lets you finish projects that are feature complete. I have multiple Rust projects in production for years that have needed at most one or two bugfix releases after their initial rollout on top of a half a dozen feature updates. For a very slight additional startup cost in doing that modeling, I’ve gotten massive dividends back in the volume of maintenance programming that hasn’t needed to be done.
But if your problem domain changes frequently enough that the model needs to be changed all the time, that extra inflexibility isn’t worth it. On the other hand, I don’t know much go software that isn’t beset by the same number of bugs as every other modern language.
Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained executable.
I would say that Go is mostly a better Modula-2 (with bits of Oberon); it's only better from the language standpoint because now it has type parameters, but GC definitely helps make writing it simpler.