4 ms·

Yes, I think that's the only new innovation in Rust. Everything else is just an incremental improvement on what already exists elsewhere. Supposedly the develop

by zelly 7y ago

Yes, I think that's the only new innovation in Rust. Everything else is just an incremental improvement on what already exists elsewhere. Supposedly the developer experience/ergonomics is a feature, but everyone I have met says the syntax is ugly. In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin. I can't for the life of me understand why it keeps getting more popular. Memory safety? Security? C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market, but people never used them or actively turned them off. Rust forces you to use a linter. Maybe it's for the best.

winrid 7y ago
The syntax is rough mostly because of lifetime specifiers. struct MyStruct <'a> {...
- zelly 7y ago
  Supposedly lifetime specifiers will be phased out once the compiler gets good enough. I hope so. Syntax matters for adoption.
  - winrid 7y ago
    That would be amazing. I was really banging my head on that one.
    - steveklabnik 7y ago
      It's not true. They're required, as they describe programmer intent.
      - crispinb 7y ago
        Though presumably there's a chance that more could be elided over time?
        steveklabnik 7y ago
        In theory, maybe.
  - Hercuros 7y ago
    I don’t think they are going to be phased out, since including lifetime specifiers is a means of documenting intent (they are part of a function’s public interface). Removing them would mean that seemingly irrelevant internal changes to functions would cause mysterious compiler errors elsewhere.
TheDong 7y ago
> but everyone I have met says the syntax is ugly I like rust's syntax. It has very elegant macro syntax, expressions are values, and all that other good stuff. There are some small parts of it that are ugly, but honestly Java and C++ are far uglier. Templates in c++ are awful. Java's wildcard syntax and lack of macros is ugly. I find rust much prettier syntax-wise than most statically compiled languages. Prettier than Go or Java or c++. > In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin Why not? I don't see any reason why it can't compete. Heck, it's a pretty corporate language too in terms of its mozilla backing. That being said, people constantly talk about how easy it is to get started with python, and python has even less corporate backing than rust. That point makes no sense to me. > C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market C++ does not, and did not, have safety features like rust's. C++ cannot guarantee ownership semantics are correct. It cannot identify data-races at compile-time. Leaving dangling references in C++ is trivial. For example: std::vector<int> v = {1}; auto ref = &v[0]; v.push_back(10); std::cout << *ref; That code compiles in c++ even though 'ref' may be invalid because 'v.push_back' may have reallocated the underlying memory. I don't know of any compile-time tooling for c++ that reliably catches that bug. It's a clear memory safety issue, and it's basically the exact thing rust's ownership system saves you from. In short, I don't think you have a complete understanding of what rust's benefits are nor why it's innovative.
- zelly 7y ago
  > Why not? I don't see any reason why it can't compete. Heck, it's a pretty corporate language too in terms of its mozilla backing. It's niche, been around for over a decade, still hasn't reached critical mass. Golang did. Numerous mainstream projects are in Go that drive entire industries now e.g. docker, k8s. Rust's biggest deployed code is the CSS renderer of a web browser with single digit market share. I'm not saying Golang is better on PL theoretic grounds (obviously it's worse), but it proves what corporate marketing can do, which we have known since the Sun era. Also Python was not that popular until the same corporation behind Golang decided to adopt it and hired Guido. C++ compilers don't catch all the errors, but static analyzers do. Taking your code snippet as an example: % cppcheck ./main.cxx Checking main.cxx ... main.cxx:8:16: error: Using pointer to local variable 'v' that may be invalid. [invalidContainer] std::cout << *ref; ^ main.cxx:6:13: note: Address of variable taken here. auto ref = &v [0]; ^ main.cxx:7:2: note: After calling 'push_back', iterators or references to the container's data may be invalid . v.push_back (10); ^ main.cxx:5:19: note: Variable created here. std::vector<int> v = {1}; ^ There are proprietary static analyzers that go much deeper and catch less obvious bugs. Even without paying, you have ASan, TSan, UBSan, valgrind, afl, among others to do runtime analysis or fuzzing to catch memory errors and data races. Unfortunately these aren't used as much as they should be. Maybe those programmers have a point. In practice, memory management is not remotely the most difficult or bug-prone part of software. If you are using C++11 or later, the standard practice is to never do raw new and delete. std::move(std::unique_ptr...) has the same benefits as Rust borrowing without the borrow checker (although it is not rocket science to detect use-after-move with analyzers). Arc <-> shared_ptr. Sure, Rust's versions are better, but let's not get carried away, it's <10x better than C++ (with 1/10000x the ecosystem, jobs, books, libraries, people).

by zelly 7y ago

winrid 7y ago

The syntax is rough mostly because of lifetime specifiers. struct MyStruct <'a> {...

zelly 7y ago
Supposedly lifetime specifiers will be phased out once the compiler gets good enough. I hope so. Syntax matters for adoption.
- winrid 7y ago
  That would be amazing. I was really banging my head on that one.
  - steveklabnik 7y ago
    It's not true. They're required, as they describe programmer intent.
    - crispinb 7y ago
      Though presumably there's a chance that more could be elided over time?
      - steveklabnik 7y ago
        In theory, maybe.
- Hercuros 7y ago
  I don’t think they are going to be phased out, since including lifetime specifiers is a means of documenting intent (they are part of a function’s public interface). Removing them would mean that seemingly irrelevant internal changes to functions would cause mysterious compiler errors elsewhere.

TheDong 7y ago

> but everyone I have met says the syntax is ugly I like rust's syntax. It has very elegant macro syntax, expressions are values, and all that other good stuff. There are some small parts of it that are ugly, but honestly Java and C++ are far uglier. Templates in c++ are awful. Java's wildcard syntax and lack of macros is ugly. I find rust much prettier syntax-wise than most statically compiled languages. Prettier than Go or Java or c++. > In terms of ease of getting started and using tooling, it really can't ever compete with the corporate languages like Go, Swift, Kotlin Why not? I don't see any reason why it can't compete. Heck, it's a pretty corporate language too in terms of its mozilla backing. That being said, people constantly talk about how easy it is to get started with python, and python has even less corporate backing than rust. That point makes no sense to me. > C++ had the same safety characteristics for at least a decade with dozens of linters and sanitizers on the market C++ does not, and did not, have safety features like rust's. C++ cannot guarantee ownership semantics are correct. It cannot identify data-races at compile-time. Leaving dangling references in C++ is trivial. For example: std::vector<int> v = {1}; auto ref = &v[0]; v.push_back(10); std::cout << *ref; That code compiles in c++ even though 'ref' may be invalid because 'v.push_back' may have reallocated the underlying memory. I don't know of any compile-time tooling for c++ that reliably catches that bug. It's a clear memory safety issue, and it's basically the exact thing rust's ownership system saves you from. In short, I don't think you have a complete understanding of what rust's benefits are nor why it's innovative.

zelly 7y ago
> Why not? I don't see any reason why it can't compete. Heck, it's a pretty corporate language too in terms of its mozilla backing. It's niche, been around for over a decade, still hasn't reached critical mass. Golang did. Numerous mainstream projects are in Go that drive entire industries now e.g. docker, k8s. Rust's biggest deployed code is the CSS renderer of a web browser with single digit market share. I'm not saying Golang is better on PL theoretic grounds (obviously it's worse), but it proves what corporate marketing can do, which we have known since the Sun era. Also Python was not that popular until the same corporation behind Golang decided to adopt it and hired Guido. C++ compilers don't catch all the errors, but static analyzers do. Taking your code snippet as an example: % cppcheck ./main.cxx Checking main.cxx ... main.cxx:8:16: error: Using pointer to local variable 'v' that may be invalid. [invalidContainer] std::cout << *ref; ^ main.cxx:6:13: note: Address of variable taken here. auto ref = &v [0]; ^ main.cxx:7:2: note: After calling 'push_back', iterators or references to the container's data may be invalid . v.push_back (10); ^ main.cxx:5:19: note: Variable created here. std::vector<int> v = {1}; ^ There are proprietary static analyzers that go much deeper and catch less obvious bugs. Even without paying, you have ASan, TSan, UBSan, valgrind, afl, among others to do runtime analysis or fuzzing to catch memory errors and data races. Unfortunately these aren't used as much as they should be. Maybe those programmers have a point. In practice, memory management is not remotely the most difficult or bug-prone part of software. If you are using C++11 or later, the standard practice is to never do raw new and delete. std::move(std::unique_ptr...) has the same benefits as Rust borrowing without the borrow checker (although it is not rocket science to detect use-after-move with analyzers). Arc <-> shared_ptr. Sure, Rust's versions are better, but let's not get carried away, it's <10x better than C++ (with 1/10000x the ecosystem, jobs, books, libraries, people).