The first example program that demonstrates arrays in The C Programming Language 2nd edition (page 22) uses signed integers for both the induction variable and the array length (the literal 10 becomes int).
43,683 karma · joined August 22, 2009
Making int 32-bit also results in not-insignificant memory savings.
To be clear, you're proposing putting a warning on "for (int i = 0; i < n; i++)"? The most common textbook way to write a loop in C?
> I'm also incredibly suspicious of the idea that FAANG in particular won't accept minor compiler slowdowns for useful safety.
I worked on compilers at FAANG for quite a while and know quite well how these teams justify their existence. Telling executives "we cost the company $1M a quarter, but good news, we made the semantics of the language easier for programming language nerds to understand" instead of "we saved the company $10M last quarter" is an excellent strategy for getting the team axed next time downsizing comes around.
As a summary: The most common way given in C textbooks to iterate over an array is "for (int i = 0; i < n; i++) { ... array[i] ... }". The problem comes from these three facts: (1) i is a signed integer; (2) i is 32-bit; (3) pointers nowadays are usually 64-bit. That means that a compiler that can't prove that the increment on "i" won't overflow (perhaps because "n" was passed in as a function parameter) has to do a sign extend on every loop iteration, which adds extra instructions in what could be a hot loop, especially since you can't fold a sign extending index into an addressing mode on x86. Since this pattern is so common, compiler developers are loath to change the semantics here--even a 0.1% fleet-wide slowdown has a cost to FAANG measured in the millions.
Note that the problem goes away if you use pointer-width indices for arrays, which many other languages do. It also goes away if you use C++ iterators. Sadly, the C-like pattern persists.
[1]: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...
[1]: https://en.wikipedia.org/wiki/Abolition_of_the_han_system
> The period saw a breakdown in the traditional master-servant relationship between a lord and his vassals, with many instances of vassals rebelling against their lords, internal dynastic conflict over lordships within noble families (in which vassals would take sides), and the installation of figurehead lords by cadet branches of noble families.[3] The period was also marked by the loosening of samurai culture, with people born into other social strata sometimes making a name for themselves as warriors and thus becoming samurai.
> [W]eariness of war, socioeconomic unrest and poor treatment by aristocrats provoked the wrath of the peasant class. Farmers, craftsmen, merchants and even villages would organize uprisings (known as "ikki") against the ruling class. An extraordinary example is the Kaga Rebellion, in which the local ikki had staged a large-scale revolt with the support of the True Pure Land sect (thereby establishing the term ikkō ikki) and assumed control of the entire province of Kaga.
Whatever post-Heian, pre-Meiji Japan was, it was not an orderly, harmonious society.
This actually gets the history backwards. Ancient Rust tried to do generics in a fully polymorphic way using intensional type analysis, like Swift does. We switched to monomorphization reluctantly because of the code bloat, complexity of implementation, and performance problems with intensional type analysis. "dyn Trait" was always intended to be an alternative that code could opt into for runtime polymorphism.
No, that's what bytemuck is for. If bytemuck didn't exist, sure, I'd be using a lot of unsafe.
I'm curious what makes this so different from my experience. I rarely ever have to write "unsafe", and I'm writing quite low-level engine code that certainly uses bit manipulation. In fact, crates like bitflags and fixedbitset make it so easy that I tend to get dinged in code reviews for using bit flags when structs of booleans would be simpler :)
It's the exact opposite for me: I use concurrent data structures more often in Rust than I do in C++ because I don't have to worry about dumb data race bugs. If one of my Bevy systems is slow, I slap par_iter() on the query and if it compiles it probably works, or at least fails for a not-stupid reason.
Regarding game engines, the empirical evidence shows that Bevy has been moving at least as fast as, if not faster than†, comparable C++ engines. I listed all the features I landed in the past year here: https://news.ycombinator.com/item?id=42945730
We love to argue on message boards about theoretical or anecdotal productivity of programming languages, but at the end of the day the only thing that matters is what people have actually been doing with the language, and for Rust the answer is "quite a lot, actually".
†In my view, Bevy has been moving significantly faster than comparable C++ engines, but I don't need to argue that to make my point.
This is false if "etc." includes Wikipedia, on which Musk has attempted to suppress speech critical of him [1].
[1]: https://theweek.com/media/elon-musk-wikipedia-controversy
I suspect there are plenty of undocumented immigrants in states that don't have the equivalent of AB 60 licenses who are perfectly safe drivers. Perhaps even safer than licensed drivers, since they have more to lose from moving violations.
There is such a document: RFC 4180. It may not be a good document, but it does exist.
[1]: https://en.wikipedia.org/wiki/Circular_buffer#Optimization
I agree it'd be nice if it weren't confined to our community, though.
I disagree. Minimalism in systems language design has been done over and over: see Go for the most recent example. Comptime is something that C++ was already doing in the form of constexpr since 2011 and a space that D had explored for over a decade before Zig came around in the form of "static if" and so forth (in addition to lots of academic work, of course). Stripping out template metaprogramming in favor of leaning heavily on compile-time function evaluation isn't novel either. I think you find the set of features that Zig has to be personally appealing, which is fine. But the argument that it's anything novel is weak, except in the trivial sense that every language is novel because it includes some features and leaves others out (but if every language is novel, then the word "novel" has no meaning).
From my vantage point, Zig is essentially a skin on a subset of C++, one that is in practice less safe than C++ because of the relative immaturity of tooling.