[kaba0]

Disagree - a low level language can’t really mask itself as high level, the abstraction will always leak. Don’t get me wrong, Rust is a really great language and it is a very welcome addition to the for a long time seemingly stagnant low level world, but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc —- something trivially done in high level languages. C++ tried the same thing, without luck.

So for a typical CRUD app, just use one of the litany of high level language frameworks and be done with it.

[nicoburns]

For many, learning the low-level aspects of programming is the attraction of learning Rust. They want to be exposed to these concepts. What Rust does well is creating a golden pathway with guard rails through which one can learn these concepts without exposing oneself to the pitfalls of memory safety issues, thread safety issues and undefined behaviour.

[kaba0]

I absolutely agree, this was the line I was arguing with: “You can then code with much the same convenience as e.g. Python, Java or C#”

[nicoburns]

Ah I see. My personal take is that while Rust introduces some inconveniences not present in those languages, those languages also have plenty of inconveniences that are not present in Rust. From my perspective, enums and traits are so much better than classes as abstractions that most of the productivity lost is already made back.

[kaba0]

Rust is a very well designed language no doubt, but I think maintenance is where high level languages have an upper hand in some domains.

Also, there are plenty of high level languages with traits, eg Haskell, but if you prefer one where it is easier to express things optionally with an imperative/OOP mindset, Scala.

[staticassertion]

> but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc

This is sort of true, in that I might take reference where I used to take a value, or vice versa, but it's pretty trivial. It's extremely rare for borrow checking or memory layout to slow me down at all when refactoring.

[jeremychone]

Actually, once you get used to Rust, what you “loose” on one side of the productivity (ownership/lifetime/dispatch) you gain on the other side with the ergonomics (enum, matches, expression, …). So our experience, is that at the end, you still a net positive on the productivity side plus the other benefits.

We started to rewrite some of our smaller js/TS utilities, ~3k LOC, and surprisingly Rust was 10% to 20% smaller. Not that it a relevant metric, but still, we were expecting the opposite.

The missing part compared to other languages is specialization, but other patterns can be used. Still, would be nice if they add a good sound specialization construct (min_specialization seems to come short so far)

The biggest challenge is to train a full team on Rust.

[ufmace]

It varies widely based on the type of app. Most simple apps using standard lib or a few basic crates/packages/gems/etc can indeed be switched over without too much fuss. But if you're using any large frameworks with a ton of dynamic features that dictate the structure of your application, such as Rails or Django, then it's hopeless, it'll need a complete rewrite with major architectural changes.

[moltonel3x]

I actually find Rust easier to refactor Rust code than my other $DAYJOB languages, thanks to its strict type system, its informative function signatures, and its syntax. These are ingredients that make Rust programming "fearless".