17 ms·

Rust, an Anti-Sloppy Programming Language

325 points by arthurtw 12y ago

krilnon 12y ago
The author's term "anti-sloppy programming" immediately brought to mind a former colleague's paper, aptly-titled "Sloppy Programming" [1]. Interestingly, Rust is a programming language, while this paper describes an editor/IDE enhancement to turn natural language style input into ASTs. This suggests to me that the most anti-sloppy languages like Rust would benefit the most from sloppy input inference techniques. Has anyone been working on developer tools to make writing Rust code easier? (Lifetime management is the obvious new language feature to target.) [1] http://groups.csail.mit.edu/uid/other-pubs/sloppy-programming.pdf http://groups.csail.mit.edu/uid/other-pubs/sloppy-programmin... (pdf), or less-detailed: http://groups.csail.mit.edu/uid/projects/keyword-commands/index.html http://groups.csail.mit.edu/uid/projects/keyword-commands/in...
- portmanteaufu 12y ago
  > (Lifetime management is the obvious new language feature to target.) If you haven't toyed with Rust since late summer when Lifetime elision[1] landed, it's very worth revisiting. That feature made writing out lifetime notations unnecessary in 87% of the standard library. It's made things a lot more pleasant. There's still plenty of room for IDEs and editors to help out, of course, but the language itself is making great strides in usability as it matures. [1] https://github.com/rust-lang/rfcs/blob/704f0060176418659698eb63642e2071b109e029/active/0000-lifetime-elision.md https://github.com/rust-lang/rfcs/blob/704f0060176418659698e...
  - krilnon 12y ago
    Ah, great; thanks for pointing out that it has changed. The last time I looked at Rust in detail was mid-April, so I hadn't seen that.
    - wycats 12y ago
      As someone who wrote a lot of code not in the standard library, I championed this RFC pretty heavily. Part of the reason is that I noticed that with the lifetime elision rules, code using abstractions (as opposed to the implementation of abstractions) tends to use even fewer lifetime annotations. Incidentally, the 87% number is a bit misleading. Before the Lifetime Elision RFC, a limited kind of elision was already allowed (when a function borrowed a value but didn't return a borrowed value). The 87% number was the number of lifetime annotations that were still required even with that limited rule that could be removed with the new rule. When taking all kinds of elision into consideration, the number in the standard library is closer to 95%. (many of the remaining cases in the standard library involve the implementation of collections) In practice, that means that the vast, vast majority of borrowed references don't require explicit lifetime annotations, and that is pretty close to 100% in "application" code built on top of abstractions.
- seanmcdirmid 12y ago
  Greg Little's work is usually in PL HCI, which is concerned primarily with languages that improve on usability, accessibility, lowering barriers for the common folk, and such. The other approach is to force one to eat their vegetables (because they are good for you), so to speak; we also call these bondage and discipline languages. Generally, languages of the latter style don't focus on tooling so much, since the accompanying culture is more of the style of "think heavily before you write anything" rather than "fool around in your IDE for awhile to find something that works." They often don't consider the IDE or IDE-related issues as an integral part of the language design. I'm not sure if anyone has done much work to narrow this divide. There are some COQ IDEs out there now, but I'm not sure how effective they are in relieving cognitive burdens while programming.
  - krilnon 12y ago
    You're right to point out the cultural divide w.r.t. tooling. It just seems to me that when two different people come up with pretty identical names for something and focus an essay/paper on that name, then there's likely an opportunity for some sort of cross-pollination of ideas.
    - seanmcdirmid 12y ago
      One person's vice is another person's virtue; I'm not sure how that would create opportunities for collaboration :) The irony of the situation is that languages like Rust and Haskell provide a lot of static type feedback that theoretically would make their IDEs very powerful. However, in order for that to really happen, IDE concerns have to be considered very early in the language design process. As a result, we see the tooling crowns going to languages like Dart, whose "type system" is basically designed to make tooling possible (and secondly, for the early detection of errors).
      - larsberg 12y ago
        Nick Cameron's been gathering some requirements about what would have to happen to enable tooling support: https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c I tried to revive as much information as I could from my days in Visual Studio, but if you have additional feedback, I'm sure he'd be very interested to hear it! Obvious caveats about it being a long-term goal, no immediate plans to tackle it, larsberg is on Servo so what does he know, etc. :-)
alfiedotwtf 12y ago
I haven't touched C or C++ in over 10 years as I've been living like a free spirit in the Perl world. I've always wanted to go closer to the metal, but Perl did everything I ever wanted. But I slowly started to feel that dynamic languages had kind of boxed me in, almost making me timid of memory management and handling resource allocation. So I wanted to go deeper. I played with Go for a while, but kept an eye on Rust. However over the past couple of months, Rust just felt like they got it right. It made me care free about resources just like how Perl took care of everything, while being a strongly typed, static language with generics, and without the problems that might get in my way that Go has (GC and a heavy runtime). If you still haven't had a look but are interested, take a look at the Rust Guide: http://doc.rust-lang.org/guide.html http://doc.rust-lang.org/guide.html
- geofft 12y ago
  "Rust" was an interesting but slightly confusing language a year-ish ago, when it had chans and tasks and libuv and M:N threading and three kinds of pointers with their own funny symbol. That language, as far as I can tell, basically stopped existing (for lots of small good reasons that added up). Rust 1.0 will be an interesting head-on competitor to C/C++ without the awfulness of C/C++, which seems like a very different thing, and a thing I personally have more of a use case for. I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.
  - mietek 12y ago
    > I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story Not really. Here’s an example of writing shared libraries for C in Haskell: https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example
marianov 12y ago
Does Rust have anything like Python generators or coroutines? I don't even know if its possible on a strongly typed laguage, but it's a killer feature form me.
- wycats 12y ago
  I would be very surprised if something like C# and ES7's `async/await` syntax doesn't land in Rust after 1.0.
  - jpgvm 12y ago
    It can be difficult to implement well on nix systems. async/await works so well in C# because IOCP in Windows is completion based. I/O on current nix OSes is readiness based (epool/kqueue). I implemented a completion based wrapper ontop of libev and libaio in C but could never quite nail it. It's worth mentioning that IOCP can be used on any fd in Windows, whereas Linux epoll loop can only be used for sockets. There is a caveat to that however, you can use the epoll loop if you use eventfd with some effectively undocumented behavior of the aio subsystem that allows you to register an eventfd with your aio context. There are drawbacks to this though, you have to use O_DIRECT and aligned writes. In Windows you can use IOCP to do async buffered writes... Thankfully much smarter people work on Rust and hopefully they manage to make a completion based IO system that is portable across the operating systems.
    - ufo 12y ago
      I don't see why the IO model would be a fundamental issue here. Fundamentally, async/await is about automating inversion of control, which is a mechanical program transformation.
      - politician 12y ago
        The parents are saying that a transformation target that supports IOCP is easier to support than one that supports epoll. Think about this the way that you might think about GCC backends -- some architectures make certain things easier than others. Or how an abstraction layer like MonoGame papers over the fundamental differences between OpenGL and DirectX -- some abstractions perform better with one or the other subsystem.
pdq 12y ago
The quickest comparison I'd say between choosing Rust and Go is: - if you like C or Python, you will probably prefer Go - if you like C++ with templates or D or Ruby (especially Rails), you will probably prefer Rust We will see how the languages evolve, but so far I really enjoy Go having native channels, having a stable language definition, and a simple yet stable and powerful standard language API. Also the public/private access system based on capitalization is genius, and the package management is very intuitive.
- imanaccount247 12y ago
  These "if you like Foo you will like Bar" claims are really silly. I've never seen one that was accurate at all, and I don't think they can be. Different people like the same things for different reasons. For example, I like C and despise go, and I despise C++ and ruby, and like rust.
- picardo 12y ago
  Can you elaborate on why you group Rust and Ruby together, and group Go with Python?
  - panzi 12y ago
    I would like to know that as well. The strictness and cleanliness of Rust reminds me more of Python than of Ruby. Not to say that Go is messy or anything, Ruby on the other hand...
- woah 12y ago
  What if you like js?
  - jerf 12y ago
    Go will be a shorter journey from JS. Rust may someday be a better complement, partially for the exact same reason that it's more distant from JS, but Go's 1.0+ today and production ready, whereas Rust is still a ways away from that, so consider your target timescales, too.
  - 12y ago
aethertap 12y ago
I've been writing a parser generator in rust as a way to learn the language, and it's been a mixed journey of being very impressed, and very frustrated. A large part of my frustration comes from what seems like a negative feedback between algebraic data types and the borrow checker. I often find myself with a piece of code that looks clean and simple, using the Option and Result monads to deal with errors in an elegant way, but then I can't compile it because of issues with borrowing. Ultimately, I usually have to break apart the nice structure that feels natural and reimplement it as either a sequence of match or "if x.is_ok()" statements, which just feels... wrong somehow. It becomes tempting to just punt on the error handling and call unwrap() on everything just to get it working for now, which leads to problems later on. It's so close to being incredibly expressive and great for systems programming, but it isn't quite all the way there (at least for me, at this point). I think that higher-kinded types will probably help a lot with this if they make it into the language, and it's likely that there's a way to get around the errors and get the full benefit from the algebraic data types and monadic functions that I just haven't found yet. The language is enough of a level-up from my C++ days that I'm sure I'll stick to it, even if those things aren't true. I thought this quote from the article really nailed it regarding my recent experience: "Expressiveness or elegance is not a goal of Rust. It’s certainly not bad in this regard, just not as wonderful as you may wish if you care it a lot."
- falcolas 12y ago
  This is my experience as well. I was experimenting with a Rust implementation of the Whisper storage system, and I got completely stymied while trying to wire up the unit tests. While I could freely pass a file handle into multiple functions, I could not do the same with any standard implementatoins of mock read/write object due to the underlying Vector objects implementing the `drop` method, which disallowed re-use of the object (including simply reading the contents after coming out of the function).
  - pcwalton 12y ago
    > I could not do the same with any standard implementatoins of mock read/write object due to the underlying Vector objects implementing the `drop` method, which disallowed re-use of the object (including simply reading the contents after coming out of the function). That was simply the compiler preventing you from using memory after it was freed. It sounds like a case of not calling "clone" to copy the vector, instead of anything relating to nonlexical borrow scopes.
Hypx 12y ago
Since rust is a true systems programming language, without a mandatory GC, I wonder if there will be any serious attempt to build a kernel entirely in Rust? It certainly sounds possible, and I suspect it would quickly be better than any FOSS kernel currently available, given the fact that Rust is so well designed against bad or sloppy code. Perhaps I'm just talking out of my ass here, but it sounds like a good idea.
- imanaccount247 12y ago
  There's already a high performance, formally verified, "FLOSS" microkernel: http://sel4.systems/ http://sel4.systems/ As it turns out, very few people are interested in having software that works.
  - Hypx 12y ago
    I've only briefly heard of that kernel, and I suspect the same is true for many people at HN. It's also been open sourced pretty recently so maybe it needs more time for people to become aware of it. It may catch on if we give it more time. But even so, it's still mostly written in C and likely have many of the same pitfalls that all kernels written in C will have. I was thinking of a kernel written entirely in Rust, and that would be not only much more reliable, because it would have far fewer segfaults and the like, plus be more immune to the types of highly publicized security flaws lately (Heartbleed, etc.). Of course, the whole OS might have to be written in Rust + memory safe languages. So we might be a ways off from the ideal goal, but clear I was thinking that we can start with a Rust kernel and build on top of that.
    - nullc 12y ago
      SEL4 is provably free of segfaults, without any runtime overhead at all. Unlike Rust. Though it took considerable development time overhead to achieve that. (Moreover, rust itself may have bugs, or there could be bugs in unsafe code in the standard library. The amount of trusted infrastructure is much smaller for SEL4, I suppose if you compile it with compcert, I imagine it's quite small) The worst case latency is also part of the proof for SEL4-- which is a kind of correctness you cannot achieve via rust (even ignoring overhead). There are many elements of program correctness beyond memory safety. The developers of rust generally eschewed concerns about other kinds of correctness. For example, your integer types may overflow and your algorithms could fail to work as a result. SEL4's proofs show the operation of the software match its specifications completely (given some assumptions), it's really far far beyond the memory safety promises of rust.
cobookman 12y ago
I've been wanting to mess with Rust for webapps. But I've been wondering on how it performs with a lot of async operations. Is the idea that you write CPU heavy code in Rust then call the compiled blob in say a node.js app, or is the end goal to one day compete with node.js?
- kibwen 12y ago
  Async I/O is still an open question in Rust. Over the next year I expect third-party libraries to experiment heavily in this space, which will hopefully blaze a trail for a blessed solution to be uplifted into the stdlib at some point (or if not a complete solution, at least the infrastructure to make it reasonable).
markbao 12y ago
Did anyone else find Rust's package/module management kind of, well, sloppy? Perhaps coming from Rubygems and `go get` has made me spoiled. (And npm, and Cocoapods, and pip...)
- dbaupp 12y ago
  Have you used cargo and crates.io? It is effectively the systems-language successor of Ruby's bundler (designed and (initially) built by the same people), but also paying attention to lessons learnt in npm and Go etc.
  - markbao 12y ago
    Yes, that's what I used—however, I just realized I may have been conflating the difficulty of doing package management in Rust with some packages that I used that were enormously difficult to use or were outdated (speaks to the pre-1.0 thing, I suppose).
- kibwen 12y ago
  Can you be more specific? Cargo was designed and implemented by domain experts (the folks behind Bundler), and I haven't personally felt any longing for any other ecosystem's package manager.
  - MBlume 12y ago
    I think I probably don't understand the Cargo Way yet? Here's a thing that always confuses me -- is there a way to specify a rust version that my project intends to target in my Cargo.toml, or am I stuck with a global rust install?
    - thristian 12y ago
      In the current scenario, where the definition of 'Rust' changes on a daily basis, that's a major pain-point, but once Rust hits 1.0 then all future changes will be backwards-compatible (until version 2.0, in the distant future if ever), so it should be much less of an issue. That said, it's definitely a thing the Cargo devs are thinking about: https://github.com/rust-lang/cargo/issues/1044 https://github.com/rust-lang/cargo/issues/1044 https://github.com/rust-lang/cargo/issues/837 https://github.com/rust-lang/cargo/issues/837
Animats 12y ago
A big problem with Rust right now is that the documentation is awful. This has two implications. The less important one is that the language is harder to learn. The more important one is that there's no architectural document that prevents Rust from becoming a collection of features in search of an architecture. If you have to clearly explain in writing how something works, and the explanation is overly complex, that's an indication that simplifying the design may be necessary. The basic concept of ownership in Rust is simple. Everything has either a single owner, or a reference counted cell as owner. Things which cross thread boundaries have a locked reference counted cell as owner. Temporary references to single-owner objects are allowed, but must have a shorter lifetime than the primary ownership, and this must be demonstrated by simple static analysis. That's straightforward. Making those restrictions usable seems to require many features and much churn within the language. It's too soon to tell how this will come out. As I'm mentioned before, I'm bothered by the need for "unsafe" code in pure Rust that's not calling hardware or C code.
- ossreality 12y ago
  >A big problem with Rust right now is that the documentation is awful. Wha? Steve has been putting a ton of effort into it and it shows... When is the last time you looked? If you're one of these people that wants to announce your opinion in every thread and remind us that you've said them before, it would be worthwhile to keep up with the evolving language. How you can understand Rust's lifetime tracking requirements and not understand why "unsafe" is needed... Just grep through std lib for usages of "unsafe" and see why it's needed.
- MichaelGG 12y ago
  What Rust code needs to be unsafe, other than the sharing primitives? Rust has really come together well over the past year, and no doubt with 1.0 providing a serious release, a lot of gaps will get filled in. That said, I've found it pretty easy to get running with Rust, and the IRC channel is one of the best I've been in.
  - kzrdude 12y ago
    This code from BinaryHeap doesn't need unsafe, but it gladly uses it for performance. The comment in the code explains it. http://doc.rust-lang.org/src/collections/binary_heap.rs.html#501-544 http://doc.rust-lang.org/src/collections/binary_heap.rs.html...
dbaupp 12y ago
One thing the dynamic language (and Go, to some extent) comparison misses is speed: in general, Rust code is likely to be faster to execute than the equivalent Perl/Python/Ruby/Go, due to performance being a strong design choice of the language, and the use of the industrial strength LLVM optimiser. This is a general statement, it's not always true; but the control Rust provides theoretically means one can always wrangle the Rust code to be equal to/faster than most other languages. (In fact, the embeddability of Rust means it is pretty well suited to writing the parts of a Python/etc application that need performance, since Rust can easily make dynamic libraries which can be loaded as extension modules.)
jokoon 12y ago
any valuable starting tutorial for c/c++ programmers ?
- Animats 12y ago
  https://github.com/rust-lang/rust/wiki/Rust-for-CXX-programmers https://github.com/rust-lang/rust/wiki/Rust-for-CXX-programm... There's also http://featherweightmusings.blogspot.com/2014/04/rust-for-c-programmers-part-1-hello.html http://featherweightmusings.blogspot.com/2014/04/rust-for-c-... which is longer, but not as useful. Rust has roughly the feature set and memory model of C++. The difference is that in Rust, the safety issues C++ sweeps under the rug are addressed. As I point out occasionally, the three big problems in C/C++ are "who owns it", "how big it it", and "who locks it". C fails to deal with any of those issues. C++ sometimes deals with "how big is it". Rust deals with all of them. In Rust you have to deal with most of the memory management headaches you have in C++, but they're detected at compile time, not after the product ships.
  - tonfa 12y ago
    How likely is it that a future version of c++ would tackle this issues?
    - steveklabnik 12y ago
      It's impossible to address 100% in C++ without breaking backwards compatibility. "Modern C++" is significantly more safe, but still isn't completely safe.
    - Animats 12y ago
      Very unlikely. I tried, a decade ago, to get the C++ standards committee interested in safety issues. They were fixated on new template features. I once suggested, around 2002, when there was much public worry about attacks, that failure to address the safety issues in C++ constituted material support of terrorism. That really upset some people on the C++ committee. In retrospect...
EdiX 12y ago
Rust is probably the best programming language I will never use. Most of the chances I get to experiment with new languages is in small and/or personal projects. None of those projects ever benefit from manual memory management so the main selling point of Rust (safe memory management without GC) is actually just a hindrance.
- kbart 12y ago
  I'm sure Rust will be adapted to various boards for enthusiasts as soon as stable version appears and it will be suitable for small personal projects. There even have been some tries[1] and Zinc still looks pretty active[2]. 1. https://news.ycombinator.com/item?id=8035293 https://news.ycombinator.com/item?id=8035293 2. https://github.com/hackndev/zinc/graphs/commit-activity https://github.com/hackndev/zinc/graphs/commit-activity
amelius 12y ago
Can anybody explain in simple terms how Rust can manage cycled memory, without a garbage collector?
- kzrdude 12y ago
  You'll have to work hard to manage to create a cycle in the first place, regular ownership through a value or a Box<T> will not allow it. You can create cycles (that need to be broken manually) with the reference counted smart pointer Rc<T>, or you use its weak pointers to resolve it automatically. Oh, and datastructures that need cycles (the libstd's doubly linked list, for example), can use raw pointers to manage it manually, encapsulated in the implementation.
musername 12y ago
Since the ownership system and borrow checker are tuted as new, wouldn't a few papers been appropriate? Sure would be fit to document development outside of the community.
- steveklabnik 12y ago
  https://github.com/rust-lang/rust/wiki/Note-research https://github.com/rust-lang/rust/wiki/Note-research (There is also at least one recent paper on Rust which is t linked here.)
maugzoide 12y ago
Good post. I haven't coded C++ for like 3 years so Rust is a very new concept to me (I am a Python programmer). This weekend I spent some hours to build a hangman game: https://github.com/mauricioabreu/hangman https://github.com/mauricioabreu/hangman
abiox 12y ago
i just want to know if i can call a web json api with the stdlib :(
- steveklabnik 12y ago
  HTTP client / server is out of scope for the stdlib. Just add one line to your Cargo.toml and you're good to go, though.

325 points by arthurtw 12y ago

The author's term "anti-sloppy programming" immediately brought to mind a former colleague's paper, aptly-titled "Sloppy Programming" [1]. Interestingly, Rust is a programming language, while this paper describes an editor/IDE enhancement to turn natural language style input into ASTs. This suggests to me that the most anti-sloppy languages like Rust would benefit the most from sloppy input inference techniques. Has anyone been working on developer tools to make writing Rust code easier? (Lifetime management is the obvious new language feature to target.) [1] http://groups.csail.mit.edu/uid/other-pubs/sloppy-programming.pdf http://groups.csail.mit.edu/uid/other-pubs/sloppy-programmin... (pdf), or less-detailed: http://groups.csail.mit.edu/uid/projects/keyword-commands/index.html http://groups.csail.mit.edu/uid/projects/keyword-commands/in...

portmanteaufu 12y ago
> (Lifetime management is the obvious new language feature to target.) If you haven't toyed with Rust since late summer when Lifetime elision[1] landed, it's very worth revisiting. That feature made writing out lifetime notations unnecessary in 87% of the standard library. It's made things a lot more pleasant. There's still plenty of room for IDEs and editors to help out, of course, but the language itself is making great strides in usability as it matures. [1] https://github.com/rust-lang/rfcs/blob/704f0060176418659698eb63642e2071b109e029/active/0000-lifetime-elision.md https://github.com/rust-lang/rfcs/blob/704f0060176418659698e...
- krilnon 12y ago
  Ah, great; thanks for pointing out that it has changed. The last time I looked at Rust in detail was mid-April, so I hadn't seen that.
  - wycats 12y ago
    As someone who wrote a lot of code not in the standard library, I championed this RFC pretty heavily. Part of the reason is that I noticed that with the lifetime elision rules, code using abstractions (as opposed to the implementation of abstractions) tends to use even fewer lifetime annotations. Incidentally, the 87% number is a bit misleading. Before the Lifetime Elision RFC, a limited kind of elision was already allowed (when a function borrowed a value but didn't return a borrowed value). The 87% number was the number of lifetime annotations that were still required even with that limited rule that could be removed with the new rule. When taking all kinds of elision into consideration, the number in the standard library is closer to 95%. (many of the remaining cases in the standard library involve the implementation of collections) In practice, that means that the vast, vast majority of borrowed references don't require explicit lifetime annotations, and that is pretty close to 100% in "application" code built on top of abstractions.
seanmcdirmid 12y ago
Greg Little's work is usually in PL HCI, which is concerned primarily with languages that improve on usability, accessibility, lowering barriers for the common folk, and such. The other approach is to force one to eat their vegetables (because they are good for you), so to speak; we also call these bondage and discipline languages. Generally, languages of the latter style don't focus on tooling so much, since the accompanying culture is more of the style of "think heavily before you write anything" rather than "fool around in your IDE for awhile to find something that works." They often don't consider the IDE or IDE-related issues as an integral part of the language design. I'm not sure if anyone has done much work to narrow this divide. There are some COQ IDEs out there now, but I'm not sure how effective they are in relieving cognitive burdens while programming.
- krilnon 12y ago
  You're right to point out the cultural divide w.r.t. tooling. It just seems to me that when two different people come up with pretty identical names for something and focus an essay/paper on that name, then there's likely an opportunity for some sort of cross-pollination of ideas.
  - seanmcdirmid 12y ago
    One person's vice is another person's virtue; I'm not sure how that would create opportunities for collaboration :) The irony of the situation is that languages like Rust and Haskell provide a lot of static type feedback that theoretically would make their IDEs very powerful. However, in order for that to really happen, IDE concerns have to be considered very early in the language design process. As a result, we see the tooling crowns going to languages like Dart, whose "type system" is basically designed to make tooling possible (and secondly, for the early detection of errors).
    - larsberg 12y ago
      Nick Cameron's been gathering some requirements about what would have to happen to enable tooling support: https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c https://gist.github.com/nick29581/a3bbf6dd1b14ce57f18c I tried to revive as much information as I could from my days in Visual Studio, but if you have additional feedback, I'm sure he'd be very interested to hear it! Obvious caveats about it being a long-term goal, no immediate plans to tackle it, larsberg is on Servo so what does he know, etc. :-)

alfiedotwtf 12y ago

I haven't touched C or C++ in over 10 years as I've been living like a free spirit in the Perl world. I've always wanted to go closer to the metal, but Perl did everything I ever wanted. But I slowly started to feel that dynamic languages had kind of boxed me in, almost making me timid of memory management and handling resource allocation. So I wanted to go deeper. I played with Go for a while, but kept an eye on Rust. However over the past couple of months, Rust just felt like they got it right. It made me care free about resources just like how Perl took care of everything, while being a strongly typed, static language with generics, and without the problems that might get in my way that Go has (GC and a heavy runtime). If you still haven't had a look but are interested, take a look at the Rust Guide: http://doc.rust-lang.org/guide.html http://doc.rust-lang.org/guide.html

geofft 12y ago
"Rust" was an interesting but slightly confusing language a year-ish ago, when it had chans and tasks and libuv and M:N threading and three kinds of pointers with their own funny symbol. That language, as far as I can tell, basically stopped existing (for lots of small good reasons that added up). Rust 1.0 will be an interesting head-on competitor to C/C++ without the awfulness of C/C++, which seems like a very different thing, and a thing I personally have more of a use case for. I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.
- mietek 12y ago
  > I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story Not really. Here’s an example of writing shared libraries for C in Haskell: https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example

marianov 12y ago

Does Rust have anything like Python generators or coroutines? I don't even know if its possible on a strongly typed laguage, but it's a killer feature form me.

wycats 12y ago
I would be very surprised if something like C# and ES7's `async/await` syntax doesn't land in Rust after 1.0.
- jpgvm 12y ago
  It can be difficult to implement well on nix systems. async/await works so well in C# because IOCP in Windows is completion based. I/O on current nix OSes is readiness based (epool/kqueue). I implemented a completion based wrapper ontop of libev and libaio in C but could never quite nail it. It's worth mentioning that IOCP can be used on any fd in Windows, whereas Linux epoll loop can only be used for sockets. There is a caveat to that however, you can use the epoll loop if you use eventfd with some effectively undocumented behavior of the aio subsystem that allows you to register an eventfd with your aio context. There are drawbacks to this though, you have to use O_DIRECT and aligned writes. In Windows you can use IOCP to do async buffered writes... Thankfully much smarter people work on Rust and hopefully they manage to make a completion based IO system that is portable across the operating systems.
  - ufo 12y ago
    I don't see why the IO model would be a fundamental issue here. Fundamentally, async/await is about automating inversion of control, which is a mechanical program transformation.
    - politician 12y ago
      The parents are saying that a transformation target that supports IOCP is easier to support than one that supports epoll. Think about this the way that you might think about GCC backends -- some architectures make certain things easier than others. Or how an abstraction layer like MonoGame papers over the fundamental differences between OpenGL and DirectX -- some abstractions perform better with one or the other subsystem.

pdq 12y ago

The quickest comparison I'd say between choosing Rust and Go is: - if you like C or Python, you will probably prefer Go - if you like C++ with templates or D or Ruby (especially Rails), you will probably prefer Rust We will see how the languages evolve, but so far I really enjoy Go having native channels, having a stable language definition, and a simple yet stable and powerful standard language API. Also the public/private access system based on capitalization is genius, and the package management is very intuitive.

imanaccount247 12y ago
These "if you like Foo you will like Bar" claims are really silly. I've never seen one that was accurate at all, and I don't think they can be. Different people like the same things for different reasons. For example, I like C and despise go, and I despise C++ and ruby, and like rust.
picardo 12y ago
Can you elaborate on why you group Rust and Ruby together, and group Go with Python?
- panzi 12y ago
  I would like to know that as well. The strictness and cleanliness of Rust reminds me more of Python than of Ruby. Not to say that Go is messy or anything, Ruby on the other hand...
woah 12y ago
What if you like js?
- jerf 12y ago
  Go will be a shorter journey from JS. Rust may someday be a better complement, partially for the exact same reason that it's more distant from JS, but Go's 1.0+ today and production ready, whereas Rust is still a ways away from that, so consider your target timescales, too.
- 12y ago

aethertap 12y ago

I've been writing a parser generator in rust as a way to learn the language, and it's been a mixed journey of being very impressed, and very frustrated. A large part of my frustration comes from what seems like a negative feedback between algebraic data types and the borrow checker. I often find myself with a piece of code that looks clean and simple, using the Option and Result monads to deal with errors in an elegant way, but then I can't compile it because of issues with borrowing. Ultimately, I usually have to break apart the nice structure that feels natural and reimplement it as either a sequence of match or "if x.is_ok()" statements, which just feels... wrong somehow. It becomes tempting to just punt on the error handling and call unwrap() on everything just to get it working for now, which leads to problems later on. It's so close to being incredibly expressive and great for systems programming, but it isn't quite all the way there (at least for me, at this point). I think that higher-kinded types will probably help a lot with this if they make it into the language, and it's likely that there's a way to get around the errors and get the full benefit from the algebraic data types and monadic functions that I just haven't found yet. The language is enough of a level-up from my C++ days that I'm sure I'll stick to it, even if those things aren't true. I thought this quote from the article really nailed it regarding my recent experience: "Expressiveness or elegance is not a goal of Rust. It’s certainly not bad in this regard, just not as wonderful as you may wish if you care it a lot."

falcolas 12y ago
This is my experience as well. I was experimenting with a Rust implementation of the Whisper storage system, and I got completely stymied while trying to wire up the unit tests. While I could freely pass a file handle into multiple functions, I could not do the same with any standard implementatoins of mock read/write object due to the underlying Vector objects implementing the `drop` method, which disallowed re-use of the object (including simply reading the contents after coming out of the function).
- pcwalton 12y ago
  > I could not do the same with any standard implementatoins of mock read/write object due to the underlying Vector objects implementing the `drop` method, which disallowed re-use of the object (including simply reading the contents after coming out of the function). That was simply the compiler preventing you from using memory after it was freed. It sounds like a case of not calling "clone" to copy the vector, instead of anything relating to nonlexical borrow scopes.

Hypx 12y ago

Since rust is a true systems programming language, without a mandatory GC, I wonder if there will be any serious attempt to build a kernel entirely in Rust? It certainly sounds possible, and I suspect it would quickly be better than any FOSS kernel currently available, given the fact that Rust is so well designed against bad or sloppy code. Perhaps I'm just talking out of my ass here, but it sounds like a good idea.

imanaccount247 12y ago
There's already a high performance, formally verified, "FLOSS" microkernel: http://sel4.systems/ http://sel4.systems/ As it turns out, very few people are interested in having software that works.
- Hypx 12y ago
  I've only briefly heard of that kernel, and I suspect the same is true for many people at HN. It's also been open sourced pretty recently so maybe it needs more time for people to become aware of it. It may catch on if we give it more time. But even so, it's still mostly written in C and likely have many of the same pitfalls that all kernels written in C will have. I was thinking of a kernel written entirely in Rust, and that would be not only much more reliable, because it would have far fewer segfaults and the like, plus be more immune to the types of highly publicized security flaws lately (Heartbleed, etc.). Of course, the whole OS might have to be written in Rust + memory safe languages. So we might be a ways off from the ideal goal, but clear I was thinking that we can start with a Rust kernel and build on top of that.
  - nullc 12y ago
    SEL4 is provably free of segfaults, without any runtime overhead at all. Unlike Rust. Though it took considerable development time overhead to achieve that. (Moreover, rust itself may have bugs, or there could be bugs in unsafe code in the standard library. The amount of trusted infrastructure is much smaller for SEL4, I suppose if you compile it with compcert, I imagine it's quite small) The worst case latency is also part of the proof for SEL4-- which is a kind of correctness you cannot achieve via rust (even ignoring overhead). There are many elements of program correctness beyond memory safety. The developers of rust generally eschewed concerns about other kinds of correctness. For example, your integer types may overflow and your algorithms could fail to work as a result. SEL4's proofs show the operation of the software match its specifications completely (given some assumptions), it's really far far beyond the memory safety promises of rust.

cobookman 12y ago

I've been wanting to mess with Rust for webapps. But I've been wondering on how it performs with a lot of async operations. Is the idea that you write CPU heavy code in Rust then call the compiled blob in say a node.js app, or is the end goal to one day compete with node.js?

kibwen 12y ago
Async I/O is still an open question in Rust. Over the next year I expect third-party libraries to experiment heavily in this space, which will hopefully blaze a trail for a blessed solution to be uplifted into the stdlib at some point (or if not a complete solution, at least the infrastructure to make it reasonable).

markbao 12y ago

Did anyone else find Rust's package/module management kind of, well, sloppy? Perhaps coming from Rubygems and `go get` has made me spoiled. (And npm, and Cocoapods, and pip...)

dbaupp 12y ago
Have you used cargo and crates.io? It is effectively the systems-language successor of Ruby's bundler (designed and (initially) built by the same people), but also paying attention to lessons learnt in npm and Go etc.
- markbao 12y ago
  Yes, that's what I used—however, I just realized I may have been conflating the difficulty of doing package management in Rust with some packages that I used that were enormously difficult to use or were outdated (speaks to the pre-1.0 thing, I suppose).
kibwen 12y ago
Can you be more specific? Cargo was designed and implemented by domain experts (the folks behind Bundler), and I haven't personally felt any longing for any other ecosystem's package manager.
- MBlume 12y ago
  I think I probably don't understand the Cargo Way yet? Here's a thing that always confuses me -- is there a way to specify a rust version that my project intends to target in my Cargo.toml, or am I stuck with a global rust install?
  - thristian 12y ago
    In the current scenario, where the definition of 'Rust' changes on a daily basis, that's a major pain-point, but once Rust hits 1.0 then all future changes will be backwards-compatible (until version 2.0, in the distant future if ever), so it should be much less of an issue. That said, it's definitely a thing the Cargo devs are thinking about: https://github.com/rust-lang/cargo/issues/1044 https://github.com/rust-lang/cargo/issues/1044 https://github.com/rust-lang/cargo/issues/837 https://github.com/rust-lang/cargo/issues/837

Animats 12y ago

A big problem with Rust right now is that the documentation is awful. This has two implications. The less important one is that the language is harder to learn. The more important one is that there's no architectural document that prevents Rust from becoming a collection of features in search of an architecture. If you have to clearly explain in writing how something works, and the explanation is overly complex, that's an indication that simplifying the design may be necessary. The basic concept of ownership in Rust is simple. Everything has either a single owner, or a reference counted cell as owner. Things which cross thread boundaries have a locked reference counted cell as owner. Temporary references to single-owner objects are allowed, but must have a shorter lifetime than the primary ownership, and this must be demonstrated by simple static analysis. That's straightforward. Making those restrictions usable seems to require many features and much churn within the language. It's too soon to tell how this will come out. As I'm mentioned before, I'm bothered by the need for "unsafe" code in pure Rust that's not calling hardware or C code.

ossreality 12y ago
>A big problem with Rust right now is that the documentation is awful. Wha? Steve has been putting a ton of effort into it and it shows... When is the last time you looked? If you're one of these people that wants to announce your opinion in every thread and remind us that you've said them before, it would be worthwhile to keep up with the evolving language. How you can understand Rust's lifetime tracking requirements and not understand why "unsafe" is needed... Just grep through std lib for usages of "unsafe" and see why it's needed.
MichaelGG 12y ago
What Rust code needs to be unsafe, other than the sharing primitives? Rust has really come together well over the past year, and no doubt with 1.0 providing a serious release, a lot of gaps will get filled in. That said, I've found it pretty easy to get running with Rust, and the IRC channel is one of the best I've been in.
- kzrdude 12y ago
  This code from BinaryHeap doesn't need unsafe, but it gladly uses it for performance. The comment in the code explains it. http://doc.rust-lang.org/src/collections/binary_heap.rs.html#501-544 http://doc.rust-lang.org/src/collections/binary_heap.rs.html...

dbaupp 12y ago

One thing the dynamic language (and Go, to some extent) comparison misses is speed: in general, Rust code is likely to be faster to execute than the equivalent Perl/Python/Ruby/Go, due to performance being a strong design choice of the language, and the use of the industrial strength LLVM optimiser. This is a general statement, it's not always true; but the control Rust provides theoretically means one can always wrangle the Rust code to be equal to/faster than most other languages. (In fact, the embeddability of Rust means it is pretty well suited to writing the parts of a Python/etc application that need performance, since Rust can easily make dynamic libraries which can be loaded as extension modules.)

jokoon 12y ago

any valuable starting tutorial for c/c++ programmers ?

Animats 12y ago
https://github.com/rust-lang/rust/wiki/Rust-for-CXX-programmers https://github.com/rust-lang/rust/wiki/Rust-for-CXX-programm... There's also http://featherweightmusings.blogspot.com/2014/04/rust-for-c-programmers-part-1-hello.html http://featherweightmusings.blogspot.com/2014/04/rust-for-c-... which is longer, but not as useful. Rust has roughly the feature set and memory model of C++. The difference is that in Rust, the safety issues C++ sweeps under the rug are addressed. As I point out occasionally, the three big problems in C/C++ are "who owns it", "how big it it", and "who locks it". C fails to deal with any of those issues. C++ sometimes deals with "how big is it". Rust deals with all of them. In Rust you have to deal with most of the memory management headaches you have in C++, but they're detected at compile time, not after the product ships.
- tonfa 12y ago
  How likely is it that a future version of c++ would tackle this issues?
  - steveklabnik 12y ago
    It's impossible to address 100% in C++ without breaking backwards compatibility. "Modern C++" is significantly more safe, but still isn't completely safe.
  - Animats 12y ago
    Very unlikely. I tried, a decade ago, to get the C++ standards committee interested in safety issues. They were fixated on new template features. I once suggested, around 2002, when there was much public worry about attacks, that failure to address the safety issues in C++ constituted material support of terrorism. That really upset some people on the C++ committee. In retrospect...

EdiX 12y ago

Rust is probably the best programming language I will never use. Most of the chances I get to experiment with new languages is in small and/or personal projects. None of those projects ever benefit from manual memory management so the main selling point of Rust (safe memory management without GC) is actually just a hindrance.

kbart 12y ago
I'm sure Rust will be adapted to various boards for enthusiasts as soon as stable version appears and it will be suitable for small personal projects. There even have been some tries[1] and Zinc still looks pretty active[2]. 1. https://news.ycombinator.com/item?id=8035293 https://news.ycombinator.com/item?id=8035293 2. https://github.com/hackndev/zinc/graphs/commit-activity https://github.com/hackndev/zinc/graphs/commit-activity

amelius 12y ago

Can anybody explain in simple terms how Rust can manage cycled memory, without a garbage collector?

kzrdude 12y ago
You'll have to work hard to manage to create a cycle in the first place, regular ownership through a value or a Box<T> will not allow it. You can create cycles (that need to be broken manually) with the reference counted smart pointer Rc<T>, or you use its weak pointers to resolve it automatically. Oh, and datastructures that need cycles (the libstd's doubly linked list, for example), can use raw pointers to manage it manually, encapsulated in the implementation.

musername 12y ago

Since the ownership system and borrow checker are tuted as new, wouldn't a few papers been appropriate? Sure would be fit to document development outside of the community.

steveklabnik 12y ago
https://github.com/rust-lang/rust/wiki/Note-research https://github.com/rust-lang/rust/wiki/Note-research (There is also at least one recent paper on Rust which is t linked here.)

maugzoide 12y ago

Good post. I haven't coded C++ for like 3 years so Rust is a very new concept to me (I am a Python programmer). This weekend I spent some hours to build a hangman game: https://github.com/mauricioabreu/hangman https://github.com/mauricioabreu/hangman

abiox 12y ago

i just want to know if i can call a web json api with the stdlib :(

steveklabnik 12y ago
HTTP client / server is out of scope for the stdlib. Just add one line to your Cargo.toml and you're good to go, though.