Comment by vlovich123 | Hacker News Reader

Comment by vlovich123 | Hacker News Reader

Parent Full thread

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web browser in Go, but you would (& Mozilla is) in Rust.

In terms of correctness, I've never heard claims about improving security issues, except in so far as those caused by memory/concurrency - think of it as necessary but not sufficient for security. This "limited" class of bugs is responsible for quite a large number of runtime issues & they can be frustratingly difficult to find/fix (+ be confident that you did actually fix it). It's hard to say how much better things will play out in real-world software development as at some fundamental point there are always unsafe calls which weakens the guarantees Rust can make (but does put an explicit boundary on where you should go looking for bugs).

As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that. What Rust does do extremely well is that the errors are very clearly explained in the terminal (with an error code that has pretty good online documentation), but also gives you hints on simple ways to potentially alter the code to fix it. As a beginner, I've found it way quicker to fix those bugs (even within macros) than the compiler issues I encountered learning C++ - granted back then compilers were a lot worse on that front, but even these days with C++ I've struggled fighting the compiler/preprocessor.

Also, the Rust compiler appears pretty vibrant with lots of improvements being made to help with user friendliness, so it's possible that further improvements in inference might reduce the problem spots (it's already pretty magic to me).

I've started learning Rust a few weeks ago & those are my impressions so far.

>You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web browser in Go, but you would (& Mozilla is) in Rust.

I'm only comparing Rust and Go where they overlap. For example, Rust webservers versus Go webservers. There are other languages that may overlap different parts of Rust, such as in fact, Ruby and Python.

Go and Rust are both more general than the languages people compare them to. Both have C interop of various levels. Both allow unsafe code that touches memory directly. Both are high performance, relatively low level, and both provide some level of memory safety (though, Go provides much less.) I think they overlap a whole lot more than people think.

>In terms of correctness, I've never heard claims about improving security issues, except in so far as those caused by memory/concurrency - think of it as necessary but not sufficient for security. This "limited" class of bugs is responsible for quite a large number of runtime issues & they can be frustratingly difficult to find/fix (+ be confident that you did actually fix it). It's hard to say how much better things will play out in real-world software development as at some fundamental point there are always unsafe calls which weakens the guarantees Rust can make (but does put an explicit boundary on where you should go looking for bugs).

Well, I personally would claim it helps a lot of security and crash issues. Buffer overflows, use-after-frees, race conditions, and more. Also, most people do not overstate the safety of Rust, but beginners frequently misunderstand it. This is because people often list the benefits without listing the caveats.

> As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that.

Not very mainstream, but take a loot at elm's compiler errors [1]. They worked hard in this direction, and the result is both helpful and beautiful.

You can try loading up any of the examples in the online editor [2] and introducing a random bug, just to see how the compiler <del>barks</del> tries to gently teach you.

[1] http://elm-lang.org/blog/compiler-errors-for-humans

[2] http://elm-lang.org/examples

The error message catalogue [1] mentioned at the end of that first blog is interesting, wonder if Rust would benefit from something similar.

[1] https://github.com/elm-lang/error-message-catalog

Rust has a strong policy of adding tests when adding/changing code, so almost all error messages are tested in some form, including "UI" tests, that check the exact formatting.

Additionally, there's https://doc.rust-lang.org/error-index.html

Rust's error messages are (well, try to be) similar, and in fact explicitly inspired by Elm: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...

I think my point was that they may teach you if you already have some fundamental knowledge (or help remind you of the rules anyway) but they're not instructive in and of themselves (you could copy-paste the suggestion to "fix" your problem quickly but that's not really increasing your understanding I think).

>In terms of correctness, I've never heard claims about improving security issues, except in so far as those caused by memory/concurrency - think of it as necessary but not sufficient for security.

Huh? Those might not be sufficient, but are the source of 99% of security issues.

Spectre & meltdown would like to have a word with you. Yes, memory/concurrency are a large class of problems for C/C++, but plenty of security issues still exist in other languages (check out the CVE count for Django for instance). The thing about security is that attackers will predominantly use the path of least resistance. As prevention evolves so does the sophistication & vector of attacks (e.g. timing attacks attack high-level implementation details rather than buffer overflows or algorithmic flaws). Do you have any supporting evidence for your 99% claim? That seems vastly overstated.

>Spectre & meltdown would like to have a word with you.

Both are highly atypical, once in a decade, CPU issues, so represent 0% of software related bugs.

Those 2 bugs are part of the class of timing attacks which are quite common for security & no amount of memory safety will help you there (as Spectre & meltdown have shown they're not even restricted to the SW domain). Same goes for things like not sanitizing inputs for things like SQL injection, XSS etc. AFAIK Rust doesn't do much on that front either. I don't disagree that memory related errors are the cause of a lot of problems. However, I think that's because C/C++ is so common & it's such low-hanging fruit, why bother? I see no evidence that attackers are running out of tricks to pull to exploit SW regardless of the language it's written in or the countermeasures you have deployed.

> In terms of correctness, I've never heard claims about improving security issues

I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues.

> As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that.

Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;)

Alternatively, write some C++ code that uses std::map<std::string, std::string> or something like that incorrectly, and marvel at the page-long exceptions with all the default template arguments expanded into an unreadable mess.

> Also, the Rust compiler appears pretty vibrant with lots of improvements being made to help with user friendliness, so it's possible that further improvements in inference might reduce the problem spots (it's already pretty magic to me).

I also recently got into Rust (coming from Go), and the thing I miss most is `gofmt`. Is there a standard tool-enforced coding style for Rust that the community agrees on, in the same way that the Go community has by and large agreed on gofmt?

rustfmt https://github.com/rust-lang-nursery/rustfmt

There is rustfmt https://github.com/rust-lang-nursery/rustfmt though it is a work in progress: https://github.com/rust-lang-nursery/fmt-rfcs

> Is there a standard tool-enforced coding style for Rust that the community agrees on, in the same way that the Go community has by and large agreed on gofmt?

https://github.com/rust-lang-nursery/rustfmt

And is planned to be distributed with the compiler and the cargo stack by default

Ugh, C++ template errors, the bane of my existence (and why I personally avoid using anything beyond dead-simple ones unless I have to interface with STL).

Only thing worse are Java generics, if only because they literally tried to tack them in 10 (heck, getting close to 15 years now) years ago and we are still feeling the consequences of those design choices today, (unless Java 8+ made major fixes to this. Haven't used it in enough detail to make a judgement).

template errors blurb a big wall of text, but if you know how to read it it only takes a few second to find in your code where your problem is. You generally just have to look at the "required from here" (in clang and gcc at least) message which points to your own code 9 times out of ten.

https://my.mixtape.moe/xdkchm.webm

> I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues.

I think perhaps I didn't communicate my meaning clearly enough. Rust does significantly reduce the risk of a certain class of security problems (reduce not eliminate since it's highly unlikely you'll have 0 unsafe{} blocks anywhere in your dependency chain). That's not disputable since that's part of the language design. That's certainly an advantage it has over C/C++. However, security is far more than just memory safety & I have read nowhere that writing more secure code is a design goal for Rust (I'm not even sure yet such a thing is possible).

> Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;)

> Alternatively, write some C++ code that uses std::map<std::string, std::string> or something like that incorrectly, and marvel at the page-long exceptions with all the default template arguments expanded into an unreadable mess.

I agree 100%. I think perhaps you misread what I wrote? I said I have not encountered a compiler where the errors helps you understand a language.

> Is there a standard tool-enforced coding style for Rust that the community agrees on, in the same way that the Go community has by and large agreed on gofmt?

rustfmt

I think Elm has some of the best engineering around that: http://elm-lang.org/blog/compiler-errors-for-humans and http://elm-lang.org/blog/compilers-as-assistants

While it's also not perfect or can correctly identify all possible syntax/intent errors, it's a valuable tool to learn the language nonetheless.

Reply on news.ycombinator.com