"enums represent a different and incompatible concept in every language I know."
Enums has always felt very natural in every modern languages i've tried (swift and rust, for example), even with associated values. The underlying "sum type" concept also is very intuitive, and seems very complementary to structs for example.
This. I find Swift and Rust enums, which are indeed very similar, to be incredibly good at modelling the real world. For example the standard geospatial vector types which are heterogeneous and even recursive in the case of GeometryCollections can be modelled and operated upon very cleanly.
>The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
I'm not sure what you mean by this. It definitely doesn't have enums, not even in the C sense of "type alias for integers with names for specific constant values. Yes, it has iota, but that's orthogonal to enums; you could use it to define bitmasks, for example. While you can certainly use it in combination with a type alias to make something resembling an enum, I'd argue that's still not actually "having enums"; you could do the same thing in C with typedefs and constants even if it didn't have enums.
Go seems like such a strange language to me. I like its simple syntax, but it's strange that they compromised and added generics to the language but balk at basic things like sum types, pattern matching and type safe enums. Their simplicity design philosophy seems a bit incoherent.
They might be trying to do another C, that is so simple that it will be ubiquitous? They're failing to understand that C would never take off it invented today. Go is nowhere on my list of languages I would use - there is simply nothing it's great at. Serialization/deserialization? Rust. Multithreading? Rust. Low level high performance stuff? C, Zig. Quick scripts? Bash, python, JavaScript, Rust. Really fast concurrency? C++ or Rust. Web servers and services? Either nodejs, something static on an existing webserver, or rust for backends.
I completely fail to see where Go excels. Large, statically linked binaries that aren't even concurrency safe...? Really? No enums? Odd syntax (I like Rust, C++ and Haskell, I find Go's syntax odd still).
Like so many Google products, it solves a problem that nobody I know has. And I guess they can afford concurrency bugs, who cares, its only a language primarily for concurrency.
Have you used Go? Most of your criticisms are, in my experience, incorrect. But ultimately there are tradeoffs, and Go seems to be a divisive language.
In my experience, Go excels at pushing you towards solving the problem rather than yak shaving. And in my opinion that is worth it’s relatively minor frustrations.
It is a passable replacement for CLI utilities (so basically Python or bash) thanks to the rich ecosystem, easy cross-compilation, and static linking, which makes deploying the result easy while also avoiding the horrible mess and pain of handling Python dependencies, or remembering dozens of tiny incompatibilities between various flavors of UNIX utilities.
Unlike Rust, one is not required to have three digit IQ to use the language, so that's why I've been using it where previously I would have resorted to Python (and then either copy venvs around, or write packages for my packages to ship dependencies of my dependencies).
I too fail to see why would anybody use it for anything else, especially compilers or more complicated server stuff where you really benefit from having a proper type system, but people do, so I must be missing something...
Compilation time is fast, and it’s debuggable. Typescript would be the main competitor in my mind, but compilation with TS is slow and you have no parallelism without native extensions.
It's a better Python, that's where I see most of the real world use cases. After dealing with Python for a while now, I would take golang any day of the week lol. But for backend systems, there are far superior alternatives.
reply