3 ms·

> What I don't like is the implied "only people doing stuff that I think is hard are real programmers. That's not exactly my what I want to say. My point is mo

by fiedzia 10y ago

> What I don't like is the implied "only people doing stuff that I think is hard are real programmers. That's not exactly my what I want to say. My point is more like "You may not see a point in becoming a soldier and its not a career for you, but be glad that those who defend you have big guns, so stop complaining that they are heavy". > I'm also not sure how relying on the language to guarantee safety is much different from relying on a complex beastie like a c++ compiler to be correct. Compiler are way more likely to be correct then people who use them. Problem with C++ (that Rust is trying to solve) is that the correctness of the compiler does not translate to correctness of compiled code, just as correctness of your text editor does not guarantee that you won't make typos, if it doesn't provide spellchecker. (I really like this analogy)

skybrian 10y ago
> You may not see a point in becoming a soldier You might want to try saying that a different way; this metaphor is a problem. It comes across as a slightly more colorful way of putting down people who use other languages as not "real" programmers - you're saying they should find another career. Or at best, maybe they are real programmers but they should be using harder languages? In practice, most of the important code that everyone relies on to defend us (assuming here you mean security-critical or safety-critical code) is not written in Rust. So who are the real "soldiers"? There's certainly a case to be made for using safer languages for critical code. On the other hand, using stricter static analysis for existing languages (and other kinds of testing like fuzz testing) will find bugs quicker and avoids boiling a few oceans.
- fiedzia 10y ago
  > It comes across as a slightly more colorful way of putting down people who use other languages as not "real" programmers This is not my intention. > In practice, most of the important code that everyone relies on to defend us (assuming here you mean security-critical or safety-critical code) is not written in Rust. So who are the real "soldiers"? Rust is relatively new. The real soldiers who use C bravely fight with of-by-one errors and buffer overruns and I really don't want them to do that. > There's certainly a case to be made for using safer languages for critical code. We can afford using safer languages for a lot of code. > On the other hand, using stricter static analysis for existing languages (and other kinds of testing like fuzz testing) will find bugs quicker and avoids boiling a few oceans. No, it will not. It may find few bugs here and there, but will leave whole classes of problems untouched. You can't bolt security onto a language. And we do not want to find few bugs, we want to be sure they are not there.
gh02t 10y ago
What are your thoughts on languages like Haskell? It certainly isn't simple or easy by any means, but it also isn't anything like nuts-and-bolts systems languages like C or C++. It gives you a lot of strong guarantees of correctness, but it's also pretty far removed from the mechanics of the machine. Lisp is another possible example, though in a different way. Though, I agree with the sentiment that we need languages like C or Rust etc. People who are dismissive of the value of systems languages are as silly as people who dismiss "easy" languages. I will say, which I bet you'll agree with, that I think dismissing the value of languages like C is the worse of the two mistakes to make.
- fiedzia 10y ago
  > What are your thoughts on languages like Haskell? I'm planning learn some functional language this year. There is a lot of Haskell developers in Rust community who came for performance and some ties to functional programming. I've just seen presentation about patterns in functional languages (https://www.youtube.com/watch?v=E8I19uA-wGY https://www.youtube.com/watch?v=E8I19uA-wGY - strongly recommended) and I like it so far. Getting hardware mechanics out of your way is amazing boost for productivity (I know that from using python). > dismissing the value of languages like C is the worse of the two mistakes to make I have Rust now for things that must be fast and low-level, so I do not need C anymore. It served us well, but a lot has changed since it was invented.
kelnos 10y ago
> Compiler are way more likely to be correct then people who use them. Yes! This is why I prefer languages with stronger type systems. The more classes of errors a compiler can pick up, the fewer tests I have to spend time writing & maintaining, and I feel so much more confident about running that code in production.

by fiedzia 10y ago

skybrian 10y ago

> You may not see a point in becoming a soldier You might want to try saying that a different way; this metaphor is a problem. It comes across as a slightly more colorful way of putting down people who use other languages as not "real" programmers - you're saying they should find another career. Or at best, maybe they are real programmers but they should be using harder languages? In practice, most of the important code that everyone relies on to defend us (assuming here you mean security-critical or safety-critical code) is not written in Rust. So who are the real "soldiers"? There's certainly a case to be made for using safer languages for critical code. On the other hand, using stricter static analysis for existing languages (and other kinds of testing like fuzz testing) will find bugs quicker and avoids boiling a few oceans.

fiedzia 10y ago
> It comes across as a slightly more colorful way of putting down people who use other languages as not "real" programmers This is not my intention. > In practice, most of the important code that everyone relies on to defend us (assuming here you mean security-critical or safety-critical code) is not written in Rust. So who are the real "soldiers"? Rust is relatively new. The real soldiers who use C bravely fight with of-by-one errors and buffer overruns and I really don't want them to do that. > There's certainly a case to be made for using safer languages for critical code. We can afford using safer languages for a lot of code. > On the other hand, using stricter static analysis for existing languages (and other kinds of testing like fuzz testing) will find bugs quicker and avoids boiling a few oceans. No, it will not. It may find few bugs here and there, but will leave whole classes of problems untouched. You can't bolt security onto a language. And we do not want to find few bugs, we want to be sure they are not there.

gh02t 10y ago

What are your thoughts on languages like Haskell? It certainly isn't simple or easy by any means, but it also isn't anything like nuts-and-bolts systems languages like C or C++. It gives you a lot of strong guarantees of correctness, but it's also pretty far removed from the mechanics of the machine. Lisp is another possible example, though in a different way. Though, I agree with the sentiment that we need languages like C or Rust etc. People who are dismissive of the value of systems languages are as silly as people who dismiss "easy" languages. I will say, which I bet you'll agree with, that I think dismissing the value of languages like C is the worse of the two mistakes to make.

fiedzia 10y ago
> What are your thoughts on languages like Haskell? I'm planning learn some functional language this year. There is a lot of Haskell developers in Rust community who came for performance and some ties to functional programming. I've just seen presentation about patterns in functional languages (https://www.youtube.com/watch?v=E8I19uA-wGY https://www.youtube.com/watch?v=E8I19uA-wGY - strongly recommended) and I like it so far. Getting hardware mechanics out of your way is amazing boost for productivity (I know that from using python). > dismissing the value of languages like C is the worse of the two mistakes to make I have Rust now for things that must be fast and low-level, so I do not need C anymore. It served us well, but a lot has changed since it was invented.

kelnos 10y ago

> Compiler are way more likely to be correct then people who use them. Yes! This is why I prefer languages with stronger type systems. The more classes of errors a compiler can pick up, the fewer tests I have to spend time writing & maintaining, and I feel so much more confident about running that code in production.