7 ms·

The biggest selling point for Rust is a non-obvious one and one that is hard to "sell" with screenshots: refactoring. Despite having few tools for automatic ref

The biggest selling point for Rust is a non-obvious one and one that is hard to "sell" with screenshots: refactoring. Despite having few tools for automatic refactoring, manual refactoring of large Rust codebases is a breeze: change the portion of code you care about, follow the compiler's complaints and by the end you're likely to have a codebase in a good state. I wouldn't be able to go back to a dynamic language after using Rust for so long, I'd be in constant panic about changing the smallest thing. I equate it to the same discomfort I feel when getting on a car with no seatbelts. I'm just waiting on the day when I can plug the change I want to do to rustfix and let it figure it out, with the help from the compiler.

mehrdadn 8y ago
I think the question was what the biggest selling point is for those who already do e.g. C++, not for those using dynamic languages like Python.
- 0815test 8y ago
  Both questions are important, though. The Rust community is in a very compelling position, in being able to appeal to both the C/C++/'system programming' and the Python/Ruby/etc/'high-level application programming' dev communities.
  - mehrdadn 8y ago
    What I was trying to say was that ease of rafactoring compared to a dynamic language like Python isn't omitted because it's "non-obvious". Rather, it's in fact quite obvious, and simply omitted because it's answering a different question than the one that was asked. Robust refactoring isn't Rust-specific or even new. It's always been the selling point of many statically typed languages, like C++, D, Java, etc.
    - estebank 8y ago
      I mentioned Python because it sits in the other extreme, but the combination of pattern matching, strong types, type inference and ergonomic combinators on the standard library makes the experience much nicer than, for example, Scala. Robust refactoring isn't new. Rust isn't novel. It's just well put together because it had the benefit of hindsight and being able to consider how different advanced features fit together without having to abide by backwards compatibility until recently. Refactoring a single threaded process that operates over a vector can be a single line code change, and the compiler is capable of complaining about data races by leveraging the type system and lifetime analysis.
      - kod 8y ago
        Much nicer than scala? I don't see how you can claim that if you've touched futures in both languages. Rust is a nice language for threaded programming, but the async situation is a trainwreck 4 years in the making.
        0815test 8y ago
        The async situation for Rust is very much in flux, of course - see https://areweasyncyet.rs/ https://areweasyncyet.rs/ for details and updates. It's definitely a pain point at this time, and stability itself is an important value so I can see this making Rust less desirable for some - but calling it a "trainwreck" that the Rust community is supposedly to blame for just seems pointless, other than as snarky flamebait. That sort of comment is a good fit for `rustjerk`, not for the sort of substantive discussion we seek on HN.
        estebank 8y ago
        I have touched both and async in Rust is indeed half baked at the moment. That a factor of immaturity of Rust and maturity of Scala. I also had a Scala codebase that had 4 different Future classes, due to it having been an early adopter. I was thinking if the language itself, where it needs to keep backwards compatibility with Java (the distinction between case classes and classes, for example) and over engineering (implicit action at a distance all over the place). I think Scala is a nice language buried in way too much syntactic sugar. Interestingly enough, Rust's syntax doesn't bother me but quite a few people seem out off by it. Rust is new and it advances slowly but at a steady state. Given its immaturity in some areas I can only go off potential and the async story seems to have a bright future, despite it's somewhat underwhelming present.
- leshow 8y ago
  I think you'd be surprised, Rust has seen a lot of adoption & interest from the dynamic languages crowd.
  - jchw 8y ago
    Go and Rust killed my interest in writing Python code. A paradigm shift worth losing amazing libraries and frameworks like SQLalchemy and Django is rare, but I believe we are here (and have been for a while.)
    - mehrdadn 8y ago
      > Go and Rust killed my interest in writing Python code. Strange to see Go suddenly brought in to support Rust like this. Was it Go that killed said interest or Rust? Why is Go relevant here?
      - jchw 8y ago
        For the same reasons: it offers a strong alternative to C/C++ with memory safety. Often I want performance like C++ but cleaner code and memory safety. Before recently, Python was a go-to when you didn't want to cut yourself on C++s sharp edges, even with it's disadvantages. The overlap isn't clean, but Go is strong for writing simple programs and glue layers, and Rust is strong for writing complex software where correctness and performance are both very important. Python still has a fair bit of expressive power that Go and Rust would struggle to provide, but I think both can be compelling alternatives in different cases, and they offer a lot in exchange (such as, full type safety and improved performance.) I realize Rust offers much more safety than Go, but both of them are eons ahead of C++ in this regard. When you're starting from nothing, any level of guarantees is a huge shift.
        blub 8y ago
        You're confusing "correctness" with not crashing because of invalid memory access, which is a low bar to clear. There's really no proof that systems written in Rust have better reliability compared to systems written in Java, Typescript or PHP, is there? I've recently had the same discussion with someone claiming that FP offers stronger correctness guarantees than OO languages: where's the proof? Furthermore, Rust doesn't offer "much more" safety than Go either, in fact Go's GC suggests that it's harder to make memory handling errors in Go compared to Rust. After all Rust's still vulnerable to memory leaks. Finally, comparing C++ and Rust reliability is much more nuanced than your dismissive attempt. Modern C++ written by an experienced team + good tooling can have really good memory safety, not as good as Rust, but good enough so that the other advantages of C++ can tip the balance in its favor. The problem: many projects don't use modern C++, or they don't have experienced devs or they neglect the tooling. But here's the kicker - those same teams are unlikely to use Rust anyway. Here I expect Firefox or Chrome to be given as counter-examples to which I's say that it's likely impossible to write a memory safe browser in C++, due to the project dynamic. Remains to be seen if it's possible to do it in Rust.
burk96 8y ago
> I wouldn't be able to go back to a dynamic language after using Rust for so long, I'd be in constant panic about changing the smallest thing. As someone who has been working mainly in Rust for about a year and is now starting to pick up Python, this is huge! I pretty much never write Python that isn't explicitly typed thanks to how Rust changed me as a programmer.
- arcticbull 8y ago
  Same. I think Rust has been the biggest thing for me in terms of growth as an engineer in recent memory, and I've worked across the stack from HDLs to embedded to mobile to desktop to server over the course of my career.
ajxs 8y ago
I'm really glad to see that there is a huge resurgence in support for statically typed languages in mainstream programming. I always felt that this was somewhat inevitable, but the tide of opinion was against it for a while. I completely agree, and the inverse situation is true too. If you're used to statically typed languages, working with a dynamically typed language can be hellish if your codebase is suitably complex! And by suitably complex I mean more than >500LOC. ( That's not a typo, the omission of the 'K' is intentional. )
- arcticbull 8y ago
  I'd love your thoughts on this, my guess is it's because of ergonomics improvements. Specifically, inferred types. This middle-ground lets you have much of the ergonomics of a dynamic language but with the safety of a static one. You may have to hint it from time to time, but for the most part (99%+) Rust guesses the types of everything I do day to day, and when it doesn't know, it ... asks.
  - steveklabnik 8y ago
    In some sense. I mean, type inference is not new. But the languages that really brought static typing to the masses didn’t use it, or only did deduction, so it is “new” to a lot of programmers. I do think that there’s a relationship between power and usefulness, but more power isn’t always better. I’d rather use Ruby than Java 1.5, but I’d rather use Rust than Ruby. YMMV.
    - typeliftr03 8y ago
      It's kind of sad to me that (almost) complete type inference has been around since the [70s](https://en.wikipedia.org/wiki/Hindley–Milner_type_system https://en.wikipedia.org/wiki/Hindley–Milner_type_system) and it's still not mainstream. (unless you consider F# or OCaml mainstream languages)
      - pkolaczk 8y ago
        Type annotations at the signature level are documentation, so I'm not so sure if global type inference is really better than local type inference. Also HM type inference doesn't play nice with type systems with subtyping or method overloading.
maxxxxx 8y ago
“change the portion of code you care about, follow the compiler's complaints and by the end you're likely to have a codebase in a good state.” That has always been my refactoring algorithm with C++, C# of TypeScript now. I know a lot of smart people using dynamic languages but I always prefer to lean on the compiler to tell me what needs to be changed.
DCoder 8y ago
This is one of the big reasons I use TypeScript over plain JS as well, especially when combined with TSX for typesafe views.
mzl 8y ago
> refactoring of large Rust codebases is a breeze: change the portion of code you care about, follow the compiler's complaints At my $DAYJOB I write a lot of Java, and modern full-featured IDE's for Java like IntelliJ are absolutely awersome for refactoring. Most common refactorings are fully automated, and many more complex things are very easy to do by combinding some of the base refactorings. I really like writing Rust in side projects, but after getting used to the phenomenal support refactoring support in Java, having to follow the compilers diagnostics feels very primitive.
- Sahhaese 8y ago
  Jetbrains' refactoring tools have always been top tier. For years resharper was absolutely essential for C# development because visual studio just lacked good refactoring. VS has been catching up and has mostly caught up in recent editions but I doubt that would have happened if not for MS being able to see just how popular resharper is. I'd hope that as Rust grows in popularity the tooling will come from that so I'd keep an eye on the intelliJ rust plugin or rider support for rust because as you say, it's really difficult to go from a day job where for example promoting a local variable to a parameter (with replacement at the call sites) just works to one where you actually have to think about manual refactoring.
  - 0815test 8y ago
    > I'd hope that as Rust grows in popularity the tooling will come from that ... Patches are welcome! https://areweideyet.com/ https://areweideyet.com/
  - mzl 8y ago
    The Rust plug-in, is already quite nice, and getting better all the time. I use it from CLion, since that has integrated debuging support.
  - int_19h 8y ago
    One reason why I'm optimistic about Rust is because the team not only explicitly recognizes the need for advanced tooling (such as IDEs), but owns critical parts of the underlying infrastructure, such as RLS. If you want a language to have quality tooling, it needs to be designed for that, and there's no better forcing function for that than having to write that tooling yourself, or at least having someone who does on the same team, in constant communication.

mehrdadn 8y ago

I think the question was what the biggest selling point is for those who already do e.g. C++, not for those using dynamic languages like Python.

0815test 8y ago
Both questions are important, though. The Rust community is in a very compelling position, in being able to appeal to both the C/C++/'system programming' and the Python/Ruby/etc/'high-level application programming' dev communities.
- mehrdadn 8y ago
  What I was trying to say was that ease of rafactoring compared to a dynamic language like Python isn't omitted because it's "non-obvious". Rather, it's in fact quite obvious, and simply omitted because it's answering a different question than the one that was asked. Robust refactoring isn't Rust-specific or even new. It's always been the selling point of many statically typed languages, like C++, D, Java, etc.
  - estebank 8y ago
    I mentioned Python because it sits in the other extreme, but the combination of pattern matching, strong types, type inference and ergonomic combinators on the standard library makes the experience much nicer than, for example, Scala. Robust refactoring isn't new. Rust isn't novel. It's just well put together because it had the benefit of hindsight and being able to consider how different advanced features fit together without having to abide by backwards compatibility until recently. Refactoring a single threaded process that operates over a vector can be a single line code change, and the compiler is capable of complaining about data races by leveraging the type system and lifetime analysis.
    - kod 8y ago
      Much nicer than scala? I don't see how you can claim that if you've touched futures in both languages. Rust is a nice language for threaded programming, but the async situation is a trainwreck 4 years in the making.
      - 0815test 8y ago
        The async situation for Rust is very much in flux, of course - see https://areweasyncyet.rs/ https://areweasyncyet.rs/ for details and updates. It's definitely a pain point at this time, and stability itself is an important value so I can see this making Rust less desirable for some - but calling it a "trainwreck" that the Rust community is supposedly to blame for just seems pointless, other than as snarky flamebait. That sort of comment is a good fit for `rustjerk`, not for the sort of substantive discussion we seek on HN.
      - estebank 8y ago
        I have touched both and async in Rust is indeed half baked at the moment. That a factor of immaturity of Rust and maturity of Scala. I also had a Scala codebase that had 4 different Future classes, due to it having been an early adopter. I was thinking if the language itself, where it needs to keep backwards compatibility with Java (the distinction between case classes and classes, for example) and over engineering (implicit action at a distance all over the place). I think Scala is a nice language buried in way too much syntactic sugar. Interestingly enough, Rust's syntax doesn't bother me but quite a few people seem out off by it. Rust is new and it advances slowly but at a steady state. Given its immaturity in some areas I can only go off potential and the async story seems to have a bright future, despite it's somewhat underwhelming present.
leshow 8y ago
I think you'd be surprised, Rust has seen a lot of adoption & interest from the dynamic languages crowd.
- jchw 8y ago
  Go and Rust killed my interest in writing Python code. A paradigm shift worth losing amazing libraries and frameworks like SQLalchemy and Django is rare, but I believe we are here (and have been for a while.)
  - mehrdadn 8y ago
    > Go and Rust killed my interest in writing Python code. Strange to see Go suddenly brought in to support Rust like this. Was it Go that killed said interest or Rust? Why is Go relevant here?
    - jchw 8y ago
      For the same reasons: it offers a strong alternative to C/C++ with memory safety. Often I want performance like C++ but cleaner code and memory safety. Before recently, Python was a go-to when you didn't want to cut yourself on C++s sharp edges, even with it's disadvantages. The overlap isn't clean, but Go is strong for writing simple programs and glue layers, and Rust is strong for writing complex software where correctness and performance are both very important. Python still has a fair bit of expressive power that Go and Rust would struggle to provide, but I think both can be compelling alternatives in different cases, and they offer a lot in exchange (such as, full type safety and improved performance.) I realize Rust offers much more safety than Go, but both of them are eons ahead of C++ in this regard. When you're starting from nothing, any level of guarantees is a huge shift.
      - blub 8y ago
        You're confusing "correctness" with not crashing because of invalid memory access, which is a low bar to clear. There's really no proof that systems written in Rust have better reliability compared to systems written in Java, Typescript or PHP, is there? I've recently had the same discussion with someone claiming that FP offers stronger correctness guarantees than OO languages: where's the proof? Furthermore, Rust doesn't offer "much more" safety than Go either, in fact Go's GC suggests that it's harder to make memory handling errors in Go compared to Rust. After all Rust's still vulnerable to memory leaks. Finally, comparing C++ and Rust reliability is much more nuanced than your dismissive attempt. Modern C++ written by an experienced team + good tooling can have really good memory safety, not as good as Rust, but good enough so that the other advantages of C++ can tip the balance in its favor. The problem: many projects don't use modern C++, or they don't have experienced devs or they neglect the tooling. But here's the kicker - those same teams are unlikely to use Rust anyway. Here I expect Firefox or Chrome to be given as counter-examples to which I's say that it's likely impossible to write a memory safe browser in C++, due to the project dynamic. Remains to be seen if it's possible to do it in Rust.

burk96 8y ago

> I wouldn't be able to go back to a dynamic language after using Rust for so long, I'd be in constant panic about changing the smallest thing. As someone who has been working mainly in Rust for about a year and is now starting to pick up Python, this is huge! I pretty much never write Python that isn't explicitly typed thanks to how Rust changed me as a programmer.

arcticbull 8y ago
Same. I think Rust has been the biggest thing for me in terms of growth as an engineer in recent memory, and I've worked across the stack from HDLs to embedded to mobile to desktop to server over the course of my career.

ajxs 8y ago

I'm really glad to see that there is a huge resurgence in support for statically typed languages in mainstream programming. I always felt that this was somewhat inevitable, but the tide of opinion was against it for a while. I completely agree, and the inverse situation is true too. If you're used to statically typed languages, working with a dynamically typed language can be hellish if your codebase is suitably complex! And by suitably complex I mean more than >500LOC. ( That's not a typo, the omission of the 'K' is intentional. )

arcticbull 8y ago
I'd love your thoughts on this, my guess is it's because of ergonomics improvements. Specifically, inferred types. This middle-ground lets you have much of the ergonomics of a dynamic language but with the safety of a static one. You may have to hint it from time to time, but for the most part (99%+) Rust guesses the types of everything I do day to day, and when it doesn't know, it ... asks.
- steveklabnik 8y ago
  In some sense. I mean, type inference is not new. But the languages that really brought static typing to the masses didn’t use it, or only did deduction, so it is “new” to a lot of programmers. I do think that there’s a relationship between power and usefulness, but more power isn’t always better. I’d rather use Ruby than Java 1.5, but I’d rather use Rust than Ruby. YMMV.
  - typeliftr03 8y ago
    It's kind of sad to me that (almost) complete type inference has been around since the [70s](https://en.wikipedia.org/wiki/Hindley–Milner_type_system https://en.wikipedia.org/wiki/Hindley–Milner_type_system) and it's still not mainstream. (unless you consider F# or OCaml mainstream languages)
    - pkolaczk 8y ago
      Type annotations at the signature level are documentation, so I'm not so sure if global type inference is really better than local type inference. Also HM type inference doesn't play nice with type systems with subtyping or method overloading.

maxxxxx 8y ago

“change the portion of code you care about, follow the compiler's complaints and by the end you're likely to have a codebase in a good state.” That has always been my refactoring algorithm with C++, C# of TypeScript now. I know a lot of smart people using dynamic languages but I always prefer to lean on the compiler to tell me what needs to be changed.

DCoder 8y ago

This is one of the big reasons I use TypeScript over plain JS as well, especially when combined with TSX for typesafe views.

mzl 8y ago

> refactoring of large Rust codebases is a breeze: change the portion of code you care about, follow the compiler's complaints At my $DAYJOB I write a lot of Java, and modern full-featured IDE's for Java like IntelliJ are absolutely awersome for refactoring. Most common refactorings are fully automated, and many more complex things are very easy to do by combinding some of the base refactorings. I really like writing Rust in side projects, but after getting used to the phenomenal support refactoring support in Java, having to follow the compilers diagnostics feels very primitive.

Sahhaese 8y ago
Jetbrains' refactoring tools have always been top tier. For years resharper was absolutely essential for C# development because visual studio just lacked good refactoring. VS has been catching up and has mostly caught up in recent editions but I doubt that would have happened if not for MS being able to see just how popular resharper is. I'd hope that as Rust grows in popularity the tooling will come from that so I'd keep an eye on the intelliJ rust plugin or rider support for rust because as you say, it's really difficult to go from a day job where for example promoting a local variable to a parameter (with replacement at the call sites) just works to one where you actually have to think about manual refactoring.
- 0815test 8y ago
  > I'd hope that as Rust grows in popularity the tooling will come from that ... Patches are welcome! https://areweideyet.com/ https://areweideyet.com/
- mzl 8y ago
  The Rust plug-in, is already quite nice, and getting better all the time. I use it from CLion, since that has integrated debuging support.
- int_19h 8y ago
  One reason why I'm optimistic about Rust is because the team not only explicitly recognizes the need for advanced tooling (such as IDEs), but owns critical parts of the underlying infrastructure, such as RLS. If you want a language to have quality tooling, it needs to be designed for that, and there's no better forcing function for that than having to write that tooling yourself, or at least having someone who does on the same team, in constant communication.