I think you’re hitting some good points, but the thing we need to teach these boys is that they shouldn’t be looking towards society for rewards. Society’s rewards have become a gamified rat race, so the way out is men to look inward. Not gonna lie though, that’s easier said than done…
I recently wrote a post too that touches on this topic: https://philosophyofbalance.com/blog/the-emancipation-of-men/
Don’t tell that to the kids in Finland 😉
https://santaclausvillage.info/activities/santa-claus-main-post-office/
Good news: if you’re writing #Rust and only using basic features of the language, you’re doing it right.
People who use the advanced stuff either have unique, interesting challenges, or they’re over-engineering. Since the former are overrepresented in the blogosphere, you’re probably comparing yourself to them. But just because their problems are interesting doesn’t mean yours are not! Nor does it mean you have to use the same solutions.
If you can solve interesting problems (it sounds like you can!) and keep the code simple, more power to you!
Try browsing the list of somewhat recent #CVE rated critical, as I just did to verify. A majority of them is not related to any memory errors. Will you tell all them “just use a different programming language”?
I'm sorry, but this has been repeatedly refuted:
And yes, they are telling their engineers to use a different programming language. In fact, even the NSA is saying exactly that: https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/
It doesn’t come out today, it’s been there for a long time, and it’s standardized, proven and stable.
This seems like an extremely short-sighted red herring. C has so many gaps in its specification, because it has no problem defining things as "undefined behavior" or "implementation defined", that the standard is essentially useless for kernel-level programming. The Linux kernel is written in C and used to only build with GCC. Now it builds with GCC and LLVM, and it relies on many non-standard compiler extensions for each. The effort to add support for LLVM took them 10 years. That's 10 years for a migration from C to C. Ask yourself: how is that possible if the language is so well standardized?
I find Linear to be reasonably pleasant.
Hehe, yeah, I actually agree in principle, although in the context of web tooling I think it’s at least understandable. For many years, web tooling was almost exclusively written in JavaScript itself, which was hailed as a feature, since it allowed JS developers to easily jump in and help improve their own tooling. And it made the stack relatively simple: All you needed was Node.js and you were good to go.
Something like the Google Closure Compiler, written in Java, was for many years better than comparable tooling written in JS, but remained in obscurity, partially because it was cumbersome to setup and people didn’t want to deal with Java.
Then the JS ecosystem ran into a wall. JS projects were becoming bigger and bigger, and the performance overhead of their homegrown tooling started frustrating more and more. That just happened to be the time that Rust came around, and it happened to tick all the boxes:
I think these things combined helped the language to quickly win the hearts and minds of many in the web community. So now we’re in a position where just name dropping “Rust” can be a way to quickly resonate with those developers, because they associate it with fast and reliable and portable. In principle you’re right, it should just be an implementation detail. But through circumstance it seems to have also become an expression of mindshare – ie. a marketing tool.
Finding a Webpack replacement that doesn’t use NPM at all is going to be hard, but there are certainly alternatives that don’t require the 1000+ NPM dependencies required to use Webpack.
Some alternatives you can consider are Rsbuild and Farm. Part of the reason they use so much fewer NPM dependencies is because they’re written in Rust, so they’ll have Cargo dependencies instead, but you shouldn’t notice anything of that. Of course if you want to audit everything it’s not that much easier, but at least the Cargo ecosystem seems to have avoided quite some of the mistakes that NPM made. But yes, in the end it still comes down to the extent that you trust your dependencies.
Thanks! This mirrors quite some experiences I’ve had over the years indeed. And for what it’s worth, I think the way you’re handling that is not bad at all.
As someone else mentioned in the comments on Mastodon, one of the hardest things about mentoring is articulating the lessons you may not even realize you’ve learned. I don’t think anyone can be blamed for failing to teach or convince someone else, since people are simply too different to be able to teach and convince them all. As you say, you have to pick your battles, and as long as you let your teammates do their work respectfully in their own way, that alone is a great achievement!
Yeah, sorting is definitely a common use case, but note it also didn’t improve every sorting use case. Anyway, even if I’m a bit skeptical I trust the Rust team that they don’t take these decisions lightly.
But the thing that lead to my original question was: if the compiler itself uses the std sorting internally, there’s also additional reason to hope that it might have transitive performance benefits. So even if compiling the Rust compiler with this PR was actually slower, compiling again with the resulting compiler could be faster since the resulting compiler benefits from faster sorting. So yeah, fingers crossed 🤞
The post mentioned that the introduction of these new algorithms brings compile-time improvements too, so how should I see this? I assumed it meant that compiling applications that use sorting would speed up, but that seems like a meaningless improvement if overall compilation times have regressed. Or do you mean compiling the compiler has become slower?
Yeah, it has its nice moments, but I also see it make mistakes and a lot of uselessly verbose text. It’s sometimes useful, sometimes funny, but mostly just noisy. Could be genuinely useful if it keeps improving though.
Ah yes, because we should condemn people over a statistic, even when the things they do may actually warrant some praise.