29 ms·

Falling in love with Rust

440 points by irfansharif 8y ago

whalesalad 8y ago
I like that the author threads in so many other concepts with links to other blogs that explain those concepts. I really need to get my hands dirty with Rust. A lot of very smart engineers have been throwing projects my direction seeking opinions and I've never been able to properly offer any. The folks working on the language and projects around the language are really sharp. Recently I haven't had any personal projects that aren't a conglomeration of API requests and simple data storage. Rust is more than capable of doing this kind of work but I'd really like to find a pet project that would take advantage of it's performance capabilities.
- mamcx 8y ago
  For me, is build a relational language (http://tablam.org http://tablam.org) (like a kind of data engine, like sqlite but not storage). I never do that kind of work before (ie: language/rdbms) and is a eye opener. I can't denied rust is hard and a lot of time I get lost thinking "why rust don't let me do...". But is truly a good teacher...
steveklabnik 8y ago
This post makes me extremely happy. :D > among the sites of its peers, only Ruby is similarly localized. Given that several prominent Rustaceans like Steve Klabnik and Carol Nichols came from the Ruby community, it would not be unreasonable to guess that they brought this globally inclusive view with them. Not just that, I actually looked at how Ruby's website did it in order to bring it to our site. This has... issues. But it's served us fairly well. Additionally, while there's so much more I could say about this post, one thing: > my naive Rust was ~32% faster than my carefully implemented C. This is a metric I'm more interested in, far more interested than classic benchmarks, where various experts eke every last little bit out of an example. What's the average case here? It is, of course, much much harder to get numbers for these kinds of things...
- k__ 8y ago
  I talked to some embedded C programmers and they said thad basically everything besides C is too slow for their use-cases. I would be interested if they're wrong, hehe
  - steveklabnik 8y ago
    In general, if Rust is significantly slower than equivalent C, it's a bug. We do care about bugs, and if you try some stuff and find them, please file them. (We track them via this tag: https://github.com/rust-lang/rust/labels/I-slow https://github.com/rust-lang/rust/labels/I-slow) Embedded can be tricky at times; we've had a working group pushing on making stuff great all year. There's still a lot of work to be done. Sometimes you need to opt into nightly-only features. We'll get there! (One major example is platform support: since we're built off of LLVM, we may not have a backend for more obscure architectures. ARM stuff works really well, generally. AVR is down to some codegen bugs...)
    - k__ 8y ago
      Are there theoretical boundaries that prevent Rust from ever reaching C performance or is this just a practical question of compiler optimization?
      - thsowers 8y ago
        Not qualified to answer, but I did notice recently that Rust appears to generate more compiler code than equivalent C, but I don't think this realistically has a negative performance impact. You can check this out on godbolt (https://godbolt.org/ https://godbolt.org/)
        raphlinus 8y ago
        It's possible to set compiler flags to optimize for size. That said, I've also seen large binaries, and monomorphization can contribute to that. Some projects are taking that more seriously, for example miniserde is designed to explicitly minimize monomorphization and this improve both code size and compile time.
qaq 8y ago
Honestly watching Brian talk about Rust https://www.youtube.com/watch?v=LjFM8vw3pbU https://www.youtube.com/watch?v=LjFM8vw3pbU is what finally inspired me to get the books and give it a go.
- e12e 8y ago
  Thanks for posting that. Great rant/talk.
  - AceJohnny2 8y ago
    Hah, I think a lot of bcantrill's talks could be classified as rant/talk hybrids ;) Here's his 2011 diatribe against Oracle (after they bought Sun, which he worked for at the time): https://youtu.be/-zRN7XLCRhc?t=34m00s https://youtu.be/-zRN7XLCRhc?t=34m00s
    - qaq 8y ago
      Yep that one is pure gold
- yash1th 8y ago
  Can you tell what books/resources you have used to pick rust?
  - qaq 8y ago
    Honestly so far "The Rust Programming Language" book proved to be the most useful resource.
raphlinus 8y ago
For what it's worth, these observations track closely with my own experience. I like that Cantrill emphasizes values rather than simply technical decisions. The Rust community, I believe, tries to get things right. There's a learning curve, but with much experience, I find myself naturally thinking and writing in Rust code. I can get in the flow, and it feels just as high level and productive as languages prized for those qualities. I'm happy to see other very talented programmers have similar experiences.
skybrian 8y ago
It's kind of weird to say m:n threading is terrible when it seems to work okay in Go. It wasn't the right choice for Rust, but that doesn't mean Go's choice was wrong.
- steveklabnik 8y ago
  As with everything, it's a tradeoff. You're right that it's working well with Go, but that's because Go is willing to accept the downsides of that choice. And they've done some stuff to minimize those downsides. I think both languages made the correct decisions for what they're trying to accomplish as a language.
- Rusky 8y ago
  Go solved the main downside the article cites with M:N threading- it replaced split stacks with growable stacks, via a precise garbage collector.
  - kibwen 8y ago
    That solved the hot split problem, but that was more of a once-in-a-while gotcha. The main downside for Rust specifically was the complications that arise when doing any sort of C interop in the presence of growable stacks. This mattered more for Rust than Go, since Rust is relatively more intended to freely intermingle with C code (and other languages via, C FFI), whereas the happy path for Go tends to involve exclusively Go code in a given process (even going so far as to reimplement their own libc in Go), and use of cgo is discouraged by the community (https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go).
millstone 8y ago
nit: the author describes the '?' operator as both not-magic and magical. IMO an operator that returns is pretty magical. What do others think about '?'? It's certainly more ergonomic than pattern matching / monads etc, but it also seems easy to miss if it's buried in the middle of an expression. I think Swift's try is a bit nicer to use, because it comes at the beginning of the statement, provides more flexibility in how the error should be handled, and supports multiple expressions that may generate errors. On the other hand Swift's error handling is an addition to its type system, instead of being built inside it like Rust.
- james-mcelwain 8y ago
  I'm unsure what "miss" means here. If you forget to add a ?, it's a compilation error.
  - millstone 8y ago
    When I'm reading code, I may not realize that an expression can return, because it can be hard to spot a ? embedded in the middle of the line: sanitize(getFile(getName())?.contents); Swift requires prefixing the line with try, which makes it easier to notice: try sanitize(getFile(getName()).contents) Both are a big improvement over exceptions which have no indication at the call site.
    - eridius 8y ago
      In Swift you can still bury that `try` in the middle of the expression sanitize(try getFile(getName()).contents)
    - kibwen 8y ago
      Bit of a correction, I believe that `try` in Swift must precede an expression that can throw, rather than preceding a statement that can throw, so AFAICT the Swift code would have to be written like this: sanitize((try getFile(getName())).contents) This sort of illustrates why Rust moved away from its own prefix `try!` macro to its postfix `?` operator: in a language that encourages chaining methods, `foo()?.bar()?.qux()?` looks better than `try!(try!(try!(foo()).bar()).qux())`.
azhenley 8y ago
I've been dabbling in Go, but I keep wondering if I would prefer Rust after reading articles like this...
- innocentoldguy 8y ago
  I dabbled in Go for a while too, but found I much prefer Rust, Elixir, and Crystal (even though it is still a bit immature). I know a lot of people love Go, but these other three languages speak to my soul.
  - azhenley 8y ago
    You're making this decision even harder! I used Go a bit in the course I'm teaching this semester, so maybe next semester I'll teach with Rust :)
  - PopeDotNinja 8y ago
    How does the concurrency model in Rust hold up when compared to Erlang/Elixir? Crystal's concurrency seemed lacking the last time I looked (which was a while ago).
    - steveklabnik 8y ago
      The biggest difference is that Rust doesn't force a specific one on you. The language knows nothing about threads. It does have two special traits, Sync and Send, that should be used by any thread-related APIs for concurrency guarantees, and the stdlib thread API does use them. But there are other concurrency/paralellism models beyond std::thread, including really cool stuff like "scoped threads", and more classic "single threaded event loop" stuff, or thread pools. The big differentiator is that Rust proves code free from data races at compile time. Not the specific model. Incidentally, you can write NIFs in Rust...
  - 52-6F-62 8y ago
    This begins to frame one of the problems I have lately. Dabbling in Go, dabbling in Erlang/Elixir, dabbling in Elm, dabbling in Rust...
wasted_intel 8y ago
I'm happy that error handling landed in first place; I feel the same way. Rust is the first language I've used with ADTs, and they're incredibly expressive. It allows the error system to be a set of idioms built atop an expressive type system (okay, so the ? operator does add a little sugar), rather than a discrete language feature, like with exceptions. It brings error handling to the forefront, and it's a big reason why people tend to say "if it compiles, it works" when talking about Rust.
brian-armstrong 8y ago
One of the things that's turned me off about Rust is that a lot of code seems().to().chain().lots().of().operators() Is this idiomatic? It seems powerfully indecipherable/illegible
- staticassertion 8y ago
  It's often idiomatic. I've never found it to be indecipherable at all. I actually find it to be quite readable in most contexts where intermediate variables are just noise. Iterators are a typical example of this. vec![0, 1, 2, 3].into_iter() .filter(|x| x % 2 == 0) // Keep the evens .map(|y| y + 1 ) // Add 1 to elements .rev(); // Reverse the iterator Adding intermediates would just add noise for code like this.
- gamegoblin 8y ago
  It's idiomatically done with newline separators, e.g: let sum = vec_of_ints .iter() .filter(|x| x > 5) .map(|x| x.pow(2)) .take(3) .sum() That is, iterate my vec, only consider values > 5, square them, take the first 3, them sum them. Consider the imperative code: let mut sum = 0; let mut n = 0; for x in vec_of_ints { if x > 5 { sum += x.pow(2); n += 1; if n == 3 { break; } } } I think the chained combinator approach is much easier to see exactly what's happening (and is often higher performance!)
  - zinid 8y ago
    Well, dunno, in my opinion both are equally obscure. I personally don't like "dot notation" and that's one of the reason I don't like Rust. The main problem I see with dot notation is the Pigeon hole problem: why sometimes you write x(y) and sometimes y.x()? While the functions in the above example are trivial, there exist not so obvious cases.
  - Spiritus 8y ago
    That's nice and all. But then you have abominations like this: state .db .send(Queries::GetTopTenHottestYears) .from_err() .and_then(move |res| { result.push(res.unwrap()); state .db .send(Queries::GetTopTenColdestYears) .from_err() .and_then(move |res| { result.push(res.unwrap()); state .db .send(Queries::GetTopTenHottestMonths) .from_err() .and_then(move |res| { result.push(res.unwrap()); state .db .send(Queries::GetTopTenColdestMonths) .from_err() .and_then(move |res| { result.push(res.unwrap()); fut_ok(result) }) }) }) }) .and_then(|res| Ok(HttpResponse::Ok().json(res))) .responder() https://github.com/actix/examples/blob/master/async_db/src/main.rs#L46-L76 https://github.com/actix/examples/blob/master/async_db/src/m... My suspicion is the people do this to avoid "variable does not live long enough" type errors.
bacon_waffle 8y ago
One thing I've been missing in starting with Rust, is a basic GUI library. Conrod looks promising, but the apparent lack of documentation, coupled with being very new to the language, makes for a very steep learning curve. Could anyone suggest where to start developing a cross-platform GUI program in Rust?
- mamcx 8y ago
  The problem with GUI is that actually exist very few good ones. And much less languages with a good implementation. I wonder what if in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_what_a_good_gui_system_would_need/e51o6mw/ https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... how about use Rust for most of the UI logic and off-load the final steps for a native layer. I call it a "almost cross-platform" UI.
- mastax 8y ago
  On mobile, so no links for you ;) I've seen promising things about Qt/QML. Qml in particular helps avoid having to deal with lots of C++ interop. GTK seems to be rallying around Rust, and it actually looks pretty good nowadays. relm is a really interesting elmish wrapper around GTK. Others have put rust components behind an Electron GUI. So tl;dr it's quickly moving from "terrible and immature" to "terrible, like other languages".
  - smittywerben 8y ago
    > I've seen promising things about Qt/QML. For simple GUIs, the problem I always ran into was 1) spooky licensing vs 2) Tkinter vs 3) can this be forced into a browser? > in particular helps avoid having to deal with lots of C++ interop. I agree there is significant demand here. But I also feel a second (smaller) group wants access to GPUs for high-performance visualizations and/or games, since that's usually built in C or C++. > "terrible, like other languages" This made me laugh. I want to move out of the browser and back to the metal.
  - bacon_waffle 8y ago
    Thanks for the pointers! I have used Qt a fair bit for hobby projects, and quite like it in the context of cross-platform C++. But I haven't yet wrapped my head around what a Rust interface to Qt would look like, and results searching https://crates.io https://crates.io for Qt bindings had kinda scared me off. https://github.com/KDE/rust-qt-binding-generator https://github.com/KDE/rust-qt-binding-generator looks quite interesting though! > So tl;dr it's quickly moving from "terrible and immature" to "terrible, like other languages". Ha! Well, at least we don't have so long to wait, I guess.
bogomipz 8y ago
>"Over a decade ago, I worked on a technology to which a competitor paid the highest possible compliment: they tried to implement their own knockoff." Could someone share who the competitor and what the knock off was?
- dralley 8y ago
  Containers maybe?
  - bogomipz 8y ago
    Thanks, right he's a Sun Microsystems alumn. Two very brilliant projects(dtrace and zfs.) Cheers.
- IronBacon 8y ago
  Looking at the blog name I would say DTrace on Solaris (Sun) and SystemTap on Linux.
  - AceJohnny2 8y ago
    Good find. Indeed, looks like Graydon did work on SystemTap in that timeframe: https://www.openhub.net/p/systemtap/contributors?page=4&query=&sort=name&time_span= https://www.openhub.net/p/systemtap/contributors?page=4&quer...
- wscott 8y ago
  I was assuming zfs and btrfs
nixpulvis 8y ago
This resonated with me a lot: > These values reflect a deeper sense within me: that software can be permanent — that software’s unique duality as both information and machine afford a timeless perfection and utility that stand apart from other human endeavor.
- topspin 8y ago
  I recall reading a story about IBM systems programmers writing code for zSeries mainframes. A thing that stuck with me was a discussion about code at the core of this work; virtual memory, IO subsystems, etc. The engineer reflected on how the code he was writing would still be in production when he died. It would survive evolution of the hardware for many generations; they designed it to do this and provide permanent APIs to relying code. I wish I had a copy (..link) to that article. Byte, Computer Shopper... something like that. There are a few pieces of code I wrote in the 90's (in C) that I know are still in use and may survive a few more decades; as long and the companies that I worked for at the time are still in operation anyhow.
VirenM 8y ago
In the past week only there have been 33 posts about Rust. Y Comb loves to constantly push technology in short spurts.
gshrikant 8y ago
I've been on something of a language tour recently - trying out C++, Typescript, OCaml each for a couple of weeks just to get a taste of living in each ecosystem. I haven't been actively following Rust beyond reading Hacker News articles (of which there are many) about people liking the language. One of my pet peeves with several "newer" languages that I've looked at is that users don't usually talk about the ugly parts. You can try out C++ for a week visiting forums and r/cpp and you find out fairly quickly what the pain points are and what typical workarounds look like. At that point, it is up to you to decide to what extent you can live with those downsides and where to tread lightly. Same for C, Python, OCaml etc. To be clear, I don't mean that you should go looking for the bad parts in a language but I do believe you should be aware of them before you invest a lot of your time in it. Unfortunately, a lot of the language love blog posts do not talk about the pain points of the language and what kind of problems it isn't well suited for. I like Rust and I love several features that Bryan talks about (algebraic data types being one of them) but I would love to read a more balanced evaluation of the language - focusing on aspects which are rough around the edges and expected future improvements.
- steveklabnik 8y ago
  You’ll see more of that over the next few months. The roadmap process for rust kicks off with an end-of-the-year call for blog posts about what you want to see in Rust the next year. That invariably brings up areas where Rust could be improved, that’s kind of the point! We’re beta testing the last improvements for the year now, so looking at last year’s posts isn’t going to give you an accurate picture; a lot has happened in the last year! That said, I can give you at least one thing where Rust needs to, and will be, improving over the next months: the async story is finally settling into place, but hasn’t settled yet. Async/await is coming and will improve things so so much. Right now things are a bit boiler-platey, and you can’t always write what would be equivalently idiomatic to the sync code. See here: http://aturon.github.io/2018/04/24/async-borrowing/ http://aturon.github.io/2018/04/24/async-borrowing/
- notriddle 8y ago
  You mean like https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/ ? > This book digs into all the awful details that are necessary to understand in order to write correct Unsafe Rust programs. Due to the nature of this problem, it may lead to unleashing untold horrors that shatter your psyche into a billion infinitesimal fragments of despair. It's surprising how many things in that book don't have anything to do with unsafe per se. It's just that, when you can't rely on the inference system to "do the right thing", you now have to actually think about subtype variance and the order that destructors run in, instead of letting the compiler worry about all that bookkeeping.
_sh 8y ago
My thoughts on the philosophical aspects of the article don't really relate to Rust. > These values reflect a deeper sense within me: that software can be permanent Maybe it can be permanent, but it shouldn't be. Software is disposable and all the time developers are mistakenly fighting this aspect of its nature instead of embracing it. Great software is malleable and develops, over time, to adapt to the human that is using it. But it is impermanent--parts are snipped off here, fleshed out there, nothing stays the same, it is obsolete as soon as it is released. Don't delude yourself that your software will run for a thousand years, be like Warhol and celebrate the ephemera that is pretty much every program ever written. > I have believed (and continue to believe) that we are living in a Golden Age of software, one that will produce artifacts that will endure for generations Museum pieces, sure, but do we still want to be using generations-old software in the years to come? Hope not. Times change, needs change, and software that doesn't change is replaced by software that does, and quick. What about such monumental artifacts as 'cc', 'awk', or even the UNIX kernel? For years they have dominated the landscape, they are the Ozymandias, the King of Kings. If we are still clinging to these titans in another 20, 50 years, is that a good thing?
- scns 8y ago
  COBOL?
  - _sh 8y ago
    SNOBOL!
- jazzyjackson 8y ago
  I'm glad there are Warhols doing their thing but I think the world would be worse off without Michelangelo. awk, vim, whatever Dos 3.1 GUI the guys at B&H use to fulfill my orders, why shouldn't I expect to be using these programs in 50 years? They solve a problem and work every time.
  - _sh 8y ago
    > why shouldn't I expect to be using these programs in 50 years? No reason at all, if they still solve the same problem, they're still the best solution. The problem with 'problems' though, is that once they're cornered they tend to change into a whole new problem. A nasty one the current solution won't work for, usually.
TuringTest 8y ago
I'm I the only one reading the title in Elvis voice?
Animats 8y ago
Maybe Rust has passed through its dark time and come out the other side. There was a long period during which error handling was a mess. First it was too verbose. Then came "try!", which was kind of a hack to return from functions on error. Now there's "?", and a reasonable structure around how to use it.
- majewsky 8y ago
  It depends on what your field is. If you're writing any form of async code that uses futures, Rust is still firmly in the dark ages. I'm being told there is preliminary async/await support on nightly, but it won't be on stable this year.
  - Animats 8y ago
    If you're writing async code with futures, you're probably writing a web service. Go is a better fit for that.
    - majewsky 8y ago
      I'm using both Go and Rust extensively. What I'm doing in Rust, I'm doing in Rust for a reason. Async code is not just for web services.
markpapadakis 8y ago
Watch the Apple - Think Different commercial at https://www.youtube.com/watch?v=cFEarBzelBs https://www.youtube.com/watch?v=cFEarBzelBs , and pay attention to the script/words. It's as if it was purpose-written for Rust. In fact, there's even a callout to Result<> "..but the only thing you can't do, is ignore them" . :)
- coonery 8y ago
  Jesus...
  - markpapadakis 8y ago
    It was mostly sarcasm really — I thought the word play was fun:) kidding aside, I am intrigued by Rust. I am glad it gets the attention that it deserves.
pjmlp 8y ago
This is great sign for Rust, as it is getting adopted by actual OSes. All successful systems programming languages got OS adoption at a given moment on their history. As addendum, even if off-topic, Microsoft is also making use of it on Azure IoT Edge and possibly on Azure Sphere, but the later remains to be confirmed.

440 points by irfansharif 8y ago

I like that the author threads in so many other concepts with links to other blogs that explain those concepts. I really need to get my hands dirty with Rust. A lot of very smart engineers have been throwing projects my direction seeking opinions and I've never been able to properly offer any. The folks working on the language and projects around the language are really sharp. Recently I haven't had any personal projects that aren't a conglomeration of API requests and simple data storage. Rust is more than capable of doing this kind of work but I'd really like to find a pet project that would take advantage of it's performance capabilities.

mamcx 8y ago
For me, is build a relational language (http://tablam.org http://tablam.org) (like a kind of data engine, like sqlite but not storage). I never do that kind of work before (ie: language/rdbms) and is a eye opener. I can't denied rust is hard and a lot of time I get lost thinking "why rust don't let me do...". But is truly a good teacher...

steveklabnik 8y ago

This post makes me extremely happy. :D > among the sites of its peers, only Ruby is similarly localized. Given that several prominent Rustaceans like Steve Klabnik and Carol Nichols came from the Ruby community, it would not be unreasonable to guess that they brought this globally inclusive view with them. Not just that, I actually looked at how Ruby's website did it in order to bring it to our site. This has... issues. But it's served us fairly well. Additionally, while there's so much more I could say about this post, one thing: > my naive Rust was ~32% faster than my carefully implemented C. This is a metric I'm more interested in, far more interested than classic benchmarks, where various experts eke every last little bit out of an example. What's the average case here? It is, of course, much much harder to get numbers for these kinds of things...

k__ 8y ago
I talked to some embedded C programmers and they said thad basically everything besides C is too slow for their use-cases. I would be interested if they're wrong, hehe
- steveklabnik 8y ago
  In general, if Rust is significantly slower than equivalent C, it's a bug. We do care about bugs, and if you try some stuff and find them, please file them. (We track them via this tag: https://github.com/rust-lang/rust/labels/I-slow https://github.com/rust-lang/rust/labels/I-slow) Embedded can be tricky at times; we've had a working group pushing on making stuff great all year. There's still a lot of work to be done. Sometimes you need to opt into nightly-only features. We'll get there! (One major example is platform support: since we're built off of LLVM, we may not have a backend for more obscure architectures. ARM stuff works really well, generally. AVR is down to some codegen bugs...)
  - k__ 8y ago
    Are there theoretical boundaries that prevent Rust from ever reaching C performance or is this just a practical question of compiler optimization?
    - thsowers 8y ago
      Not qualified to answer, but I did notice recently that Rust appears to generate more compiler code than equivalent C, but I don't think this realistically has a negative performance impact. You can check this out on godbolt (https://godbolt.org/ https://godbolt.org/)
      - raphlinus 8y ago
        It's possible to set compiler flags to optimize for size. That said, I've also seen large binaries, and monomorphization can contribute to that. Some projects are taking that more seriously, for example miniserde is designed to explicitly minimize monomorphization and this improve both code size and compile time.

qaq 8y ago

Honestly watching Brian talk about Rust https://www.youtube.com/watch?v=LjFM8vw3pbU https://www.youtube.com/watch?v=LjFM8vw3pbU is what finally inspired me to get the books and give it a go.

e12e 8y ago
Thanks for posting that. Great rant/talk.
- AceJohnny2 8y ago
  Hah, I think a lot of bcantrill's talks could be classified as rant/talk hybrids ;) Here's his 2011 diatribe against Oracle (after they bought Sun, which he worked for at the time): https://youtu.be/-zRN7XLCRhc?t=34m00s https://youtu.be/-zRN7XLCRhc?t=34m00s
  - qaq 8y ago
    Yep that one is pure gold
yash1th 8y ago
Can you tell what books/resources you have used to pick rust?
- qaq 8y ago
  Honestly so far "The Rust Programming Language" book proved to be the most useful resource.

raphlinus 8y ago

For what it's worth, these observations track closely with my own experience. I like that Cantrill emphasizes values rather than simply technical decisions. The Rust community, I believe, tries to get things right. There's a learning curve, but with much experience, I find myself naturally thinking and writing in Rust code. I can get in the flow, and it feels just as high level and productive as languages prized for those qualities. I'm happy to see other very talented programmers have similar experiences.

skybrian 8y ago

It's kind of weird to say m:n threading is terrible when it seems to work okay in Go. It wasn't the right choice for Rust, but that doesn't mean Go's choice was wrong.

steveklabnik 8y ago
As with everything, it's a tradeoff. You're right that it's working well with Go, but that's because Go is willing to accept the downsides of that choice. And they've done some stuff to minimize those downsides. I think both languages made the correct decisions for what they're trying to accomplish as a language.
Rusky 8y ago
Go solved the main downside the article cites with M:N threading- it replaced split stacks with growable stacks, via a precise garbage collector.
- kibwen 8y ago
  That solved the hot split problem, but that was more of a once-in-a-while gotcha. The main downside for Rust specifically was the complications that arise when doing any sort of C interop in the presence of growable stacks. This mattered more for Rust than Go, since Rust is relatively more intended to freely intermingle with C code (and other languages via, C FFI), whereas the happy path for Go tends to involve exclusively Go code in a given process (even going so far as to reimplement their own libc in Go), and use of cgo is discouraged by the community (https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go).

millstone 8y ago

nit: the author describes the '?' operator as both not-magic and magical. IMO an operator that returns is pretty magical. What do others think about '?'? It's certainly more ergonomic than pattern matching / monads etc, but it also seems easy to miss if it's buried in the middle of an expression. I think Swift's try is a bit nicer to use, because it comes at the beginning of the statement, provides more flexibility in how the error should be handled, and supports multiple expressions that may generate errors. On the other hand Swift's error handling is an addition to its type system, instead of being built inside it like Rust.

james-mcelwain 8y ago
I'm unsure what "miss" means here. If you forget to add a ?, it's a compilation error.
- millstone 8y ago
  When I'm reading code, I may not realize that an expression can return, because it can be hard to spot a ? embedded in the middle of the line: sanitize(getFile(getName())?.contents); Swift requires prefixing the line with try, which makes it easier to notice: try sanitize(getFile(getName()).contents) Both are a big improvement over exceptions which have no indication at the call site.
  - eridius 8y ago
    In Swift you can still bury that `try` in the middle of the expression sanitize(try getFile(getName()).contents)
  - kibwen 8y ago
    Bit of a correction, I believe that `try` in Swift must precede an expression that can throw, rather than preceding a statement that can throw, so AFAICT the Swift code would have to be written like this: sanitize((try getFile(getName())).contents) This sort of illustrates why Rust moved away from its own prefix `try!` macro to its postfix `?` operator: in a language that encourages chaining methods, `foo()?.bar()?.qux()?` looks better than `try!(try!(try!(foo()).bar()).qux())`.

azhenley 8y ago

I've been dabbling in Go, but I keep wondering if I would prefer Rust after reading articles like this...

innocentoldguy 8y ago
I dabbled in Go for a while too, but found I much prefer Rust, Elixir, and Crystal (even though it is still a bit immature). I know a lot of people love Go, but these other three languages speak to my soul.
- azhenley 8y ago
  You're making this decision even harder! I used Go a bit in the course I'm teaching this semester, so maybe next semester I'll teach with Rust :)
- PopeDotNinja 8y ago
  How does the concurrency model in Rust hold up when compared to Erlang/Elixir? Crystal's concurrency seemed lacking the last time I looked (which was a while ago).
  - steveklabnik 8y ago
    The biggest difference is that Rust doesn't force a specific one on you. The language knows nothing about threads. It does have two special traits, Sync and Send, that should be used by any thread-related APIs for concurrency guarantees, and the stdlib thread API does use them. But there are other concurrency/paralellism models beyond std::thread, including really cool stuff like "scoped threads", and more classic "single threaded event loop" stuff, or thread pools. The big differentiator is that Rust proves code free from data races at compile time. Not the specific model. Incidentally, you can write NIFs in Rust...
- 52-6F-62 8y ago
  This begins to frame one of the problems I have lately. Dabbling in Go, dabbling in Erlang/Elixir, dabbling in Elm, dabbling in Rust...

wasted_intel 8y ago

I'm happy that error handling landed in first place; I feel the same way. Rust is the first language I've used with ADTs, and they're incredibly expressive. It allows the error system to be a set of idioms built atop an expressive type system (okay, so the ? operator does add a little sugar), rather than a discrete language feature, like with exceptions. It brings error handling to the forefront, and it's a big reason why people tend to say "if it compiles, it works" when talking about Rust.

brian-armstrong 8y ago

One of the things that's turned me off about Rust is that a lot of code seems().to().chain().lots().of().operators() Is this idiomatic? It seems powerfully indecipherable/illegible

staticassertion 8y ago
It's often idiomatic. I've never found it to be indecipherable at all. I actually find it to be quite readable in most contexts where intermediate variables are just noise. Iterators are a typical example of this. vec![0, 1, 2, 3].into_iter() .filter(|x| x % 2 == 0) // Keep the evens .map(|y| y + 1 ) // Add 1 to elements .rev(); // Reverse the iterator Adding intermediates would just add noise for code like this.
gamegoblin 8y ago
It's idiomatically done with newline separators, e.g: let sum = vec_of_ints .iter() .filter(|x| x > 5) .map(|x| x.pow(2)) .take(3) .sum() That is, iterate my vec, only consider values > 5, square them, take the first 3, them sum them. Consider the imperative code: let mut sum = 0; let mut n = 0; for x in vec_of_ints { if x > 5 { sum += x.pow(2); n += 1; if n == 3 { break; } } } I think the chained combinator approach is much easier to see exactly what's happening (and is often higher performance!)
- zinid 8y ago
  Well, dunno, in my opinion both are equally obscure. I personally don't like "dot notation" and that's one of the reason I don't like Rust. The main problem I see with dot notation is the Pigeon hole problem: why sometimes you write x(y) and sometimes y.x()? While the functions in the above example are trivial, there exist not so obvious cases.
- Spiritus 8y ago
  That's nice and all. But then you have abominations like this: state .db .send(Queries::GetTopTenHottestYears) .from_err() .and_then(move |res| { result.push(res.unwrap()); state .db .send(Queries::GetTopTenColdestYears) .from_err() .and_then(move |res| { result.push(res.unwrap()); state .db .send(Queries::GetTopTenHottestMonths) .from_err() .and_then(move |res| { result.push(res.unwrap()); state .db .send(Queries::GetTopTenColdestMonths) .from_err() .and_then(move |res| { result.push(res.unwrap()); fut_ok(result) }) }) }) }) .and_then(|res| Ok(HttpResponse::Ok().json(res))) .responder() https://github.com/actix/examples/blob/master/async_db/src/main.rs#L46-L76 https://github.com/actix/examples/blob/master/async_db/src/m... My suspicion is the people do this to avoid "variable does not live long enough" type errors.

bacon_waffle 8y ago

One thing I've been missing in starting with Rust, is a basic GUI library. Conrod looks promising, but the apparent lack of documentation, coupled with being very new to the language, makes for a very steep learning curve. Could anyone suggest where to start developing a cross-platform GUI program in Rust?

mamcx 8y ago
The problem with GUI is that actually exist very few good ones. And much less languages with a good implementation. I wonder what if in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_what_a_good_gui_system_would_need/e51o6mw/ https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... how about use Rust for most of the UI logic and off-load the final steps for a native layer. I call it a "almost cross-platform" UI.
mastax 8y ago
On mobile, so no links for you ;) I've seen promising things about Qt/QML. Qml in particular helps avoid having to deal with lots of C++ interop. GTK seems to be rallying around Rust, and it actually looks pretty good nowadays. relm is a really interesting elmish wrapper around GTK. Others have put rust components behind an Electron GUI. So tl;dr it's quickly moving from "terrible and immature" to "terrible, like other languages".
- smittywerben 8y ago
  > I've seen promising things about Qt/QML. For simple GUIs, the problem I always ran into was 1) spooky licensing vs 2) Tkinter vs 3) can this be forced into a browser? > in particular helps avoid having to deal with lots of C++ interop. I agree there is significant demand here. But I also feel a second (smaller) group wants access to GPUs for high-performance visualizations and/or games, since that's usually built in C or C++. > "terrible, like other languages" This made me laugh. I want to move out of the browser and back to the metal.
- bacon_waffle 8y ago
  Thanks for the pointers! I have used Qt a fair bit for hobby projects, and quite like it in the context of cross-platform C++. But I haven't yet wrapped my head around what a Rust interface to Qt would look like, and results searching https://crates.io https://crates.io for Qt bindings had kinda scared me off. https://github.com/KDE/rust-qt-binding-generator https://github.com/KDE/rust-qt-binding-generator looks quite interesting though! > So tl;dr it's quickly moving from "terrible and immature" to "terrible, like other languages". Ha! Well, at least we don't have so long to wait, I guess.

bogomipz 8y ago

>"Over a decade ago, I worked on a technology to which a competitor paid the highest possible compliment: they tried to implement their own knockoff." Could someone share who the competitor and what the knock off was?

dralley 8y ago
Containers maybe?
- bogomipz 8y ago
  Thanks, right he's a Sun Microsystems alumn. Two very brilliant projects(dtrace and zfs.) Cheers.
IronBacon 8y ago
Looking at the blog name I would say DTrace on Solaris (Sun) and SystemTap on Linux.
- AceJohnny2 8y ago
  Good find. Indeed, looks like Graydon did work on SystemTap in that timeframe: https://www.openhub.net/p/systemtap/contributors?page=4&query=&sort=name&time_span= https://www.openhub.net/p/systemtap/contributors?page=4&quer...
wscott 8y ago
I was assuming zfs and btrfs

nixpulvis 8y ago

This resonated with me a lot: > These values reflect a deeper sense within me: that software can be permanent — that software’s unique duality as both information and machine afford a timeless perfection and utility that stand apart from other human endeavor.

topspin 8y ago
I recall reading a story about IBM systems programmers writing code for zSeries mainframes. A thing that stuck with me was a discussion about code at the core of this work; virtual memory, IO subsystems, etc. The engineer reflected on how the code he was writing would still be in production when he died. It would survive evolution of the hardware for many generations; they designed it to do this and provide permanent APIs to relying code. I wish I had a copy (..link) to that article. Byte, Computer Shopper... something like that. There are a few pieces of code I wrote in the 90's (in C) that I know are still in use and may survive a few more decades; as long and the companies that I worked for at the time are still in operation anyhow.

VirenM 8y ago

In the past week only there have been 33 posts about Rust. Y Comb loves to constantly push technology in short spurts.

gshrikant 8y ago

I've been on something of a language tour recently - trying out C++, Typescript, OCaml each for a couple of weeks just to get a taste of living in each ecosystem. I haven't been actively following Rust beyond reading Hacker News articles (of which there are many) about people liking the language. One of my pet peeves with several "newer" languages that I've looked at is that users don't usually talk about the ugly parts. You can try out C++ for a week visiting forums and r/cpp and you find out fairly quickly what the pain points are and what typical workarounds look like. At that point, it is up to you to decide to what extent you can live with those downsides and where to tread lightly. Same for C, Python, OCaml etc. To be clear, I don't mean that you should go looking for the bad parts in a language but I do believe you should be aware of them before you invest a lot of your time in it. Unfortunately, a lot of the language love blog posts do not talk about the pain points of the language and what kind of problems it isn't well suited for. I like Rust and I love several features that Bryan talks about (algebraic data types being one of them) but I would love to read a more balanced evaluation of the language - focusing on aspects which are rough around the edges and expected future improvements.

steveklabnik 8y ago
You’ll see more of that over the next few months. The roadmap process for rust kicks off with an end-of-the-year call for blog posts about what you want to see in Rust the next year. That invariably brings up areas where Rust could be improved, that’s kind of the point! We’re beta testing the last improvements for the year now, so looking at last year’s posts isn’t going to give you an accurate picture; a lot has happened in the last year! That said, I can give you at least one thing where Rust needs to, and will be, improving over the next months: the async story is finally settling into place, but hasn’t settled yet. Async/await is coming and will improve things so so much. Right now things are a bit boiler-platey, and you can’t always write what would be equivalently idiomatic to the sync code. See here: http://aturon.github.io/2018/04/24/async-borrowing/ http://aturon.github.io/2018/04/24/async-borrowing/
notriddle 8y ago
You mean like https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/ ? > This book digs into all the awful details that are necessary to understand in order to write correct Unsafe Rust programs. Due to the nature of this problem, it may lead to unleashing untold horrors that shatter your psyche into a billion infinitesimal fragments of despair. It's surprising how many things in that book don't have anything to do with unsafe per se. It's just that, when you can't rely on the inference system to "do the right thing", you now have to actually think about subtype variance and the order that destructors run in, instead of letting the compiler worry about all that bookkeeping.

_sh 8y ago

My thoughts on the philosophical aspects of the article don't really relate to Rust. > These values reflect a deeper sense within me: that software can be permanent Maybe it can be permanent, but it shouldn't be. Software is disposable and all the time developers are mistakenly fighting this aspect of its nature instead of embracing it. Great software is malleable and develops, over time, to adapt to the human that is using it. But it is impermanent--parts are snipped off here, fleshed out there, nothing stays the same, it is obsolete as soon as it is released. Don't delude yourself that your software will run for a thousand years, be like Warhol and celebrate the ephemera that is pretty much every program ever written. > I have believed (and continue to believe) that we are living in a Golden Age of software, one that will produce artifacts that will endure for generations Museum pieces, sure, but do we still want to be using generations-old software in the years to come? Hope not. Times change, needs change, and software that doesn't change is replaced by software that does, and quick. What about such monumental artifacts as 'cc', 'awk', or even the UNIX kernel? For years they have dominated the landscape, they are the Ozymandias, the King of Kings. If we are still clinging to these titans in another 20, 50 years, is that a good thing?

scns 8y ago
COBOL?
- _sh 8y ago
  SNOBOL!
jazzyjackson 8y ago
I'm glad there are Warhols doing their thing but I think the world would be worse off without Michelangelo. awk, vim, whatever Dos 3.1 GUI the guys at B&H use to fulfill my orders, why shouldn't I expect to be using these programs in 50 years? They solve a problem and work every time.
- _sh 8y ago
  > why shouldn't I expect to be using these programs in 50 years? No reason at all, if they still solve the same problem, they're still the best solution. The problem with 'problems' though, is that once they're cornered they tend to change into a whole new problem. A nasty one the current solution won't work for, usually.

TuringTest 8y ago

I'm I the only one reading the title in Elvis voice?

Animats 8y ago

Maybe Rust has passed through its dark time and come out the other side. There was a long period during which error handling was a mess. First it was too verbose. Then came "try!", which was kind of a hack to return from functions on error. Now there's "?", and a reasonable structure around how to use it.

majewsky 8y ago
It depends on what your field is. If you're writing any form of async code that uses futures, Rust is still firmly in the dark ages. I'm being told there is preliminary async/await support on nightly, but it won't be on stable this year.
- Animats 8y ago
  If you're writing async code with futures, you're probably writing a web service. Go is a better fit for that.
  - majewsky 8y ago
    I'm using both Go and Rust extensively. What I'm doing in Rust, I'm doing in Rust for a reason. Async code is not just for web services.

markpapadakis 8y ago

Watch the Apple - Think Different commercial at https://www.youtube.com/watch?v=cFEarBzelBs https://www.youtube.com/watch?v=cFEarBzelBs , and pay attention to the script/words. It's as if it was purpose-written for Rust. In fact, there's even a callout to Result<> "..but the only thing you can't do, is ignore them" . :)

coonery 8y ago
Jesus...
- markpapadakis 8y ago
  It was mostly sarcasm really — I thought the word play was fun:) kidding aside, I am intrigued by Rust. I am glad it gets the attention that it deserves.

pjmlp 8y ago

This is great sign for Rust, as it is getting adopted by actual OSes. All successful systems programming languages got OS adoption at a given moment on their history. As addendum, even if off-topic, Microsoft is also making use of it on Azure IoT Edge and possibly on Azure Sphere, but the later remains to be confirmed.