I learned seven programming languages

Try crystal!

https://crystal-lang.org/

The author's experience is based on toy examples. Programming (and designing) in a professional setting is more than that, though. And the solutions are not the same for everyone: writing an Office plugin has different needs than writing a mobile game. For many of us, the availability of tooling and libraries is crucial. I'm not going to reinvent the web server by building on OS sockets or write a graphics rendering engine from scratch.

That said: Nim does look nice.

> most programmer convenience is sacrificed on the altar of "never crash". This makes it a good choice for sending a rocket to space

When it comes to safety- or mission-critical software, crashing due to a dangling pointer, a stack overflow or a failed allocation are equally catastrophic, and not crashing but producing a wrong answer due to an algorithmic error is also equally catastrophic. In fact, producing the correct answer late can also be just as catastrophic when the system is real-time -- we don't care if the operation takes 1ms or 99ms, but if the deadline for emitting a control command is at 100ms, emitting it 100.001ms late is just as catastrophic as a crash (while completing the calculation in 20ms or 95ms is equally good). Never crashing for any reason, never producing a wrong result, and never producing a correct result late are all equally critical.

How are such systems written? They normally require very simple code and very simple algorithms -- to make analysis by tools, and even more importantly, by humans as easy as possible. Any compiler magic or implicitness in the code may be problematic (possibly including reference-counting if a bound on deallocation time cannot be guaranteed). We don't want to make code as fast as possible, but as non-surprising and as predictable as possible.

The author tests the seven languages python, julia, rust, c#, swift, c and nim by programming a Yahtzee bot in each and comparing them. The "winner" is nim.

Unfortunately the author only provides the code for nim.

So it is subjective based on a simple practical project (1000 locs). Unfortunately it leaves out all the other "cool kids" like crystal, zig, v, dart, d and so forth...

Swift, I was once puzzled by the named function parameter,

but then notice later

func icon(forFile fullPath: String) -> NSImage

func icon(forFiles fullPaths: [String]) -> NSImage?

func icon(for contentType: UTType) -> NSImage

func with same name, can have different named parameter, and return type.

func iconForFile

func iconForFiles

func iconForContentType

Will be the alternative in every other language(paramtype overload is available in c*/java/kotlin to extent, but it is less explicit), Swift sounds neat isn't it?

You can see more examples, in particularly class overloads it looks cleaner and convenient to communicate, verbosity is not an issue, code is optimised for reading.

https://developer.apple.com/documentation/appkit/nsapplicati...

The actual issue with Swift, is tooling and there's SOOOOOO many hidden wanted/unwanted "feature"