Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Four Years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 203 posts

Re: Four Years of Rust

#61

Post by foldr »

sriram_malhar wrote: post #59
jnordwick wrote: post #41

I really want to like Rust, and I've made a few attempts in the past to get involved - I wrote a database driver for a time series database (KDB) in pure Rust among a few other things. I've even done a couple deep dives into rustc to figure out the cause of some iterator slowness (it wasn't giving proper hinting in the LLVM IM). However, I keep having to step back. And in this short time Rust has progressed a lot (an…

You speak of low latency code and doubly linked lists in the same breath. Personally, I have moved from linked data structures to more cache friendly data structures, which means contiguous spaces. No jumping around. It's very liberating.

Doubly linked lists are perhaps not the best example, but there are lots of practical data structures that aren't compatible with the single ownership restriction. It's possible to implement them in safe Rust using various techniques, but it's not ideal.

Then there is the fact that mutation makes things even harder. So for example, you can easily implement a tree using Box to hold pointers to child nodes, but you'll then need a little bit of unsafe code to write a mutable iterator over the tree. (Even mutable iterators for slices require unsafe code under the hood.)

Re: Four Years of Rust

#62

Post by Outpox »

thenewwazoo wrote: post #43
estebank wrote: post #40

Earlier quoted context omitted.

They are, and it is one of the places where I'd see us working towards improving their ergonomics in the next couple of years. In the meantime I'm convinced that most code falls either on "small enough that they can be Copy" or big balls of state that also need internal mutability. For people just arriving to the language I always recommend "don't be afraid of .clone(), .clone() until you understand the rest of the l…

It's funny, I give almost the exact opposite advice when I'm helping Rust newbies. My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes. w.r.t. Arc/Rc, I'd say that it might feel verbose at first, but it makes explicit what a GC does implicitly, and you can get all the benefits of Rust's ownership model at the same ti…

Have you written about this (your diktat about clone()) somewhere? I'd be interested to read more.

Re: Four Years of Rust

#63

Post by xvilka »

Hermitian909 wrote: post #34
lmm wrote: post #20

Earlier quoted context omitted.

What is it you don't like about OCaml, or similar ML-family languages (e.g. F#)? Most of "modern language design" seems to amount to the ML featureset.

As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what…

Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).

Re: Four Years of Rust

#64

Post by thenewwazoo »

estebank wrote: post #50
thenewwazoo wrote: post #43

Earlier quoted context omitted.

It's funny, I give almost the exact opposite advice when I'm helping Rust newbies. My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes. w.r.t. Arc/Rc, I'd say that it might feel verbose at first, but it makes explicit what a GC does implicitly, and you can get all the benefits of Rust's ownership model at the same ti…

> My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes. That is good advice for people that are getting familiar with the borrow checker, making them think about allocations and ownership, but making newcomers that are getting familiar with the entire language, in some cases coming from very different paradigms, can b…

> But it is verbose. I think this is part of the problem with Rust learnability, because Rust makes inefficient code evident (think unsafe, clone and Rc), and that makes experienced programmers want to remove the inefficiency before they are proficient with the language enough to do so, so they encounter the hardest edges of the language early.

That's a really, really insightful way to frame it. I don't think I agree that it's a problem, though. Indeed, it's probably the very thing I like most. There's a fine line between syntactic sugar and obfuscating the underlying principles (e.g., I think async syntax is toeing that line). I feel (and I've read others saying the same) that one of the reasons Rust has made me a better programmer is because it makes thinking about this complexity second-nature, and now I do it even when other languages permit (or encourage!) me to forget it.

I'm big on pedagogical rigor and I think there's a particular way to come at learning Rust that results in things like Arc/Rc/RefCell et al feeling good and natural (also, dealing with Result::Err, for similar reasons). I think both of our experiences are equally valid and probably entirely situational. I'll have to think a bit more about it. I have an opportunity to teach Rust to a large-ish group within my company, so it's top of mind for me right now.

Re: Four Years of Rust

#65

Post by thenewwazoo »

Outpox wrote: post #62
thenewwazoo wrote: post #43

Earlier quoted context omitted.

It's funny, I give almost the exact opposite advice when I'm helping Rust newbies. My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes. w.r.t. Arc/Rc, I'd say that it might feel verbose at first, but it makes explicit what a GC does implicitly, and you can get all the benefits of Rust's ownership model at the same ti…

Have you written about this (your diktat about clone()) somewhere? I'd be interested to read more.

I haven't, but maybe I will today.

Re: Four Years of Rust

#66

Post by bitwalker »

amelius wrote: post #45
wyatwerp wrote: post #24

Earlier quoted context omitted.

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

What do you mean by: > Its (thread-local) memory heap is GC'd by default. What happens to objects that are allocated in one thread, and then have their reference passed to another thread?

The typical approach here as far as I'm aware is to use a deallocation queue - frees of an object that was allocated on another thread are freed by putting that object in the original thread's deallocation queue. When that thread gets an opportunity, it frees everything in its deallocation queue to reclaim that memory.

Re: Four Years of Rust

#67

Post by Outpox »

steveklabnik wrote: post #14
alexeldeib wrote: post #12

Earlier quoted context omitted.

I'm interested in Rust and have dabbled but don't follow the community too closely. Why do you say later this year, specifically?

It's not 100% for sure, but it's 99% for sure that async/await will be stable in August. The decision to stabilize is being made in seven days, and if it's decided, it will take that long to make it into its first stable release.

I'm so excited to read this!

Re: Four Years of Rust

#68

Post by ummonk »

UnpossibleJim wrote: post #47
yawn wrote: post #22

Earlier quoted context omitted.

This is exactly how I feel. I'd be all about Rust if it was GC'd. Go is close enough that it's what I reach for for personal projects, but not having ADTs and pattern matching is super frustrating for modeling data.

Not to be the nay sayer here, but garbage collection kind of goes against the premise of Rust, as stated by the mission statement. I'm a fan of Rust, but I also like Python, but they are different tools for different problems. Go seems like the tool for your specific problems. I'm not trying to be offensive towards you, or anything, but Rusts mission statement was written pretty clearly and the reasons against a garb…

You're missing the point. Go is not the tool for their specific problems because it's a crappy language that lacks generics, algebraic data types, etc.

In contrast, a language very much like Rust, but with GC, would be the right tool for their problems.

Re: Four Years of Rust

#69

Post by burntsushi »

thenewwazoo wrote: post #64
estebank wrote: post #50

Earlier quoted context omitted.

> My diktat is "clone is banned unless you can explain why you must have it", and then I teach people about what a move is and how to think about lifetimes. That is good advice for people that are getting familiar with the borrow checker, making them think about allocations and ownership, but making newcomers that are getting familiar with the entire language, in some cases coming from very different paradigms, can b…

> But it is verbose. I think this is part of the problem with Rust learnability, because Rust makes inefficient code evident (think unsafe, clone and Rc), and that makes experienced programmers want to remove the inefficiency before they are proficient with the language enough to do so, so they encounter the hardest edges of the language early. That's a really, really insightful way to frame it. I don't think I agree…

> I have an opportunity to teach Rust to a large-ish group within my company, so it's top of mind for me right now.

If you could share an experience report when you're done, that would be most helpful. :-)

Re: Four Years of Rust

#70

Post by estebank »

foldr wrote: post #61
sriram_malhar wrote: post #59

Earlier quoted context omitted.

You speak of low latency code and doubly linked lists in the same breath. Personally, I have moved from linked data structures to more cache friendly data structures, which means contiguous spaces. No jumping around. It's very liberating.

Doubly linked lists are perhaps not the best example, but there are lots of practical data structures that aren't compatible with the single ownership restriction. It's possible to implement them in safe Rust using various techniques, but it's not ideal. Then there is the fact that mutation makes things even harder. So for example, you can easily implement a tree using Box to hold pointers to child nodes, but you'll…

And that should be fine. unsafe is not something to be forbidden, it is a marker for "here-be-dragons, as the compiler can't check that all invariants are correct when you dereference a raw pointer or modify a mutable static variable". In reality I've found the need for unsafe to be minimal, either when doing something that is actually forbidden for good reason or interacting with C libraries.
Post reply on HN