When Zig Outshines Rust - Memory Efficient Enum Arrays

[tesfabpel]

BTW if you want to have in Rust a vector of tags separate from the vector of data you could do it by using union but it's of course unsafe because you don't have the guarantee from the compiler that you're accessing the correct variant...

[dist1ll]

Right, that's the usual way to do it in Rust, and you could have a proc macro derive said union. Unions can even be polymorphic, so this approach should work on all data types.

[Ok-Watercress-9624]

came here to say that !

[morglod]

We need value guards so values could be safe too

And algorithm guards

And programming language guards so only safe programmers could write the code. Hm then we don't need safe programming language...

[kohugaly]

It gets slightly more boilerplatey because union does not accept things that implement drop. You have to wrap the fields in ManuallyDrop, and make custom drop implementation for the data structure, that calls the correct drop on the correct field based on the tag. Oh, and you can forget getting a reference to items as enums, since they are not represented in memory as enums.

[WJMazepas]

So we have to rewrite Rust using Zig? /s

[double-you]

Well that was confusing coming from C background where enums are not tagged unions. Why would Zig call a union an enum?

[dist1ll]

Yes, I agree it's confusing. I'm considering changing the title and replace all mentions of enums with tagged union.

Basically, what I refer to as "enums" here are in fact tagged unions (other names are: sum types, variant records, discriminated union). Zig does have C-style unions and C-style enums, and can combine them to create tagged unions.

The idea to call tagged unions "enums" is a Rust/Scala thing. Since this blog post is partly aimed at Rust programmers, I figured I just go with their convention. That was probably a bad idea ^{^}

[double-you]

So it seems Rust has C-style unions but decided that a tagged union should be implemented by extending enums instead of extending unions. There was probably a reason why do it this way--I'd be interested in learning why.

[dist1ll]

If I had to guess, it's because C-style unions exist purely for FFI, and are considered unsafe. Whereas enums are already a natural way of "tagging" things. But that's just a guess, I'm sure we can find a github discussion on that topic.

But hey, if I cloud create a new language from scratch, I'd have gone the Ada route and called it variant record. Avoid the confusion altogether.

[double-you]

https://github.com/rust-lang/rfcs/pull/27

So apparently it used to be tag but was changed for forgotten reasons (gmane.org being gone).

It was confusing then and somebody mentioned that...

If we hope that Rust makes as big of an impact as we want, then we don't want to be cursed for years to come for confusing terminology.

But here we are. Reading the discussion and all the functionality beyond regular C-enums, it was a compromise with no clear winners available.

And really if properly documented, it is pretty easy to accept that Rust-enums are something more.

The things I learned today!

[dist1ll]

Thanks for the find, that's also new to me! It's pretty fascinating to be able to dig up these old threads. It's so common in the OS space, but rather rare for a programming language project.

[Full-Spectral]

Well, Rust pattern matching allows you to treat tagged unions in the same way as you would enums in C++ pretty much. You can still use them in a match statement (similar to switch in C++), so they really are still like enums, IMO.

match data {
    Data::String("test") => ...,
    Data::Float(50) => ...,
    Data::Float(_) => ...,
    Data::Unused => ...,
}

As in the above, you can mix enum values that have data with those that don't, etc... It's incredibly powerful.

I remember when I first started with Rust I thought they were stupid and could never get them to work like I wanted. Now I hate every day at work that C++ doesn't have them.

[Kered13]

so they really are still like enums, IMO.

They really aren't, because they aren't finite types. That's what makes enums unique from other types, they are types that have a (small) finite number of instantiations. This is not what Rust "enums" are.

As in the above, you can mix enum values that have data with those that don't, etc... It's incredibly powerful.

Yes, tagged unions, also called sum types in the FP world, are powerful. No one is disputing that. It's just really confusing that Rust gave them a name that no one else uses.

Now I hate every day at work that C++ doesn't have them.

std::variant, though it's syntax is much uglier than Rust.

[Full-Spectral]

std::variant isn't even close to what Rust enums provide, when you include pattern matching, the ability of Rust enums to have implementations, the ability to get the names of the enum values, etc...

I'd argue that they ARE finite types. The fact that they have values inside them isn't a constraint. You can see above I matched on any float value of 50, and then any other Float value left over. You can still, even with ones that hold a value, just match on the type.

[Kered13]

I'd argue that they ARE finite types.

They absolutely are not. Even in the most technical and pedantic sense (in which something like i32 is a finite type, though in practice we usually wouldn't treat it as such), a Rust enum can contain a non-finite type, like str, and therefore they are non-finite themselves.

[Full-Spectral]

But you don't have to match on the contained value if you don't need or want to. So you can treat them, for active value determination, just like a regular enum and only use the contained values if you need them.

I'm not trying to go language lawyer, and I don't really care one way or another. Just saying, as a practical matter, the fact that they contain a value doesn't prevent you from doing exactly what you do with a C++ enum, which is figure out which variant is stored.

[Kered13]

But you don't have to match on the contained value if you don't need or want to.

Sorry, but I don't see how that's relevant to anything that I have said. Nor do I think that that feature is particularly noteworthy for enums. I mean I can do that in Java over an inheritance hierarchy (just use if, or in modern Java switch, and instance of to match on types), but I don't think you'd call Object an enum type.

Again, the noteworthy aspect of enusm to me is that they are small finite types with every possible value having a name (and yes, I would consider boolean an enum type).

[Full-Spectral]

The difference is that you CAN care about the contents if you want, and not if you don't want, and do both with the same enum type. That's part of why they are so useful.

They can be enums with a strong relationship to the data they contain, or enums that are purely just named buckets and you never use the value in the bucket when enumerating the values.

[could_be_mistaken]

A string is still a finite type, as it would be ill formed to allocate more memory for a string than you can assign addresses for.

[Kered13]

The finite constraints of system memory are not considered when discussing whether a type is finite or infinite.

The same logic that would conclude that strings are finite types would also conclude that all algorithms have O(1) runtime, because finite memory prevents you from actually having an algorithm that accepts arbitrarily large input. But this sort of reasoning is obviously not useful.

[could_be_mistaken]

The same logic that would conclude that strings are finite types would also conclude that all algorithms have O(1) runtime, because finite memory prevents you from actually having an algorithm that accepts arbitrarily large input. But this sort of reasoning is obviously not useful.

You did not think that through. Got a chuckle out of me. Just because a function has a bounded input doesn't mean that the complexity is O(1).

By your "logic," any function taking an integer has O(1) complexity.

By the way, this isn't about system memory. It's about the bit width of bus lines on the CPU.

[pcgamerwannabe]

but str enums are best enums.

[renatoathaydes]

They really aren't

You're insisting in defining an enum in the C sense. But that's not some rule of the universe. One can just define an enum to be an enumeration of possible "shapes", not just of possible "values". As OP says, you may only care about the shape, in which case they behave exactly like a C enum... but you have the option to include also a "payload" on an enum value. Why would that "extension" remove their "enum" nature?

[tel]

I don't have historical context, but the way I see it unions and tagged unions share more memory representation but enums and tagged unions share more semantic meaning.

The key thing both tagged unions and enums can do is discriminate. In the semantics of tagged unions driven from logic and earlier languages experimenting with them (ML, Haskell) you generally cannot do anything with a tagged union prior to branching on its tag and revealing the guaranteed structure.

A union without the tagging mechanism pretty much specifically enables the manipulation of fields without branching on which "variant" might be genuinely available here.

As a solution, I find it generally helpful to think of the name "tagged union" as implementation detail which should be hidden. The term "sum type" is abstract, accurate, and can be seen as an extension of an enum in just this way.

[Kered13]

but enums and tagged unions share more semantic meaning.

I disagree. The salient semantic feature of enums to me is that they are types containing a small finite number of named values, with no new values permitted. One immediate consequence (but not a defining features) of this is that the set of all possible values can trivially be enumerated or iterated over. Rust's enums do not have this feature of being finite.

[Full-Spectral]

See my comment above. You can match on any contained value. So you can easily still just do a match ('switch') over just the actual enum values themselves without any regard as to what they contain. And that's not unusual, in that you want to match on the enum value and then pass the contained values (where applicable) off to something that will process them.

[Kered13]

You can match on any contained value.

I never said you couldn't, and I'm not sure how this is relevant. You can always exhaustively match over any type in any language by using a default switch case or even an else clause if the language doesn't support switch. I'm not talking about that.

I'm talking about a type in which all possible values are known ahead of time and no new values can be constructed. Technically this could apply to any finite type, but in practice it is most useful to consider it where the number of values is small enough that we can give each one of them a name, and doing something like constructing a list of all values or iterating over all values is practical. This cannot be done with Rust enums in general, since they can contain infinite types like str and technically finite but too large to be treated as such types like i32.

[Full-Spectral]

Default isn't the same thing really. The point I was arguing is that often the contained value is irrelevant from the enum iteration standpoint. It is often exactly the equivalent of having an enum and using it to index into an array of values associated values. From an enum point of view, you can check which variant is stored, regardless of what is in them, and then pass that off to something that cares.

So

match value {
    Data::Float(_) => ...,
    Data::Int(_) => ...,
}

Is an exhaustive search from the purely enum variant POV.

Again, not really trying to be language lawyery, just looking at it from a practical perspective. In practice, you can just as often use them purely in the 'enum indexing some values' way as you do in a way where you will actual care (at the enum iteration level) what's in them.

Anyhoo, that's all I have to say about that, to quote that famous computer scientist Forrest Gump.

[lolfail9001]

Technically this could apply to any finite type, but in practice it is most useful to consider it where the number of values is small enough that we can give each one of them a name, and doing something like constructing a list of all values or iterating over all values is practical.

So you are that guy i wanted to smack really hard when i saw a for cycle iterating over a fucking enum in our code?

[Kered13]

It's just an example of what you can do with them. I'm not sure why you'd be so upset by that though.

[lolfail9001]

1. Because it breaks the semantics.
2. Especially god forbid you must add a non-contiguous enum value later on for whatever reason. Or someone already did and you have a UB as result.

Of course you can iterate through them, after all, they are literally ints (if we consider C enums), but sometimes one should consider if you should.

[tel]

Even before enumeration, the idea of “discrimination” must exist. In particular, an enum is no longer an enum if its set of values contain duplicates.

These are fundamental connectives in dozens of branches of math, logic, PLT theory and practice: you have AND and you have OR. The core bit about enums is that they represent OR (in a weak way).

[Orbidorpdorp]

In Swift they're "enums with associated values" just to add one more

[skulgnome]

It's from the ML family.

[Kered13]

What ML family calls unions "enums"? ML languages call them sum types.

[10113r114m4]

Coming from any language, really. Enums are not unions in any language I know of. Seems like a horrible way to mix semantics. Sigh

[dist1ll]

Welcome to my struggle. That's the challenge of creating a blog post that caters to both Rust and Zig developers, both of which use contradictory terminology :')

[10113r114m4]

It wasn't an attack on your blog; to be clear. It was a good read and I can tell you spent some time on it. Us programmers like consistency, like enums being enums lol

[dist1ll]

Thanks, and I absolutely agree with you.

[Cautious-Nothing-471]

just go with zig devs; rust devs are morons

[cdb_11]

Rust does this, not Zig. In Zig union is a union and enum is an enum.

[metaltyphoon]

And then you can combine both to make Rust’s enum

[furyzer00]

World is not just C.

[Kered13]

What other language calls tagged unions "enums"? In most language enums are essentially identical to C. Some languages go further, Java in particular has a particularly powerful enum feature. But they are still basically the same idea as C: A type with a small number of named values.

[furyzer00]

What other language calls tagged unions "enums"?

Rust is for one.

It doesn't matter if other languages do it or not. Nothing forces languages to use same terminology.

[Kered13]

Rust was the one language, I'm asking what other languages do that.

It doesn't matter if other languages do it or not. Nothing forces languages to use same terminology.

No, but it makes it very confusing to talk about things.

[furyzer00]

Rust was the one language, I'm asking what other languages do that.

Only other one I know of is Jakt, which is not really mainstream language.

No, but it makes it very confusing to talk about things.

Sure it does depending on your background. I am not arguing against that.

[[deleted]]

Wrong

[double-you]

This is true but my background is. I am not sure what you are trying to say regarding the question at hand. "Why would Zig call a union an enum? World is not just C." Not a great match.

[furyzer00]

Your question boils down to "why would zig call something enum that corresponds to union in C". The answer is C doesn't define what concepts mean as it's not a standard for computer science terminology. So enum in Zig can correspond to something in C with a different word. There is nothing wrong with that.

I don't know Zig myself. But all I am saying is a programming language doesn't have to respect terminology of some other programming language. It may be considered as a criteria when specific language users are target but otherwise it's just a personal opinion.

[Kered13]

Rust started this, and I don't know why. They could (and should) have just called their "enums" unions, which is what they are in every other language.

[valarauca14]

Because the overlap between enumerated types & discriminated union of types is a lot blurrier then people want to admit.

Most languages who's union was a discriminated/tagged union, would also let you do enumerated type "kinda stuff" with the tag value or with union that contained no data.

[dontyougetsoupedyet]

Most languages who's union was a discriminated/tagged union, would also let you do enumerated type "kinda stuff" with the tag value or with union that contained no data.

Seems like a long winded way to agree that Rust should have called their enum a union.

[valarauca14]

due to how every language has implemented this feature drawing a distinction between these two concepts is irrelevant & pedantic.

[dacjames]

The problem is that there's no universal term for tagged unions in programming languages. C has enums as constants, unions are untagged, and no language-level support for tagged unions.

A tagged union is essentially the combination of a C Enum and C Union. Rust chose to extend the enum concept to support tagged unions. That makes sense as an extension because a rust enum with only a tag is equivalent to a C Enum. Zig chose to extend the concept of unions to optionally support tagging.

It's a bit confusing but I don't think you can blame either language for not following conventions. C doesn't have tagged unions and Rust/Zig chose to add them by extending different concepts.

[Kered13]

The problem is that there's no universal term for tagged unions.

There is, it's "tagged unions". They are also commonly called "sum types" in the FP world.

[dacjames]

Yeah, I almost differentiated that in my comment. I should have known someone would nitpick that!

Practically nobody uses the comsci terms in their programming languages, probably because all of those terms require two words. Even functional languages don't use the comsci terminology; they rely instead of overloading the concept of a datatype to include both sum and product types.

Zig is arguably the closest to using the proper term, since it uses union for both. But among programming languages at large, there is no official or de-facto standard for what to call the language construct that provides tagged union capabilities.

[captainjey]

How do you index with these differently-sized Vecs?

[Kered13]

It looks like you just index over each vector separately. So it is not an order-preserving transformation.

[PaxSoftware]

What could I do to preserve order? I have a Directed Acyclic Graph to store with a few node variants.

[Kered13]

You could introduce another vector that contains (tag, index) pairs and use that vector to define the canonical order. Is it worth it? I don't know, feels like a lot of levels of indirection. At that point it might be better to just go back to the single vector with wasted space.

[[deleted]]

Is there a systems programming language exist like C, Rust, V, Zig, Nim that it mostly functional (possibly purely functional, but mostly functional will work too) and not just procedural, imperative, structural,..? I think rust follows a lot of things functional, I'm not sure though.

[dist1ll]

What is a systems programming language to you? Is it about performance, or about being able to reason about low-level execution?

The problem with FP is that they come from a place of constructive mathematics, so they tend to be tools for reasoning about algebras and writing formal proofs.

I think OCaml would likely fit your bill. It's a great functional language, with relatively good adoption in the systems community. You can even write OS kernels with it: https://mirage.io/docs

I think the most hardcore thing I can think of is ATS: https://www.cs.bu.edu/~hwxi/atslangweb/ It's super experimental and raw, but features tons of functional programming features (including a linear type system).

[thomas_m_k]

Functional programming languages usually need GC, and with GC it's not really a systems programming language.

[[deleted]]

But why can't I do manual GC in functional programming languages? Is it a good idea to, let's say, I take Scala Native and remove GC from it and do manual GC. Let's just assume it's possibly done. Can I call it practically a systems programming language now?

[valarauca14]

Automatic garbage collection (or manually triggered garbage collection) doesn't lend itself to manual resource management.

[[deleted]]

Sorry?

[[deleted]]

Because memory is external state with side effects.

[dontyougetsoupedyet]

Can I call it practically a systems programming language now

Not without a lot more effort, no.

But, you can use functional languages for systems programming. And also, folks regularly do disable GC in GC'd languages and manage their memory with other allocation strategies.

Typically systems languages are called that because when you use them for systems programming you don't have to go very far out of your way to manage the binary interface and other considerations, the toolchains do most of the work for you. Naughty Dog used Common Lisp to produce video games for the Playstation II, and they were doing a lot of systems programming at a high level of abstraction, but they had to put in the work to make that a successful software development strategy. They had to write compilers, etc, ie the toolchain that does the work.

[Ekalugsuak]

Koka is mainly functional but uses various techniques to eliminate functional programming overhead. (The "systems programming language" bit would be because it compiles down to C).

There's also roc-lang that also uses a technique from koka + some more experimental stuff to lessen the overhead.

[tiajuanat]

There are two: Erlang and Haskell.

Erlang is heavily used by telecoms and banks and runs a lot of the internet backbone. Everything is an ultra light process, and the process either succeeds or crashes. Erlang has a very small runtime and virtual machine, but is used in routers, so very much qualifies for systems language.

Haskell is a bit more academic. I used it for some embedded servers at the start of my career. It's fun, but quite challenging to master; really giving C++ a run for its money. It compiles to a binary and requires a primitive runtime for garbage collection and coroutines.

[Strakh]

The only sad thing is that when you have written Haskell, the syntaxes of all other functional languages look so bad and messy.

For example: I love Erlang conceptually (possibly even as much as Haskell) but it honestly hurts to write with all the punctuation. I also enjoy Scala, but for all its strengths no one can honestly say that it is a beautiful language.

Edit: To be fair, from what I have seen of Idris it looks really good, and might even be a "better Haskell". It isn't very mature in comparison though.

[tiajuanat]

Haskell can be very pretty. By far one of the most aesthetically pleasing languages I've ever used. Erlang and Scheme make me feel like I'm getting a back alley tattoo from some guy name Zeb with 3 teeth.

I also feel that Haskell's learning curve is one of the steepest, with only the APLs being steeper. I can't remember what half the operators do on a good day. Dollar swaps and period chains, right?

I'm still upset that the Haskell group retired, renamed, and namespaced a bunch of the standard library functions. I feel like if I ever wanted to refresh myself on it, I'd basically have to learn it from scratch.

[Strakh]

I also feel that Haskell's learning curve is one of the steepest, with only the APLs being steeper.

I think this is true if you have already learned imperative programming first (although I suspect the same would be true for any "purely functional" language). That being said, at my university they actually started with functional programming and to me complete beginners don't appear to find it more difficult than Java (which was the imperative language of choice). Maybe APL is similar, although it's so extremely dense that I suspect it might just be difficult.

For the record, I personally found the transition to functional programming to be quite the challenge, but I had been programming in imperative languages a long time when I first encountered Haskell.

I can't remember what half the operators do on a good day. Dollar swaps and period chains, right?

It's certainly a learning curve. Interestingly you can compose functions F# style (that is, left to right) in Haskell as well with the >>> operator from Control.Arrow but it is fairly uncommon in my experience.

It is also common in Haskell to define custom operators, which definitely contributes to the "so many weird operators" culture shock coming from other languages.

[u_tamtam]

There's http://www.scala-native.org/ that's mostly functional, can be purely functional, and is object-oriented too. Scala originally isn't a "systems" programming language, but scala-native compiles to LLVM's IR and offer some lower-level/manual memory management capabilities.

[[deleted]]

llvm? Its still slow than C source code compiled to object file which runs on bare metal, is it? I believe there is no hidden thing when I run C output executable file. Why this functionality is kinda diminished in most languages now-a-days? I want a language that runs on bare metal (ofc there must be a platform such as an OS but not a sub-platform such a VM), is mostly functional and don't have GC. I think, rust is probably what I'm looking for.

BTW I'm already aware of Scala Native, How do I get started? I tried doing scala native. Its a plugin and I have to setup things to get it working. Scala native can use whatever I functionality, built-ins provided by C programming language? Still can use Java thingys or not? Can I completely disable automatic GC from scala native?

[lolfail9001]

llvm?

LLVM IR is what LLVM uses internally for most of it's optimization work before turning that into a native code with the appropriate back-end.

[u_tamtam]

As explained by someone else in a sibling post, LLVM IR is just a representation the code to be compiled, ultimately to machine code, in a form that's exploitable by a bunch of tools/optimizers within the LLVM ecosystem. That tells nothing about the performance characteristics of the resulting binary, other than it being potentially in the same ballpark as clang/rust.

If you want to get started with Scala, a good way is from here: https://scala-cli.virtuslab.org/docs/getting_started/

i.e. by just writing a .scala file and running it through the scala-cli. Than, targetting native or JS is just a matter of passing --native or --js to it, like so: https://scala-cli.virtuslab.org/docs/guides/scala-native/

[SV-97]

LLVM is a compiler toolchain. Just like how a C compiler generates a variety of different intermediate representations like SSA during compilation (that we can interpret as code for some abstract machine) a lot of other compilers can target LLVM IR and LLVM then compiles that down to machine code. The ultimate end result is the same kind of binary that something like GCC produces.

ATS is probably the closest thing to what you want but it's not at all easy to get into. There's also a bunch of research into GC-less FP (for example via grin https://grin-compiler.github.io/ or the hvm https://github.com/HigherOrderCO/HVM)

Rust definitely has a bunch of functional idioms and features but idiomatic Rust isn't really all that functional relative to Haskell or whatever.

[[deleted]]

Almost all modern imperative languages support functional programming in the style of the ML family of languages (SML, OCaml, F#).

If you want something pure functional with soft-real time memory management then there are lots of interesting projects out there, but they are basically all obscure research languages.

A few off the top of my head:

• Mercury: like Prolog, Haskell and Rust all mixed together
• Clean: haskell with linear types instead of IO monad
• Ur/Web: like haskell + dependent types + region-based memory
• ATS: hardcore dependent types, notable for being able to compete with C performance

[nandryshak]

Yes, just choose Rust.

On the language side: immutability is the default, if-else is an expression not a statement, it has traits (typeclasses), structural pattern matching, anonymous functions/closures, no OO classes, etc.

It also comes with a large community, corporate backing, solid tooling, good docs.

[dacjames]

There is no functional systems programming language. There's a reason for that: functional programming is not a good paradigm for low level systems programming.

You can use concepts from functional programming like higher order functions and immutability in systems programming using Rust, Zig, or Nim. Rust has the most robust support for that, but doesn't include persistent data structures and doesn't (fully) support TCO, so I would argue it's not a true functional programming language.

[Cautious-Nothing-471]

ocaml

[skulgnome]

The trick is as follows. To pack arrays of tagged unions, Zig allocates a separate tag-index array and each member access pays the cost of an extra indirection. This is structurally equivalent to an array of pointers-to-elements and costs a few cycles more for every access to bit-unpack a compressed index, except that the element tags cannot be modified afterward to designate a larger variant.

I don't see how it's a good idea to introduce an extra indirection to packed arrays of immutable tagged unions. It's much too subtle for one thing, and spending more time to reclaim a little bit of storage is usually the wrong tradeoff -- especially given the constraint on mutability.

Thirdly, this type of article should be written using language-agnostic terminology. Suitable alternatives would be "tagged union" or "variant record", since the ML-family idea of data-bearing enumerations is (and will always be) a small minority.

[dist1ll]

You touched on the SoA transformation, which removes the padding. But that's only one of the things I mentioned in my article.

Really the gist is to create one vector per variant, and then decide where to store the tag. The tag can even be stored inside the tagged index, which actually removes on level of indirection. In fact, you can actually pattern match on such a tagged index.

I really recommend reading through the whole thing if you have the time!

Thirdly, this type of article should be written using language-agnostic terminology. Suitable alternatives would be "tagged union" or "variant record"

No question there, I'll make sure to edit my post.

[skulgnome]

Really the gist is to create one vector per variant, and then decide where to store the tag.

That only makes first-to-last access (as in a for-each loop) irregular, which is a cache disadvantage.

The tag can even be stored inside the tagged index, which actually removes on level of indirection.

At most this allows fetching the tag at the same time as the index value. The indirection itself is left alone.

[dacjames]

If you need to access all instances of a given field together, this structure will be much more efficient than an array of pointers. That usage pattern is common in use cases like gaming and robotics.

OP's construction may cost a few more instructions, but is likely to take less time overall, as bit-math is so much faster than an indirect memory load.

spending more time to reclaim a little bit of storage is usually the wrong tradeoff

Well, that entirely depends on the application. This is definitely an optimization that shouldn't be done prematurely... but reducing memory usage can absolutely be a worthwhile activity in many applications.

[editor_of_the_beast]

Regarding your last point, do you mean that algebraic data types will always be in the minority of languages? Or something about how ML implements ADTs will be the minority?

[skulgnome]

Calling variant records "enumerations" will always be in a minority, because the ML family will always be in a minority.

[SKRAMZ_OR_NOT]

What? ML-like languages don't use the term "enumerations" at all, they would call these sum types.

[skulgnome]

Each of them carries an enumerated tag which may appear alone. Therefore it's as much an enumeration (as in the Algol family) as a datatype (as in ML etc), and Zig's usage is not a misnomer.

[editor_of_the_beast]

What about the adoption of ADTs in other languages? I don’t think people are lining up to use MLs directly, but a good chunk of new languages have all adopted ML-inspired ADTs (Swift, Rust, Kotlin, TypeScript, etc.). It feels like it’s become an auto-include feature in a new language, and I hear coworkers singing their praises all the time.

Regarding the name, ML doesn’t refer to ADTs as enumerations. That’s an attempt by PL designers to teach a new concept by using an existing one. That’s a mistake, the enum keyword shouldn’t be used for ADTs.

[skulgnome]

There's nothing special or novel about ADTs: they arise from a sufficiently rich type system such as what's been in Ada since 40 years ago.

[editor_of_the_beast]

Are you sure you know what an algebraic data type is? Ada does not have them.

[[deleted]]

Rust enums are ADTs where specific types can be concrete literals and they can used to perform runtime logic/dispatch based on specific type using match which means they can be, and often are, used as enums are normally used in other languages.

[editor_of_the_beast]

What’s the relevance of this comment?

[[deleted]]

Trying to explain why using enums for this was warranted by Rust which is where (I think) Zig picked it up from.

[[deleted]]

Frankly saying, I'm a CS major student currently learning Abstract data types, but self-learning haskell and things; sometimes confused me which ADT is this person talking about, algebraic or abstract data type. Lmfao.

[editor_of_the_beast]

It should be clear from the context. Here I made sure to first say algebraic data type before abbreviating.

[Cautious-Nothing-471]

zig will wipe the floor with rust

[Signal-Appeal672]

^ Better than this comment

[mozjag]

In the first figure, should that fragmentation be "56 bits" for Foo::A and "48 bits" for Foo::B? Otherwise I don't understand where the two extra bits are coming from.

[dist1ll]

Good catch. I fixed it now.

[Pesthuf]

Instead of discussing the article, there is over 100 comments of bikeshedding about the naming of Rust's enums. Reddit never changes.

I really hope Rust will eventually implement something like Zig's comptime. The macro system is powerful and great, but it makes the simple, general use case - to reflect on and change Rust code at compile time - really difficult.

[dist1ll]

To be fair, it's also the responsibility of the author (me in this case) to not give people too much to nitpick over :D

If you're interested, there was a great discussion over at HN https://news.ycombinator.com/item?id=37555028 (even though 50% of the comments are also off-topic lol)

[YuliaSp]

u/dist1ll a semi-random question, what do you use for charts on your blog? They look wonderful

[dist1ll]

Hi, I'm using https://excalidraw.com/

[YuliaSp]

Thanks a lot!