I am so glad someone said this. This also shows nicely how async is wrong, not just that it's viral, but it's bad design because it forces code duplication.
Middleware/library writers that touch on anything that could be async (db, SPI, network etc.) will now have to write two versions of their API and duplicate most code.
I wanted to avoid people just taking this out of the javascript source so it's using some hash tricks to prevent that. Maybe I over engineered that a bit though.
This is not correct. The api that was disabled was deprecated for over a decade when disabled. It was an api that wasn't meant to be used. Zol folks kept using it out of tree and when Linus finally removed/hidden them people went apeshit thinking it was some sort of attack. It wasnt, it was 12 years late...
> We didn't go out of our way to deliberately break anything.
> But we do occasionally turn symbols that aren't meant to be used outside the kernel into GPL-only, because they have some internal implementation issues.
An api may not be meant to be used but what makes it important to hide it? They could just let it be until there is a real need to delete it. Just going out of your way to hide something is a bit hard to understand.
There are very good reasons to delete unmaintained or hard-to-maintain code that nothing important depends on, or should depend on. But just deleting it creates hardships, so things happen in stages.
Really cool. For some reason when I opened the webpage I was like "this seems like it's written in Rust" and it is! I'm using Rust as my main language for the past 6 months now so it makes me happy :D
This happens regularly, the bee cluster doesn't wait for late comers. There are some scouts that keep going there and back but there are also scouts that do that with the "Correct" destination, so they "lead" the stray ones to their new home eventually. In the end most bees end up where they're supposed to.
It's much worse when a beekeeper takes the swarm tho. Speaking from experience, you can see "lost" scouts going to and from the temporary cluster from their destinations for days after you moved the cluster into a new hive. The reason is because there's noone going from cluster to new hive since no scout found that destination. It's a bit heartbreaking.
I collected the "leftover" mini-clusters 4 times in a row coz I felt responsible...
Rust will outperform C consistently soon. It already does in some cases. It will also do so with safe idiomatic code in most cases. The reason behind my statement is simply more opportunity for the optimizer. Rusts rules allow for a more aggressive optimization. The reasons why it's not outperforming C yet are LLVM bugs and some missing Rust language features and fixes. LLVM in particular is driven by C needs so they rarely fix bugs present only Rustc generated IR.
This is grey, but shouldn’t be. I assume people are downing it because it doesn’t give examples of the optimization opportunities it claims. So here are two that I think are likely most significant.
1. Rust’s aliasing semantics are more powerful than C’s unless you use the ‘restrict’ keyword everywhere, which most people don’t. It’s well recognized that FORTRAN continues to generally outperform C in many numeric applications because FORTRAN compilers are free to perform optimizations that C compilers cannot or don’t, due to the fact that multi-aliasing memory is undefined behavior in FORTRAN. The rust compiler currently doesn’t pass the relevant hints to the generated LLVM IR due to a long history of LLVM having bugs in ‘noalias’ handling, in large part due to the fact that those code paths are so rarely executed while compiling C code, itself due to the relatively low usage of the ‘restrict’ keyword.
2. Implicit arena allocations. The Rust compiler has access to information about possible aliasing and overlapping lifetimes that it can use to replace multiple allocations with similar lifetimes with offsets into a single allocation that is then all freed together. This is a complicated topic, but work is ongoing to make this a reality.
2 might sound overly optimistic like "Rust will eventually beat C" but V8 already has an allocation folding optimization which combines multiple objects into a single site. There's also run time profiling to try and figure out the allocation lifetime.
I'm not disputing that. In theory Rust should outperform even today but of course reality is a different beast and implementation details are important.
Then you also get into architecture specifics etc.
dodobirdlord described the two major advantages Rust has on the language level very well so I won't repeat them, but the gist I'm making is that Rust simply allows more optimizations purely on the language level. Specifics of backend implementations are of course another topic completely (and is one of the reasons why I'm excited for the possibility of a GNU Rustc)
Middleware/library writers that touch on anything that could be async (db, SPI, network etc.) will now have to write two versions of their API and duplicate most code.