51–60 of 244 posts
So much so that much of the dotnet official stuff, ie asp.net, use static classes with string fields instead of enums.
Unfortunately that doesn't play well with libraries that have enum support like entity framework. PITA.
One saving grace is the ability to create extension methods on enums.
I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers! How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases w…
I think boneheaded is a good way to describe the evolution of go. It seems like the original authors were convinced most of the complexity of modern languages was unjustified and have slowly proven themselves incorrect over the years
Yeah it has evolved a bit since, but keeping the language simple is a worthwhile goal, so they didn't make rapid changes. It was intentional and thoughtful. If you want lots of language features, pick another language. I'll take my simple one.
Also: go enums do suck.
Earlier quoted context omitted.
The article is about enums, which are lacking in Go.
No, Go definitely has enums. It is sum types (that some people have recently started calling enums) that Go lacks.
Im also curious now if the Typescript checker was written in a way that it could be adapted to new languages easily.
I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers! How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases w…
Not even Java. The entirety of programming language development. Go is a language written by very good software developers but very bad language designers. It's an entire language of "why don't you just..." statements. Errors? Why don't you just return a value? Generics? Why don't you just use duck typing? Packages? Why don't you just use vendoring? In some cases these statements have some merit, but, as in most case…
Go does have generics, though.
> Why don't you just use duck typing?
Go doesn't have duck typing. It has structural typing, which is not duck typing. Duck typing is dynamic typing (at runtime), structural typing is static (at compile time).
> Packages?
Go does have packages.
> Why don't you just use vendoring?
In Go it's recommended to use versioned modules, not vendoring.
It has always been surprising to me how primitive Go really is, for no really good reason. I understand the evolution of C, it made perfect sense back when it was invented. And the limitations were necessary due to the wide array of architectures and extremely limited computers of the time in every dimension (CPU speed, IO speed, RAM size, disk size, etc). Many of those dimensions have been improved by several orders…
At the same time, Go has generators built in and can generate enum tables, enum to strings, and other things they have shown. I am unsure why they didn't do it the "Go" way.
Cries in I18N...
Earlier quoted context omitted.
> Go has constants That's literally what enums are: A set of named constants. You might be thinking of what is traditionally known as sum types, which some people have recently started calling enums[1]. Indeed, Go does not have sum types. [1] Presumably because of Rust using the wrong term when specifying its sum types
is there any further information on why Rust and other recent languages have started using `enum` to refer to sum types? I don't use Rust or TypeScript (edit: apparently TS doesn't have this, my memory is bad) or any of those languages and it's been very strange to see this redefinition occur
[0] https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml