Hacker News Reader

Comment by melling | Hacker News Reader

“Since we began our journey with Rust, the number of projects using Rust inside Meta has increased at an accelerated rate”

That almost sounds like an endorsement. I’ve been holding off learning Rust. However, it seems like Rust adoption is reaching a tipping point.

View on HN

> I’ve been holding off learning Rust.

Rust is quite an easy language to learn and a pleasurable language to use, due to its modern ergonomics and internal consistency. Give it a try. The only trick is that Rust newcomers actually need to read up on Rust borrow checker and lifetime annotations first, as opposed to learning Rust only through hacking with it. Those two concepts are unique to Rust and need to be well understood beforehand to avoid frustration.

I don't think Rust is easy to learn, it's has a kind of famously steep learning curve. The tooling is great which helps, but it's not easy for new-ish systems programmers.

Yeah, I have to agree with this. I tried to get my team at my previous work to adopt Rust, and they all pretty much failed to really pick it up. Granted they weren't the most talented group I've worked with.

Every video I've watched on youtube of Rust vs Go makes me think Rust is not a whole lot of fun to write.

The borrow checker and lifetime annotations. It's always the borrow checker and lifetime annotations - otherwise Rust is, IMHO, as readable as (the excellent) Golang.

I've often wondered what it would be like having a variant of Rust that was essentially the same underlying language, but with a garbage collector of some kind instead of a borrow checker and lifetime annotations.

You can approximate this already: forget Rust references (borrow checking + lifetimes; in other words, raw pointers) and start hacking with Rust using its shared ownership (reference-counted) smart pointers, immutable Rc<T>[1], mutable RefCell<T>[2] and the combination of the two[3]. The syntax will, overall, get considerably more dense than Go, but otherwise analogous to Go. Instead of GC cycles, memory will be freed incrementally, immediately when no longer in use.

[1] - https://doc.rust-lang.org/book/ch15-04-rc.html

[2] - https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

[3] - https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

That would be pretty close to OCaml.

That's fair. My favorite language so far has been F#, so maybe it's some of that preference sneaking through.

I've tried learning Rust after learning Go, never really got into it. I also know C, C++, Java, Python, PHP, JS, and a couple others (Perl, anyone?) I find Rust syntax too complex, similar to C++ which I also avoid now.

It's really frustrating to write, until it isn't. The language lets you be extremely expressive with about the same level of mental overhead as a garbage collected language. Once it "clicks," it's a joy to work with.

Well, you will probably think I'm crazy, but for me personally, having a couple of decades of C++ experience, learning Rust turned out to be much easier than learning... Swift. Yes, that famed, ultra-modern, great-as-your-first-programming-language Swift. Except for lifetime annotations and the borrow checker, Rust turned out to be much easier for my brain to parse and memorize than Swift, perhaps due to Rust's consistency and predictability and Swift's horrible language construct bloat.

Going from C++ to Rust is pretty much the easiest path, since most of the "hard" parts of Rust are just automating stuff you do by hand in C++ anyway. For other languages where people regularly get tripped up on "what's the stack vs the heap?" coming to Rust it's a bit of a different story, ime.

Talking about which object "owns" another that a pointer "outlives" what it points to are totally normal parlance for C++ developers and completely foreign to a lot of other folks.

I don't disagree but that says to me that a lot of the "Rust is hard" narrative is actually "low-level systems programming is hard", eg) domain complexity is being misattributed to the language.

I came to rust from the other direction, as it were: from Haskell.

There are a lot of similarities! The type systems are similar, with some name changes (sum types -> enums, typeclasses -> traits). Pattern matching is basically the same. Haskell uses (lazy) lists mostly the same way rust uses iterators. Ownership is new, but imposes some of the same requirements that immutability does (no cycles without shenanigans[0]). Rust requires that values are aliasable XOR mutable: Haskell does too (they're always aliasable and never mutable).

[0] https://wiki.haskell.org/Tying_the_Knot

For someone who understands C++11, I don't think FP concept _in rust_ will be hard.

But someone who understands Haskell, may still find some memory stuff clumsy.

The thing is that mutability is a useful and common property used by most programmers. It takes a bit of buy in to be convinced immutability is a good thing that solves bugs. For example:

Here's a reasonable program to write in Python (wave hands here, my python is rusty)

    queue = [root]
    for node in queue:
      if !node.visited:
        # ... visit the node ...
        node.visited = True
        for child in node.children:
          queue.insert(child)

Here's that in Rust.

    let mut queue = VecDeque::new();
    queue.push_back(root);
    
    for node in &mut queue {
      if !node.visited {
        // ... visit the node ...
        node.visited = true;
        for child in &mut node.children {
          queue.push_back(child);
        }
      }
    }

This will not compile, at all. You need to do a lot of work to restructure the data structures in Rust to get that reasonable program to run soundly. Now that's a good thing, because this would be invalid in C/C++ too due to iterator invalidation and lifetime issues, but it's the kind of thing that people who haven't seen a block of code segfault due to a `push_back` before would be confused by.

It's rather rare for a programmer to need to learn about memory safety when compilers in managed languages just solve it for you, and in other systems languages they assume you already know it (or don't care that you can write unsafe programs).

There's just that additional conceptual burden when learning Rust and why programs that seem syntactically correct and safe are forbidden.

TBH I'm surprised that even works in Python – modifying a collection you're in the middle of iterating seems like a bad habit to get into in any language.

edit: in fact, if you specifically use a deque in Python the way you are in Rust, Python will throw a "RuntimeError: deque mutated during iteration". This is just a bad approach in any language, honestly.

Agreed, python may be a contrived example here. It is possible to pull this off in a few languages where object relocation isn't a problem and mutating a collection during iteration is natural.

> Rust is quite an easy language to learn ... [except for these two incredibly complex topics that permeate the entire language]

For anyone coming from a GC language, Rust is a huge change.

Yes, good point, a switch from a GC-based language to a memory ownership -based language is definitely non-trivial, but you can always just forget Rust references altogether for the time-being and start hacking with Rust with its reference-counted smart pointers, effectively learning Rust as if it were Go. (You will have to switch back to Rust ownership/references later on to get back the performance and the respect of other Rustaceans 8) .)

I mean that's only two things! /hj

Rust is not an easy language to learn. Among languages in common use, it is almost certainly the most difficult language to learn.

Disagree. C++ is the most difficult - the compiler accepts programs which Rust would reject and then they segfault or worse.

That's true, but it doesn't mean C++ is harder to learn. Rust has a broader and more novel conceptual surface area than C++. This is what influences difficulty, not memory safety guarantees.

I postulate that a lot of folks confuse ‘easier to learn’ with ‘easier to get code to compile’ and I disagree that the two are the same. Rust makes it more obvious sooner that you have soooo much to learn.

Rust presents a programmatic model to its users that is exceptionally broad. That model is not objectively more correct, or better, or whatever else, than the model presented by other languages. It provides different guarantees, and extracts different costs, and lifts different concerns into the domain of its users, compared to alternatives. Those particular costs and benefits make sense for certain use cases, and don't make sense for others.

> Rust is quite an easy language to learn

It's funny. I hear two different things, all the time. "Rust is easy to learn" and "Rust has a steep learning curve". Personally, I found it to be the latter, and that's as a serial dabbler/language polyglot. I had a bear of a time wrapping my head around lifetime annotations, and needed someone already familiar with them to sherpa me through that stage.

I think it does a disservice to say, "Rust is easy to learn modulo these two really challenging concepts, plus some other things you are likely unfamiliar with". Python is easy to learn. C++ is hard to learn. I'd rate rust as medium difficulty.

It sure is enjoyable though, I don't think that's ever in doubt.

What makes C++ so hard to learn?

Rust adoption very much seems to be ramping up within the really big companies. Google talking about it both for Android and Chrome, FB with a ton of things, Apple had uses for it I think but I'm blanking on what, Amazon is using it for at least some new AWS infrastucture...

Microsoft has been using it internally as well.

I look forward to seeing Rust# (or R# for maximum confusion).

Yeah. They are both writing code in Rust and also dabbling in creating a language of their own to see how that goes, not necessarily with the intent of releasing it, but at least exploring the space from first principles instead of being incumbered by Rust's decisions. I think the name started with V but I cannot find it right now with quick Googling.

I believe you're thinking of Project Verona.

https://www.microsoft.com/en-us/research/project/project-ver...

This is it, thank you for digging it up!

I wouldn't put much stock in MSR languages until they get usage in other orgs. There's at least a dozen research languages in flight at a given point in time.

They used to have this great site were you could interact with them all: https://web.archive.org/web/20180130101736/https://www.rise4...

Source: I'm a former member of RiSE

Verona is less interesting in the language that I expect to make it into the world sense and more they may learn things while exploring safety that can be applied by someone else. Rust does a lot of good with exploring the safety space, but I hope we don't simply let that be the end of any exploration of building safety into the language at a deep level.

To be fair, many modern C# features have started their life in MSR languages and eventually found their way to C#.

It is also where F# started, although they seem not yet to know where to push it, or if it was a good idea to actually box it in VS 2010.

Note that on Android it is only endorsed for system code by Google itself and OEMs, officially there are no plans to support it on the NDK, or Android Studio.

Yeah sorry I should have been more specific that I meant used in the operating system. That was my bad.

Nothing prevents Google to eventually change their mind in regards to its support on userspace, however given how the NDK has been managed all these years (as a kind of side project at least from the outside), I pretty much doubt it.

Right the future could be anything, so we might as well just talk about the present.

It's commonly used at Cloudflare too. You're probably browsing pages piped via Rust services every day.

Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

This needs to exist in Rust for it to get adopted, because forcing good developers to get explicit with code for memory safety when they are doing simple operations is going to result in them ignoring the language.

So eventually code bases are going to be exactly like C++ code bases - C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively (or better yet, the language disallowed any C style pointers or arrays), the language would be dramatically more safe.

If you want to improve development, focus on smarter compilers/interpreters, not languages.

Being "explicit with code for memory safety [even for] simple operations" is the whole point of Rust. Otherwise, sooner or later, as a codebase grows, you make mistakes that your compiler cannot catch (e.g., you give an immutable reference to a component and later on unexpectedly mutate that same referenced memory from under that component).

> [Rust] [will be] driven into a shit state. Specifically because of [unsafe Rust]

Using unsafe Rust is actually frowned upon in the Rust community, unless you specifically need it in order to interface with another programming language (e.g., Foreign Function Interface), work around some OS issue (e.g., memory pinning for Linux driver development) and so on. Otherwise, you are supposed to always write safe Rust code.

Way more than unsafe Rust, what worries me is the potential future, long-term language feature bloat. I wholeheartedly do hope that Rust core team will keep the language as simple and consistent as humanly possible.

> If you want to improve development, focus on smarter compilers/interpreters, not languages.

Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler - hence Rust's new language features, for example (memory reference) lifetime annotations that all newcomers have a problem with :).

Rust community can't control what happens in enterprise, and enterprise has a nasty habit of prioritizing delivery times over robustness.

>Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler

Yes and no. There are some things you want to specify for compiler to check, but a lot of behavior can be inferred from the code. Think about some backend server functionality for a website that has to do processing on some json data. You could take that code in python and write absolutely safe C code, and the process to translate it wouldn't be that hard.

This needs to exist in order for the Rust standard library to be written in Rust.

> C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively

You can't use smart pointers exclusively, because there is no "smart observational pointer", and there cannot be one, because that would be a reference type checked by a borrow checker, which is exactly what rust uses.

You can emulate it with shared pointers, but then you're left with basically a reference counted language. Why not using swift at this point? Also this creates a semantic impedance mismatch that tends to manifest with cycles.

Source: walked a codebase that would (ab)use shared pointers

The point is you can still write memory safe code and avoid all the double free and user after free bugs if you just use smart pointers correctly and standard namespace constructs. You can be extra safe and use unique pointers and transfer ownership.

Sure, there are some things that Rust makes nice, like compile time checking for errors, however with C++ codebases, they will just result in runtime errors rather than usable exploits.

> focus on smarter compilers/interpreters, not languages

That's...exactly what Rust is doing with their compiler, which checks ownership and lifetimes, so I don't understand your point here. Maybe they didn't need to write a whole new language, but why not add modern features like pattern matching along the way?

Reply on news.ycombinator.com