Except for, you know, the majority of Rust projects which reach the HN front page and don't, like the stories on PopOS, Redox, and the Wild linker from the past day.
To be fair that video game was released (in early access) during Rust 0.8 - the language was already popular on HN I think, but not as a "you should use this in prod" type of thing.
In fairness, many language/framework communities often have project names that are related or tongue in cheek, and not just to advertise that its x language; Python comes to mind
This is cope. Functionally nobody remembers enough high school chemistry to remember what a redox reaction is, let alone associate that with Rust, and such a naming convention is hardly worthy of the petulant dismissal expressed by the original comment.
And while we're on the topic, more Rust projects on the HN front page that don't mention Rust in the past day were Typst and the Cloudflare thing. Turns out, there's just a ton of good Rust projects out there, to the surprise of clueless HN commenters.
> Wilson rejected the idea of mass joblessness due to AI as "a very silly fear because human desires and human wants are infinite, and therefore, we always find new things for people to do."
While I'm highly skeptical that the current iteration of LLM tech will lead to mass joblessness, the reasoning above is flawed. If it costs less to employ a bot than to employ a human, then the price of human labor will fall until it reaches equilibrium with the bot. And if that equilibrium price happens to be below what it takes to keep a human alive, then it doesn't matter if "human wants are infinite" because it would be cheaper to fulfill those wants without paying a human.
I'm more concerned that the above reasoning is flawed just because it's untrue.
I don't know any yacht owning people but the few people I know with boats are very happy with it's size. The people looking for a football field on water are _limited_. Human desires are limited and if that limit can be achieved without the collective efforts of all humans then under our capitalistic model somebody is going to starve.
While I agree that the replacement of humans with AI would lead to joblessness, I think you'll see far sooner mass joblessness as a human with better technology can replace 50+ other humans (like containership engineer vs sailship crew).
Yeah, we’ll see what happens, but one of the interesting things about the book sapiens, is it highlights that there are plenty of paradigm shifting events in human history that change our basic assumptions.
“Life is suffering” meant something very different when the Buddha first said it to now. The idea that “the only constant is change” is a relatively modern creation(or at least the significance of it), so this idea that economics is going to keep working the way it always has - at least feels like it’s going to change if we get more advanced AI.
The assertion that we are refuting is this: "human wants are infinite, and therefore, we always find new things for people to do". The context here is specifically about employment, human labor, and the spectre of joblessness. What you're describing is not a labor market, it's charity. And indeed, one peaceful, idyllic solution to mass unemployment that gets trotted out is something like UBI, where you pay people to simply keep them alive, without expecting anything in return. But that's not at all what's being discussed here; instead, what the OP is asserting is the usual yarn that technological advances will not decrease human employment, but at a certain point this simply stops being the case, and that point will be reached if or when the price of artificial labor falls below a critical level. In short: at the limit of technological advancement, you can either prioritize a market economy, or you can prioritize keeping people alive; you cannot have both.
> In C I wouldn't use such a fluffy high-level approach in the first place.
Sure, though that's because C has abstraction like Mars has a breathable atmosphere.
> This approach leads to straightforward, efficient architecture and bug-free code. It's also much better for concurrency/parallelism.
This claim is wild considering that Rust code is more bug-free than C code while being just as efficient, while keeping in mind that Rust makes parallelism so much easier than C that it's stops being funny and starts being tragic.
I'm not even sure what it means for a language to "have" abstractions. Abstractions are created by competent software engineers, according to the requirements. A language can have features that make creating certain kinds of abstractions easier -- for example type-abstractions. I've stopped thinking that type abstractions are all that important. Somehow creating those always leads to decision paralysis and scope creep, and using those always leads to layers of bloat and less than straightforward programs.
...Except that Rust is thread-safe, so expressing your algorithm in terms that the borrow checker accepts makes safe parallelism possible, as shown in the example using Rayon to trivially parallelize an operation. This is the whole point of Rust, and to say that C and C++ fail at thread-safety would be the understatement of the century.
If you're writing C code that shares memory between threads without some sort of synchronization primitive, then as your doctor I'm afraid I'm going to have to ask you to sit down, because I have some very bad news for you.
> At this point, we have to be actively be against free services.
Nah, GCC is free, Linux is free, Debian is free. What we need to be against is free stuff provided by for-profit entities, because the love of money is the root of all evil.
Linux is free as-in freedom. Linux is not zero-cost: it has taken tens of billions of dollars of investment from thousands of organisations over three decades - and countless volunteer hours - to make it what it is today; that the wider community gets Linux security patches and feature updates for free is a side-effect of the GPL license coupled with the low marginal cost of reproducing software once-written. I’m here to remind people that the bulk of Linux’ codebase was not written for free as an act of charity.
What I’m saying is that, hypothetically, if the entire business-world suddenly ditched Linux overnight and went back to IBM and Burrows like it’s the 1960s again again (and let’s pretend Android isn’t a thing either) then no-one would be funding significant Linux dev/eng work, and as much as we value the hacker-spirit of unpaid community/volunteer projects, I feel it isn’t enough to keep Linux viable and secure (especially in high-visibility, high-exposure scenarios like desktops and internet-facing services).
Eh, I heard lots of complaints from the Xen folks that the prevalence of RedHat in the kernel development community leads to double standards that makes their favourite product (KVM) get nicer and quicker reviews than the Xen related changes.
I played it on Steam Deck when it first came out (docked, standard HD display). It was perfectly acceptable, as long as you're fine with semi-stable 30 FPS and cranking down the graphics a tad. The only real problem that I encountered was that the game wouldn't recognize or remember my input settings, and would always default to controller-only, so I would have to attach a controller to navigate to the menu to switch it to keyboard; hopefully the Deck-native version fixes that.
One big upside of single player games is that they have an ending. After playing MUDs back in the day, this was a decision I've kept -- no games without an end.
To be fair, I've still spent a crazy amount of time with the Civilization games so let's say that was a partial success.
You can make it run much better by increasing the game's process priority with `renice`. I know that sounds like something that should not work, but it does.
> And the more nested the format becomes, with arrays of dicts, or dicts of arrays, the harder it is to follow.
While I have some minor annoyances with TOML, I counterintuitively consider it a strength of the format that nesting quickly becomes untenable, because it produces pressure on the designers of config file schemas to keep nesting to a minimum.
Maybe some projects have a legitimate need for something more complex, but IMO config files are at their best when they're just key-value pairs organized into sections.
As far as I can see, nobody originally constrained the problem to config files. So I guess the problem with TOML is that it's only good for config files, while JSON and TOML are general purpose.
Yes, I think that's a fair characterization. The priorities of config file formats are different than the priorities of human-readable arbitrary data serialization and transmission formats.
> Make no mistake, the Internet has never been free. There's always been a reward system that transferred value from consumers to creators and, in doing so, filled the Internet with content. Had the Internet not had that reward system it wouldn't be nearly as vibrant as it is today.
This is an attempt to rewrite history. Back in the day, we stood up servers at our own expense and filled them with content for free, for nothing other than the fun of it. In fact, the "vibrancy" of the internet appears to be inversely correlated to the number of people using it to generate a profit.
They're not saying what you think either, there's no reward system or transfer of value in free content, offered for free. It doesn't matter if it's hosted at someone's own expense if it's done for nothing other than the fun of it.
I never implied there was a reward system or value transfer (unless you count the feel-good reward of sharing knowledge with others and the value of doing so).
I said that putting things on the Internet is not, and has never been, "free".
And I think that's what Cloudflare is saying too.
You're free to interpret it differently (as was OP) but I think you're wrong. ;-)
CloudFlare is definitely implying there's always been a reward systems and value transfer at play, that's there in the quoted text and what the OP is complaining about
reply