2017 Rust Roadmap

Post by tmzt » Sun, Oct 23, 2016, 7:35 AM UTC

steveklabnik wrote: post #116

cheepin wrote: post #15

I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compil…

This is an area in which I haven't quite figured out how to communicate properly; I feel like I have a good understanding of how Rust maps to asm, but I don't know how to transfer that understanding to other people. I'll certainly be reading your link below, thanks for that!

Post by Too » Sun, Oct 23, 2016, 7:47 AM UTC

tatterdemalion wrote: post #84

kalkin wrote: post #83

Earlier quoted context omitted.

Speaking of "guaranteed not to allocate", is there a way that you could express that in a type? Seems like that might be nice to have.

Not in Rust's type system. In a pure language, you could have some sort of "Heap" monad similar to the "IO" type in Haskell.

Post by berntb » Sun, Oct 23, 2016, 11:54 AM UTC

pjmlp wrote: post #171

berntb wrote: post #169

Earlier quoted context omitted.

I note the long list of obvious examples...? :-) But sure, the world would be a better place if Rust, Go and/or Swift could fulfill that niche. I really don't know enough. (Go seems a bit boring. Rust is too new. Swift is a bit limited re Linux etc support.) (I've seen the claim that some C++ gurus could develop features as quick as seasoned scripters, but... how many years did it take to get to that state? :-( ) (So…

OCaml and Lisp come to mind as possible examples. Also note that for me personally, I don't see any value in using scripting languages for anything other than system administration instead of the more cryptic shell variants.

Post by naasking » Sun, Oct 23, 2016, 12:27 PM UTC

pcwalton wrote: post #159

naasking wrote: post #123

Earlier quoted context omitted.

> When people (rightly) talk about how much slower reference counting is than tracing GC, they're almost always talking about either thread-safe tracing GC vs. thread-safe reference counting or single-threaded tracing GC vs. single-threaded reference counting. Reference counting has always been slower, even in single-threaded cases. This should be obvious because pure reference counting requires modifying counts when…

> This should be obvious because pure reference counting requires modifying counts whenever locals are assigned, which happen orders of magnitude more often than main memory updates, and now each local assignment requires touching main memory too. I guess so, but it's worth noting that this isn't the case in Rust, because Rc benefits from move semantics. Most assignments don't touch the reference counts at all.

Post by lispm » Sun, Oct 23, 2016, 12:55 PM UTC

pjmlp wrote: post #177

berntb wrote: post #176

Earlier quoted context omitted.

Ah, of course. I have long wondered why (Common) Lisp didn't take over the world at the end of the 90s to the beginning of the millennium. :-( They have a GC, but so do Java. There were good compilers since at least the 80s. But the lisp variants aren't really a system programming language that will replace C. (You can do bit fiddling, but... here the GC comes in, especially for embedded applications with KB of RAM.…

A thing called UNIX where the source code was available for free happened, but lets forget that fact. GC bashers would be surprised how much their lifes actually depends on embedded systems running real time Java deployments.