crystal VS go

I really enjoyed using Crystal last year. It is a very ergonomic language with a featureful standard library. I was tempted to use it again this year, but I figured I should use this opportunity to try something new. After considering several languages including Go, F#, Nim, and Raku, I decided to go with Gleam.

Temp file issue is debunked here: https://news.ycombinator.com/item?id=41684848

Dir module works fine, though maybe the docs could be improved. https://crystal-lang.org/api/1.13.3/Dir.html . The stdlib code is also highly readable: https://github.com/crystal-lang/crystal/blob/d14d04562/src/d... shows that #each_child just calls #read and yields it to the block, so I don't think this is really a wart :)

27. Crystal - $77,104

I like the first code example on https://crystal-lang.org

    # A very basic HTTP server

// handle unexported go stdlib error, XXX fix after https://github.com/golang/go/issues/35234

Go without concurrency is fully memory safe. However, once you start using goroutines there can be memory corruption and segfaults: https://github.com/golang/go/issues/37484. Note that these are not recoverable panics (such as "writing to a close channel"), but causes completely arbitrary behavior:

    runtime: pointer 0xc00379ac60 to unused region of span span.base()=0xc001794000 span.limit=0xc001795e00 span.state=1

As for first entry, this has been discussed many times without ever reaching any consensus, see - https://github.com/golang/go/issues/19412

To be fair to those projects, the type was introduced only three years ago:

https://github.com/golang/go/pull/49359/files

Before that, doing a string compare was basically the only way to detect that specific error. That was definitely an omission on the part of the original authors of the stdlib code; I don't it should be classified as "Hyrum's Law".

git clone https://github.com/golang/go OR git clone https://go.googlesource.com/go

I install go.

The difference between types.Implements and types.Satisfies is mainly a history reason, a tradeoff between keeping backward compatibility and theory perfection.

It is pity that Go didn't support the "comparable" interface from the beginning. If it has been supported since Go 1.0, then this tradeoff can be avoided.

There are more limitations in current Go custom generics, much of them could be removed when this proposal (https://github.com/golang/go/issues/70128) is done.

I recommend people to read Go Generics 101 (https://go101.org/generics/101.html, author here) for a thoroughly understanding the status quo of Go custom generics.