Safety only has a cost in this case because the switch is fundamentally just operating on an integer. With an actual enumerated type (rather than C's primitive "enums as numeric aliases"), which even a basic type system could trivially enforce, there would be no need for this check, because the domain of the value would be guaranteed at compile-time.

Comments URL: https://news.ycombinator.com/item?id=48578029

Points: 2

# Comments: 0

This is inherent to the domain of systems programming. One-size-fits-all solutions only suffice until you need extreme performance. So, for example, Rust provides a basic hashmap in the stdlib, and as a generalist hashmap it's quite close to state-of-the-art. But as a generalist hashmap it's also beaten in specific applications by specialist datastructures, and Rust needs to provide support for building those specialist datastructures in a way that makes them feel just as first-class as what the stdlib provides.

Go gets away with what it does because it's for domains where it's acceptable to trade uniformity for performance. This is not a bad thing! Go is quite performant. But Rust ultimately isn't competing with Go, it's competing with C.

And note that I say all this as someone who is, in fact, a stdlib maximalist. But I also say all this as someone who is conscientious and informed of the realities of what it takes to design and maintain a secure, high-performance stdlib.

It depends on perspective. Go is tailored for writing backends, so it's great that it provides things like net/http (we could also interpret cause and effect inversely here; Go provides net/http so it gets used for writing backends). Rust's standard library is actually pretty damn huge, but it doesn't index heavily into specific applications, and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it. Rust's stdlib is "small" if all you want to do is build a webserver and don't want to go shopping around for libraries, but anyone who's intimately familiar with Rust's stdlib can tell you for a fact that it's absolutely not small in absolute terms. Rust literally stabilizes hundreds of new stdlib functions per year.

One of the main reasons that art is valuable is in its ability to communicate emotions. Good art has the ability to serialize emotions within the artist and deserialize them within the mind of the viewer. It's not just "wow, this is a pretty picture", it's "wow, this is how another person sees the world, and now that I understand that, I feel an intimate connection with them".

Lots of urban areas in the US have been resisting, tearing down, and/or relocating major roads since the freeway revolts of the 1970s:

https://en.wikipedia.org/wiki/Highway_revolts_in_the_United_...

https://en.wikipedia.org/wiki/Freeway_removal

As usual for Gruber, this is fanboy cope. Dye may be a convenient scapegoat, but he was not a lone wolf, he was operating with the full assent of executive leadership, which is to say, the same leadership that appointed his successor.

Sadly I have yet to see evidence that something can be smart without being evil.

Indeed, there are plenty of valid reasons to be wary of operator overloading, such as the risk that someone might insert a network call into your vector addition. There's some precedence from C++ in calling an operator invocation "trivial" when it hasn't been user-defined, in general I might go further and say that a good overloaded operator is "well-behaved" when it not only has a non-surprising implementation (e.g. no side-effects) but also its function is congruent with the specific chosen operator (so no overloading bitshift for iostreams).