[pkulak]

Go is in this weird middle ground where it's modeled after C, so it's got things like no enums, return codes for errors, mutable everything, nulls, and pointers (that don't support arithmetic, so it's really just this "*" sigil that you have to remember to use sometimes), but it's also fully garbage collected and has built-in, stackful green threads. I have no idea what it's actually trying to be.

[kaashif]

It's all of the ergonomics of C combined with the bare metal performance of a garbage collector.

[foolfoolz]

and the verbosity of very old java

[StevePerkins]

I would wager that the vast majority of backend software jobs are for people writing REST API microservices, exchanging JSON, with a mindset that is more practical and "blue-collar" than academic.

Golang is an absolutely ideal language for writing REST API microservices, that exchange JSON, with a practical and blue-collar mindset.

Plus it compiles to small-ish native executables. Which renders Docker superfluous in many uses cases, and also makes it well-suited for writing DevOps tooling (e.g. Docker, everything from HashCorp, etc).

It's not trying to out-cool Haskell and Rust on online message boards. But I would never in a million years evangelize either of those two languages for routine REST API work in most real-world shops, whereas I could suggest Golang without losing professional credibility.

[avgcorrection]

It’s funny to emphasize the vibes of a language contra other ones when you’re supposed to be on the supposedly pragmatic side. Haskell and Rust are popular on “message boards”? Better not mention them among my peers and risk my blue collar street cred.

But it’s a red herring in any case since enum types are such a basic programming language feature. No need to evoke the Cool Kids languages at all.

[tgv]

Completely true. And most of the time, I enjoy writing go. But the enums are weak. However, if the Go team wants to tackle an important addition to the language, it should be non-nillable pointers. No need for Option sum types, just a type annotation that says it cannot be nil (but can be assigned a nil type if you've tested it for not being nil). I've thought about building a linter (like the Uber one), but the way the types in the syntax tree are resolved makes it too complex for a small project.

[pkulak]

> Golang is an absolutely ideal language for writing REST API microservices

Those are strong words for a language with all the flaws I just mentioned. :D Yes, green threads are great for network programming, but it's not the only language with them, and one feature does not make it "ideal". If I had to pick the best networking language... I'd probably say Elixir.

But even if we agree that it's ideal, it doesn't change my point.

[smw]

I find go distasteful, but are there really many other languages with an m:n threading model? Only other popular one I can think of is Erlang/Elixir.

[pkulak]

Java 21, and I assume like every scripting language (Ruby, Python, etc). Though I guess with scripting you can't use more than one OS thread (not totally sure). Rust started off with it, and C# tried it too, but there are huge downsides to the model, so it's not like it's perfection incarnate and every other language just can't pull it off.

[smw]

Does 21 actually automatically schedule fibers? to open cores?

[pkulak]

Yup. It's all 100% automatic. Just use a different name for the thread pool and you're done, I believe.

[Thaxll]

Elixir performance is pretty average and it's not a statically typed language, things will blow up at runtime.

[neonsunset]

The better language at this to both Java, Go and, god forbid, Elixir is C#. It properly implements generics, pattern matching and task-based asynchronous model which allows to trivially interleave or dispatch all kinds of method calls in ways which require extremely verbose and bulky code in Go.

[gregors]

completely agree Elixir is a much better language all around for this type of work

[seanw444]

More efficient than a scripting language, less performant than a systems language. I really like it for anything network-related.

[samatman]

C does have enums. Not trying to detract from your point, which I agree with, but enums are definitely a thing, which C has.

[randomdata]

> C does have enums.

Then again, so does Go. Go doesn't have an enum keyword like C, but that isn't what defines enums.

[xigoi]

But neither C nor Go have type-safe enums.

[randomdata]

They are type safe. They are not value safe, but neither language supports value constraints, so that isn't unexpected.

[cmrx64]

What is value safety? Why should value constraints be pertinent here? near I can tell this is a neologism (introduced here? https://itnext.io/we-need-to-talk-about-the-bad-sides-of-go-...) that just happens to be near the top of search results in this area.

The introduction rule for enum values in C is _not_ type safe. You know how you can tell? Well typed programs go wrong. a language absolutely does not need value constraints of any kind to get this right.

[randomdata]

> Why should value constraints be pertinent here?

Because that's where it is unsafe: You can introduce a value of the same type that is outside of the enumerable range. You cannot introduce a value of a different type, though. It is type safe.

Yeah, any language with a type system worth its salt has value constraints, but if you choose to forego them as C and Go have, you're not going to bother adding them just for enums. It would be kind of silly to leave developers with a noose to hang themselves with everywhere else, but then think you need to tightly hold their hand just for enums.

In fact, I'd argue that if you are short on time and need to make compromises to reach a completion state, enums are the last place you would want to take the time to add value constraints. The types more often used would find much greater benefit from having value constraints.

Case in point: Typescript. When was the last time you cared that its enums behave just like C and Go? Never, I'm sure, because it having value constraints everywhere else more than makes up for it. Giving up value constraints for safer enums is a trade you would never consider.