211–220 of 244 posts
Go and Python have OK enums. I will use them, but they could be simpler/more expressive. This begs the question: Is there an obstacle to releasing better enums in the next Python and Go versions? If the concern is about breaking backwards compatibility, I would be OK with a new type. Is it a culture issue, ie that Python and Go programmers don't use enums much? (Chick + egg here) Rust's enums are great. No "auto" boi…
Earlier quoted context omitted.
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…
So the inventors and maintainers of V8 and C are very bad language designers? I don't like either of those languages but those are aome pretty strong words.
Earlier quoted context omitted.
Typescript has actual enums. They behave just like Go's (for better or worse). It's not clear why Rust got confused.
yep, sorry about that, I misremembered TypeScript as having the same "kind of enums" as Rust.
https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
Go's iota is probably one of the worst ideas in all programming languages. Not a full typesafe enum type, the same clunky "enums" (assigned constants) available in C, but they bother to implement an auto-incremented counter. So you can't depend on the enum for exhaustiveness warnings e.g. on switch statements, type checking, or correctness, but you do get a useless numeric association autogenerated with iota - so tha…
Earlier quoted context omitted.
Appeal to authority. Also note that none of Wirth's Oberon variants have achieved any commercial success. Modula-2, which had enums, on the other hand did enjoy a limited success, across UNIX, PC and Amiga, and is nowadays even available as standard GCC fronted. Go would have been a failure if the authors weren't Google employees, like it happened with their Limbo.
Dart is a really good example. A dead language but somehow it was created by Google, what gives?
Nowadays I would bet there are more people using Flutter/Dart than either Xamarin, Cordova or React Native on mobile apps.
Also anyone using JavaScript libraries like scss, is dependent on Dart, at least until they remember to rewrite it in Rust, as is now fashionable on JavaScript tooling ecosystem.
Anyone writing a compiles to go, go++ yet? There are generators for better enums, sum types, and more. Bring them all together! I'm only kinda joking. Im also curious now if the Typescript checker was written in a way that it could be adapted to new languages easily.
https://github.com/goplus/gop , but they go slightly too overboard imo.
In the case of Goplus, it compiles to Go. Speaking of which, Vlang allows transpiling from Go and possibly to Go, but from and to C is more of their priority.
The intent of the Goplus author and contributors seems to be that their people could easily switch between both, but that their version is more feature rich.
Earlier quoted context omitted.
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.
It's all of the ergonomics of C combined with the bare metal performance of a garbage collector.
Earlier quoted context omitted.
I think they may be referring to if someone accidentally changes the ordering, either by inserting a new variant between two existing ones or by shuffling the order of the existing variants the value can change and cause problems.
Yes, but even with that interpretation, they claimed something much stronger: > The encoded value can change any time you re-compile your program Any value (not just enums) can change any time you re-compile your program, if some programmer goes in and messes it up. The real, much softer criticism would be that Go requires its programmer's to understand the potential consequences of inserting or shuffling enum values…
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…
Simplicity is a feature. Sure, how complicated can effective enums really be, but Go's general philosophy is to think hard (& sometimes for a long time) before adding every bell and whistle. I have a far easier time delving in to previously unknown Go code for the first time compared to something like Scala (or even Java). Go is a solid language for those who value that and want to enable the experience for others.
For example, to encode a JSON structure with a dynamic top-level key you need to write a custom marshaller OR marshal twice. That's... awful. Like bonkers level insane.
Earlier quoted context omitted.
> You're confusing unrelated features Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type sys…
You can't have closed enums without value constraints. Yes, some languages have been lazy and provided value constraints only for enum types. Which is an interesting choice: Give a noose for developers to hang themselves with for every single other type other than enums – the types they are going to use most often – and not think twice, but then go full on helicopter parent when using enums – the one type that isn't…
Sum types and closed enums don't need to constrain existing sets of values, they define the set of values. Again, I think you might be confusing the type system with runtime representation.
> It's a neat parlour trick, don't get me wrong,
It's a step towards sum types which are the mathematical dual of product types. Not a parlour trick at all, every modern language should have algebraic data types.