←back to thread

348 points giuliomagnifico | 1 comments | | HN request time: 0.314s | source
Show context
epolanski ◴[] No.46243675[source]
If Rust helps with their pains and they like Rust this seems very sensible.

That's exactly why we have different languages and tools, because they adapt differently to different projects, teams and problems.

But as soon as you get into the silly "tool X is better period" arguments, then all the nuance of choosing the right tool for the job is lost.

replies(8): >>46243722 #>>46244465 #>>46244778 #>>46245023 #>>46245269 #>>46245325 #>>46246309 #>>46250138 #
concinds ◴[] No.46245325[source]
We could move past all the unproductive, polarized online arguments if everyone accepted that:

1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.

2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident.

That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".

replies(5): >>46245419 #>>46245504 #>>46247804 #>>46248619 #>>46252477 #
udhghhe ◴[] No.46245419[source]
Thing is, Rust is not a memory safe programming language. It's not even close to being one.

> Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels

https://materialize.com/blog/rust-concurrency-bug-unbounded-...

replies(1): >>46246743 #
1. ◴[] No.46246743[source]