BatmanAoD
It is indeed clear that you’re kidding, but it’s not clear that you understand what a certified compiler is for. It’s not like RHEL, and it has nothing to do with licensing or even packaging/distribution. It’s also not something that Ferrocene needs to “sell” in the sense of convincing users to migrate to it from rustc: either you need a certified compiler and you therefore can’t use Rust at all until one exists, or you don’t need one and there’s no reason to wait for one to exist.
You’re correct that bureaucracy is effectively the reason why the concept of compiler certification exists, but it seems like you’re ignoring the fact that the devs burdened by this bureaucracy generally don’t have a choice in the matter.
“I don’t care too much because creating your own terminal is like 20 lines of code these days. People who really care can just create one as easy as configuring an existing one.”
wat
It’s pretty nice. I’ve been following its progress essentially since the beginning and would like to adopt it as my primary shell eventually, but it’s had some blockers that prevent me from switching completely, most of which have been resolved by now. The one I’m currently waiting for is the ability to suspend and resume processes: https://github.com/nushell/nushell/issues/247
The post has been edited; it looks like someone on reddit made essentially the same point. You’re right of course that void
isn’t a true type in Java, but the post now also discusses Void, which I suppose just shows how void infects the type system despite not being a type.
It’s not possible to instantiate or assign, which is more like a never type than a unit; and it is not possible to define new types with the same properties, which is also more like bottom than unit. But you’re right that it’s not actually a true never type since it can’t represent function divergence.
I think the truth is just that Java’s type system isn’t very mathematically disciplined.
I think TypeScript has a pretty good type system, and it’s not too hard to learn. Adding sum types (i.e. enums or tagged unions) to Go would be a huge improvement without making it much harder to learn. I also think that requiring nullability to be annotated (like for primitives in C#, but for everything) would be a good feature for a simple type system. (Of course that idea isn’t compatible with Go for various reasons.)
I also think that even before “proper” generics were added, Go should have provided the ability to represent and interact with “a slice (or map) of some type” in some way other than just interface{}
. This would have needed dedicated syntax, but since slice and map are the only container types and already have special syntax, I don’t think it would have been that bad.
The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that’s nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.