An unordered list of things I miss in Go

To be precise, Rust does provide an ordered map in the standard library, it's std::collections::BTreeMap. However, iteration order is key comparison order, not insertion order.

If you're using a central dictionary then it should be worst case O(log n), but the price you pay for that is attacker controlled allocated memory growth.

Technically no.

Rust does use per-hashmap seeds for its keyed hashes (where many languages use per-process seeds).

Go does that, will also randomise iteration for each iteration (it randomises the start offset of the iteration). This latter operation has nothing to do with hashdos mitigation, and exists exclusively to frustrate accidental reliance on iteration order.

The insightful comment said they were sure that whoever was implementing the UI noted the list of destinations was always ordered, so never bothered to sort out themselves. And I guess the data source never guaranteed it was ordered, it was just a coincidence, and one day they stopped providing the list in-order.

Author here.

The particular case where this behaviour took me by surprise was when I wanted to print all available options from a toy CLI program that I wrote. I defined the options in a map (that had a function handler as a value) and didn't care about the order at all, but at least I expected the print order to be stable.

So it took me by surprise when I ran the program 3 times and the order changed. First I thought I did something wrong, then I found the issue after some search.

Now, it can be argued that this behaviour was good because I ended up sorting the values before printing, and now they have a predictable order. But I still think this was that kind of code that I didn't have to write (thanks to how Go works, I need to create a separate list and sort it instead; I think it is better with iterators in Go 1.23 though).

> Because if you relied on it being conveniently stable within the same Go version, with no guarantees, your program would still be broken (reproducibility wise), if they changed the hashmap implementation.

Well, not in this particular case. I just wanted it to print it in a stable way between multiple runs of the program. Again, maybe this whole thing helped me write a better program. But I still feel that it is unnecessary, and would prefer to just use a orderedmap instead.

I am leery to tap into a new ecosystem, but the risk in this case might not be terrible. Theoretically, you could always take the transpiled code and port to idiomatic Go if the project died.

The author does not seem to require iterating over a sorted list. Sorting is not the same as ordering. An ordered map is a map in which the insertion order is preserved when iterating over the elements. A sorted map outputs the elements in an order defined by a comparison function when iterating, regardless of their insertion order. You can for example sort alphabetical in case of string keys.

Good thing that's not what they are asking at all. They just want an ordered map to be in the standard library.

> That imposes an unnecessary performance overhead to support a small subset of use cases.

Naturally ordered hash maps generally have a small performance hit on lookup and a performance gain on iteration, as iteration goes through a dense array.

Linked hash maps do tend to have worse performances for all cases.

> I think what the author requires is iterating over a sorted list of keys.

Had they needed that, they'd have said that. But they did not. And they specifically refer to an ordered map, and to Python's built-in and Ordered dicts, which are not sorted.

It’s like having an unstable sort as the default standard library sort function. People reasonably expect that when calling sort twice the second sort to do nothing, but you can always find people who will passionately argue that people deserve to get burned if they assume a sort function is stable.

1. Just a hash table, Rust's std::collections::HashMap, C++ std::unordered_map, Go's map

This type is not about the "order" of its contents. If you want the "order" in any sense, that's not what this is for and you have the wrong type just as surely as if you were surprised that your integer type can't store a half. Types of this kind can be optimised to provide extremely fast indexing by key which is why they exist as this is useful in many problems.

2. A container arranged by the value of the keys, Rust's BTreeMap, C++ std::map

This type is about the order of its contents by value. It doesn't matter when you put a 4 into this container, it goes between 3 and 5 anyway. This type is good when you need to work in that "by value" order later, for example to take the "Most important" item or the "Soonest". It doesn't remember the order in which things were added, and it is relatively slow to find items by their key.

3. A container forever arranged by order of insertion, Python's OrderedDict (and dict), in Rust that's https://crates.io/crates/linked-hash-map LinkedHashMap

This type remembers the order in which you inserted items into the container and can give them all back in that order efficiently. In other ways it's like the first container, but it compromises performance significantly to deliver this "order" promise.

It is problematic that people talk past each other on this, both in terms of a useful discussion on HN, but much worse in a Software Engineerign team if you thought you were being given an OrderedDict, but it was actually a BTreeMap for example.

Python chooses to provide (3) because Python is slow anyway so why not at least provide the least surprising container given how slow the language is. The existing Python dict was so awful that OrderedDict is actually faster (not fast in the wider scheme of things, but faster than that) so that's good enough.

Using pointers that are nillable whenever I want to have an optional value. How did I solve the usability problem? I just introduced 2 simple methods: Or and Of. First one will resolve ptr to a value or default if nil (provided in param) and the second one will make a ptr from a value type. That is actually all you need! Don't have the code here or I'd post it but it's easy enough to make your own (with generics).

It's neither possible to have a const but nilable value as well as it's not possible to have a non-nilable mutable value

OrderedDict types are nice sometimes but shouldn't be the default behavior, IMO.

There are good reasons for the second point (about default/named parameters) -- any calling code is making some assumptions based on that default value so there's a risk it can't be changed or added to. If you really want a default value, make a wrapper function for it. In the example it would be a simple matter of defining ReplaceAll with three arguments that always passes -1 to Replace(...)

Blocked channel reads and writes are unblocked in FIFO order, not random. Mutexes are similar (afaict not quite identical, but the intent is the same).

Go randomizes a lot and I am thrilled they do that, and I knew about mutexes already, but the chan part was a surprise to me. It's reasonable and matches mutexes, so that's probably for the better, but still a bit oof.

    % repeat 5 perl -e '%h=(a => 1, b  => 2, c=> 3); print for keys %h; print "\n"'
    bca
    cba
    bac
    bac
    bac

That's why we don't do `load` and `load_safe`; we do `load` and `load_unsafe`.

    for _, k := range slices.Sorted(maps.Keys(m)) {
        v := m[k]
        _ = v // do something with k and v
    }

    keys := make([]string, 0, len(m))
    for k := range m {
        keys = append(keys, k)
    }
    slices.Sort(keys)
    for _, k := range keys {
        v := m[k]
        _ = v
    }

It takes about 3 ns to choose a random starting bucket, which is basically free relative to the iteration itself.

Weird

An "ordered map" is not a hash table. I think they want a tree.

But you can get the keys and sort them.

I really do not see the problem

Use a tree if order matters, Hash if not.

(Since I am not a Go programmer, maybe I missed something)

This is incorrect (or I’m misunderstanding you). OpenJDK’s HashMap doesn’t use randomization, and the iteration order is thus deterministic under that implementation, although the API specification does not guarantee it. To mitigate DoS attacks, keys in the same hash bucket are stored as a balanced tree. For keys that implement Comparable (strings in particular), this guarantees O(n log n).

Function overloading could easily handle context with and without arguments.

Randomness is bugs. Adding randomness to a language is adding bugs.

Author here.

I never assume that hash maps can be iterated in the same order as the insertion in any language, however the fact that in Go each iteration results in a different ordering is surprising.

    func must(err error) {
        if err != nil {
            panic(err)
        }
    }
    func must1[T any](v T, err error) T {
        must(err)
        return v
    }
    func maybeError() (bool, error) { ... }

    result := must1(maybeError())

So this is why I don't care that much about having a syntax sugar for this operation anymore in Go.

That said, I think given the current state of the language, adding nullability would be much easier to do than adding Union or Sum types. And from my experience with Kotlin, nullability already gives much of the benefits.

I am not saying I will not change my opinion in the future. I got my first job working with a language that has algebraic types (Scala), so my opinion may change in future. However, even if it changes I think getting Union or Sum types in a language like Go is impossible, while nullables are unlikely to happen but at least not impossible.

This wouldn't be such a problem, since of course you can just "choose" to not use pointer- or interface-typed fields in "your" structs, but as soon as serialization, databases, or other people's APIs are involved, you don't have that "choice" anymore.

In the same vein, being unable to write e.g. &true or &"foo" is annoying too. If I can write &struct{...} why can't I write &true?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

From practical standpoint, a project with Nullable: enable, WarningsAsErrors: nullable has almost never have to think about unexpected nulls again - a solved problem.

I prefer the go style of doing a check every time rather than some of the time with the risk of missing a time. Or on the flip-side simply defining your own default.

I know that a lot of people like how C# is becoming more and more reliant on the compiler to handle type checks, but it also opens up the risk of more developer mistakes. It’s mostly down to opinion and preference. So I don’t think you can really call it a “problem” as such. Having nullability will be a feature to some, and not having it will be a feature to others. I think both decisions were right for their respective languages. C# needs it for its close integration with mssql and its exception handling. Go doesn’t want it because it favours simplicity in types and direct error handling.

Maybe the Go engineers didn't think about nullables, but I think there is a good chance they simply decided against them for various reasons.

Yes it does. I just don’t understand why does everyone want every language to be the same language? If you want all the sugar then C#, Java, latest C++ all are perfectly mature and usable and fit that niche

Yes: https://github.com/golang/go/blob/27093581b2828a2752a6d2711d...

Secondary, go map iteration starts from a random position in the hashmap. The order on subsequent iterations is the same, but rotated as a result of the random start index

Go does seed hashes on a per-hashmap basis, as does rust. But that still gives you consistent iteration order for a given map: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Go also randomly offsets the start point of every map iteration: https://go.dev/play/p/SlfDjGKi77L

I never expected this post to get here in HN the way it was. It is definitely a work in progress, most some personal notes that I will probably add more when I use other parts in Go that bothers me.

If you use functional options, please don't implement them with closures. Closures aren't comparable, so there's essentially no way to build middleware that varies behavior based on those arguments.

Just make a `type thearg string` or whatever instead. Very similar amounts of code, similarly hidden implementation, but MUCH more usable.

Options pattern is an alternative, I use it frequently, but still miss named arguments and default arguments if I'm going back and forth with Python.

- The options pattern is much more verbose to implement.

- The defaults aren't as easily clear, they need to be documented and kept consistent.

- You can't, or it's not as easy to, make some arguments required.

- And, as a caller, if the API I'm using doesn't support them, I sometimes have to rely on comments to clarify what each arg is. For example, if a function takes a bools like `func MyFunc(dryrun, inverse bool, items ...string) error { ... }`

string.Replace(urlString, " ", "%20", -1)

is less readable than

string.Replace(urlString, replace: " ", with: "%20", maxReplacements: -1)

Of course it's not often necessary, especially when you have a named variable

string.Replace(urlString, charToReplace, escapedChar, REPLACE_ALL)

But it can also be awkward to have to declare a variable for every arg, which is probably why python allows you to call it both ways. Plus the variable names and positional arg could not match up, which can be a source of hard to find bugs

> The specific examples don’t ring true to me though.

And I don't think it should. To start, the list is small because it is a work in progress, I plan to write more once I have more to talk. I didn't expect this post to hit HN that soon, but thanks to whoever posted this here. Got some really interesting points of view. But also they are particular pet peeves of mine, and don't necessarily reflect other people's experiences.

The other half is hyrum’s law.

There’s a lot of situations in reasonable unordered map implementations where the elements, by chance, do happen to be ordered. Just due to arbitrary implementation decisions.

But the Go spec says that maps are unordered, and library writers want to reserve the right to change the implementation in the future.

So always ransoming the dict prevents code from accidentally depending on some specific map implementation detail.

> The old language specification did not define the order of iteration for maps, and in practice it differed across hardware platforms. This caused tests that iterated over maps to be fragile and non-portable, with the unpleasant property that a test might always pass on one machine but break on another.

> In Go 1, the order in which elements are visited when iterating over a map using a for range statement is defined to be unpredictable, even if the same loop is run multiple times with the same map. Code should not assume that the elements are visited in any particular order.

> This change means that code that depends on iteration order is very likely to break early and be fixed long before it becomes a problem. Just as important, it allows the map implementation to ensure better map balancing even when programs are using range loops to select an element from a mapl.

Code that results in a nil dereference should not be compilable, period. Any programming language that allows it is flawed.