No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).
Because it is also possible to write tests that don't adequately capture real-life requirements.
It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.
I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.
I made the same comment last week upon learning of a redis clone entirely vibe coded in IIRC ~70k lines of Rust. Why Rust? Why does a computer need a memory safe language?
Wouldn't the instance state here be "was constructed"? That is: you should always be able to call `Read` because the constructor opened the file, and you shouldn't have to call `Close` anyway because the destructor did.
> What do you think, is there a potential niche for like NeoEmacs, a test editor written in a modern Lisp / Scheme
I think that's a non-starter because you instantly lose the entire ecosystem of elisp packages out there and nobody's config would work anymore. The latter is especially important when for some people that's a decades-developed init.el file in a repo that's migrated from CVS to subversion then git.
I've git bisected (mercurial at the time, but whatever) my .emacs repo to figure out what I did to break my Python config, so there's that.
If the array fits in the cache, deleting from the middle of an array and copying all the subsequent elements one to the left is actually faster than a linked list.
1. That's a rare use case
2. There are ways of measuring that without hampering readability. I mean, are programmers supposed to add all the variables' sizes up in their head??
Yes, I do.