> with rust you have 2x more ways to shoot yourself in the foot.
The checking isn't how you shoot yourself in the foot, it's the absence of checking. Rust doesn't allow you to forget to check. This entire class of problems just disappears in Rust.
In this if the code needs a non-null redis client to work you take `RedisClient` not `Option<RedisClient>`.
You sound like people who claim AI is freeing because it has removed the gatekeeping of programming when programming was never gatekept, all you needed to do was dedicate time to learn.
Your premise doesn't even make that much sense given that Knockin' on Heaven's Door uses only the three chords(G, C, Am) and they are some of the most common chords in music.
That makes sense, but I would love to see the data on it. I don't doubt at all that capitalism in isolation is viewed more favourably in the US, but that doesn't preclude the intersection of AI and capitalism being viewed less favourably.
I suppose my comment should've said "views on AI aren't solely views on AI, they are views on AI as it intersects with capitalism"
I don't doubt that's true for everyone who reads HN, but having seen the other side there are loads of people who don't make the effort and could've found their own answer in the knowledge base.
I find LLM customer service to be better than the historic dumber stuff. In those you can usually say "I want to talk to a human" and it will escalate. The customer service bots of yore were far dumber and made it harder to escalate.
Agree. I actually think we'll see a resurgence in art and graphic design as a consequence. At least for now people can spot AI generated artifacts and many immediately have a negative reaction to it. I don't read blog posts that feature AI generated images, even though they are only slightly worse than stuff cribbed form Unsplash.
I don't like AI customer service either, but having seen the other side it cuts down huge amounts of inbound queries (where the answer can usually be found in knowledge bases) and provides an answer faster than a human would. As long as the escalation path to talk to a human isn't too arduous it's not too bad.
I think views on AI are not really views on AI, they are views on capitalism. People don't feel optimistic that AI's impact will benefit ordinary people because, even if works out, the benefit will accrue only to capital owners. This view feels pretty understandable to me, but is ultimately orthogonal to whether AI is useful and effective for the kind of tasks we want to leverage it for.
Unironically parroting uniparty lines is moronic. Sure there are problems with the Democrats, but both-sideism is at this point being wilfully blind.
As an external observer to US politics it would be great for the country to move past the two-party system, but to say they are the same is ridiculous.
The title is a little weird. The problems outlined are mostly about the community and governance, not the language.
To address at least one part of this: rewriting things in Rust. I think this is less about security and more about people wanting to scratch their own itch. Instead of improving existing tools, which is not seen as appealing, programmers write alternatives in Rust. You can flip this on its head and say that existing tools are not welcoming to new contributors and are failing to attract them.
I'm also curious about that. One thing to keep in mind: the invariants you have to uphold in unsafe blocks are quite stringent. I expect that in some instances the Rust code has new UB due to this.
Sure, but that's kind of orthogonal. Imagine doing this by hand I still think going like-for-like with the Zig, even if that means a lot of unsafe, is a good approach.
But I suppose if you are already using LLMs it's more reasonable to try and go from Zig straight to Rust with no/minimal unsafe.
It's not that weird to end up with this when translating C/Zig/C++ to Rust. A first pass can use unsafe and then when the code is in Rust you can work on reducing the unsafe.
Trying to eliminate all unsafe as part of the rewrite, whether done by human or LLM, would be making too big of a change in the process of rewriting.
It's not that strange. TURN has two main use cases: peer-to-peer when no viable direct path can be found and working around very strict firewalls. Based on the author's experience the first isn't relevant and the second isn't much of a concern for Twitch and Discord. For the latter case HTTP/3 is helping make TURN unnecessary because you can, as the author observes, run UDP over port 443.
This is a great question and there isn't a definitive answer provided in the sources I linked.
Broadly I think there are three approaches:
1. For frequent and small CPU heavy tasks, just run them on the IO threads. As long as you don't leave too long between `.await` points (~10ms) it seems to work okay.
2. Run your sans-io code on a dedicated CPU thread and do IO from an async runtime. This introduces overhead that needs to be weighed against the amount of CPU work.
3. Have the sans-io code output something like `Output::DoHeavyCompute { .. }` and later feed the result back as `Input::HeavyComputeResult { .. }`, in the middle run the work on a thread pool.
I think you are correct, in so far that often N:M threading is overkill for the problem at hand. However, some IO bound problems truly do require it. I haven't kept up with the details, but AFAIK the fallout from Spectre and Meltdown also means context switches are more expensive than they were historically, which is another downside with regular threads.
I also want to address something that I've seen in several sub-threads here: Rust's specific async implementation. The key limitation, compared to the likes of Go and JS, is that Rust attempts to implement async as a zero-cost abstraction, which is a much harder problem than what Go and JS does. Saying some variant of "Rust should just do the same thing as Go", is missing the point.
There is work happening on keyword generics[0], which would let a function be generic over keywords like `async` and `const`.
For now the best option to write code that wants to live in both worlds is sans-io. Thomas Eizinger at Fireguard has written a good article about this[1] pattern. Not only does it nicely solve the sync/async issue, but it also makes testing easier and opens the door to techniques like DST[2]
I have my own writing on the topic[3], which highlights that the problem is wider than just async vs sync due to different executors.
The checking isn't how you shoot yourself in the foot, it's the absence of checking. Rust doesn't allow you to forget to check. This entire class of problems just disappears in Rust.
In this if the code needs a non-null redis client to work you take `RedisClient` not `Option<RedisClient>`.