← Back to context

Comment by 9rx

20 hours ago

> proper enums

It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many.

Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though.

> sensible arrays & slices, without any magic and awkward syntax

Its arrays and slices are exactly the same as how you would find it in C. So it is true that confuses many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. Any improvements to help those who are accustomed to magic would require adding magic, not taking it away.

> iterators

Is there something about them that you find lacking? They don't seem really any different than iterators in other languages that I can see, although I'll grant you that the anonymous function pattern is a bit unconventional. It is fine, though.

> result unwrapping shorthands

Go wants to add this, and has been trying to for years, but nobody has explained how to do it sensibly. There are all kinds of surface solutions that get 50% of the way there, but nobody wants to tackle the other 50%. You can't force someone to roll up their sleeves, I guess.

[1] Rust uses enums to generate the sum type tag as an implementation detail, so its not quite as weird as it originally seems, but still rather strange that it would name it based on an effectively hidden implementation detail instead of naming it by what the user is actually trying to accomplish. Most likely it started with proper enums and then realized that sum types would be better instead and never thought to change the keyword to go along with that change.

But then again Swift did the same thing, so who knows? To be fair, its "enums" can degrade to proper enums in order to be compatible with Objective-C, so while not a very good reason, at least you can maybe find some kind of understanding in their thinking in that case. Rust, though...

> It has proper enums.

Well, then they look awkward and have give a feel like it's a syntax abuse.

> Its arrays and slices are exactly the same as how you would do it in C. So while it is true that trips up many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic.

In Rust, I see exactly what I work with -- a proper vector, material thing, or a slice, which is a view into a vector. Also, a slice in Rust is always contiguous, it starts from element a and finishes at element b. I can remove an arbitrary element from a middle of a vector, but slice is read-only, and I simply can't. I can push (append) only to a vector. I can insert in the middle of a vector -- and the doc warns me that it'll need to shift every element after it forward. There's just zero magic.

In Go instead, how do I insert an element in the middle of an array? I see suggestions like `myarray[:123] + []MyType{my_element} + myarray[123:]`. (Removing is like myarray[:123] + myarray[124:]`.)

What do I deal in this code with, and what do I get afterwards? Is this a sophisticated slice that keeps 3 views, 2 to myarray and 1 to the anonymous one?

The docs on the internet suggest that slices in go are exactly like in Rust, a contiguous sequence of array's elements. If so, in my example of inserting (as well as when deleting), there must be a lot happening under the hood.

  • Inserting elements in to a slice can be done quite easily since the introduction of the slices package to the standard library.

    https://pkg.go.dev/slices#Insert

    • You shouldn’t need a library to do this simple operation.

      I’m guessing the go language design went too far into “simplicity” at the expense of reasonableness.

      For example, we can make a “simpler” language by not supporting multiplication, just use addition and write your own!

      1 reply →

  • > Well, then they look awkward and have give a feel like it's a syntax abuse.

    So nothing to worry about?

    > how do I insert an element in the middle of an array?

    Same as in C. If the array allocation is large enough, you can move the right hand side to the next memory location, and then replace the middle value.

    Something like:

        replaceWith := 3
        replaceAt := 2
        array := [5]int{1, 2, 4, 5}
        size := 4
        for i := size; i > replaceAt; i-- {
            array[i] = array[i-1]
        }
        array[replaceAt] = replaceWith
        fmt.Println(array) // Output: [1 2 3 4 5]
    

    If the array is not large enough, well, you are out of luck. Just like C, arrays must be allocated with a fixed size defined at compile time.

    > The docs on the internet suggest that slices in go are exactly like in Rust, a contiguous sequence of array's elements.

    They're exactly like how you'd implement a slice in C:

        struct slice {
            void *ptr;
            size_t len;
            size_t cap;
        };
    

    The only thing Go really adds, aside from making slice a built-in type, that you wouldn't find in C is the [:] syntax.

    Which isn't exactly the same as Rust. Technically, a Rust slice looks something like:

        struct slice {
            void *ptr;
            size_t len;
        };
    

    There is some obvious overlap, of course. It still has to run on the same computer at the end of the day. But there is enough magic in Rust to hide the details that I think that you lose the nuance in that description. Go, on the other hand, picks up the exact same patterns one uses in C. So if you understand how you'd do it in C, you understand how you'd do it in Go.

    Of course, that does mean operating a bit lower level than some developers are used to. Go favours making expensive operations obvious so that is a tradeoff it is willing to make, but regardless if it were to make it more familiar to developers coming from the land of magic it stands that it would require more magic, not less.

    • Ok, so mostly we agree. And I was right that you can't just concatenate different slices (e.g. to remove one item from the middle), hence Go has to do a lot of work under the hood to do that. I count this as magic.

      2 replies →

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

  • As a C++ dev, such comments reinforce my hesitation to pick up either Go or Rust seriously :) It seems I already have the golden middle after all.

  • I like the language saying "it's not as easy as you think" when I'm about to do something ill-advised like roll my own mutable tree structure.

    • You understand that tree structures aren't just lookup tables, right? I wouldn't roll my own red-black tree (Jesus how tedious would that be). That's not what I'm talking about.