If you actually read his message you can see he is interested in hosting projects that aren't open source.
I think mmap is unlikely to be the best option seeing as you'd be doing large sequential reads.
Yeah it's clearly more than just experience. It's at least experience + actually learning + actually caring. I wouldn't rule out natural talent either, though I have seen plenty of smart people with poor programming taste.
For example I worked on a C++ SDK where the guy that wrote it was clearly very smart... But he had also written an enormous god object using CRTP to inherit about 20 classes. The aim was to make it somehow modular, but it absolutely wasn't. Clearly poor taste.
Maybe it's like religion. There are plenty of very smart people that believe in an imaginary friend. It's almost orthogonal to "smartness". Maybe taste is the same.
I mean, sure... But for most users of GitHub actions "it's easy and free" is a huge benefit, easily outweighing any technical advantages Buildkite might have.
He's right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.
This is the kind of silly stuff that just makes RISC-V look bad.
Couldn't agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don't forget that instruction fetch ignores this and is always little endian.
Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:
We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and certain legacy code bases have been built assuming big-endian processors, so we have defined big-endian and bi-endian variants of RISC-V.
This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven't). It's extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.
Linux should absolutely not implement this.
Phoronix has notoriously dumb commenters. I don't know why exactly but it's really notable.
Hackaday too. Again, not sure why. They're both significantly worse than Reddit, HN, Ars or here. Maybe even worse than YouTube comments...
His point could be valid, if C was working fine and Rust didn't fix it. But C isn't working fine and Rust is the first actual solution we've ever had.
He's just an old man saying we can't have cars on the road because they'll scare the horses.
Ok after reading the article this is bullshit. It's only because they are counting JavaScript and Typescript separately.
Great accomplishment. I think we all knew it must happen like this but it's great to see real world results.
I think this is probably actually the most useful part of the post:
Increasing productivity: Safe Coding improves code correctness and developer productivity by shifting bug finding further left, before the code is even checked in. We see this shift showing up in important metrics such as rollback rates (emergency code revert due to an unanticipated bug). The Android team has observed that the rollback rate of Rust changes is less than half that of C++.
I think anyone writing Rust knows this but it's quite hard to convince non-Rust developers that you will write fewer bugs in general (not just memory safety bugs) with Rust than with C++. It's great to have a solid number to point to.
Maybe all of the stars, forks, and discussions on the GitHub page are from fake accounts
All 9k stars, 10k PRs, 400 forks & professional web site are fake? Come on this is about the most obviously not fake project I've seen!
How do you know when a product like this can be trusted?
The same way you tell if anything can be trusted - you look at the signals and see if they are suss. In this case:
The amount of effort it would take to fake this for very little benefit is enormous.
Maybe I’m just being paranoid.
Yeah just a little!
Seems a bit clickbaity to me. It's a flaw in Windows/cmd.exe, not Rust. Rust is just called out because it tries to emulated proper argument passing on Windows (and didn't get it perfectly right). All languages are affected by this but most of them just throw their hands in the air and say "you're on your own":
It's also extremely unlikely that you'd be running a bat script with untrusted arguments on Windows.
With caveats.