Hacker News new | past | comments | ask | show | jobs | submit login

Congrats to all developers on the release! Here's a selection of some of my personal favorite changes in this release cycle:

* Automatically-generated nightly binaries for all first-tier platforms [1]

* Switching the default hashmap over to Robin Hood hashing [2]

* Turning on native threading by default, in lieu of the green thread runtime [3]

* The removal of conditions in favor of a standardized type for returning I/O results, which will (by default) generate a warning if the result is ignored [4]

* The extension of the lifetimes of temporary values, which should greatly reduce the occasions where you have to assign a name to a temporary result in an effort to please the compiler [5] [6]

And if you're thrown by the idea that version 0.10 follows version 0.9, know that I voted for 0.A (alas). 1.0 is still expected for later this year, though no promises!

Remember, Rust 1.0 is not the milestone when the language is finished, but rather the milestone when backwards-incompatible changes to the language will no longer be made. See the "backcompat-lang" tag on the issue tracker for a list of outstanding blockers. [7]

[1] https://mail.mozilla.org/pipermail/rust-dev/2014-March/00922...

[2] https://github.com/mozilla/rust/pull/12081

[3] https://github.com/mozilla/rust/pull/12833

[4] https://mail.mozilla.org/pipermail/rust-dev/2014-February/00...

[5] http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval...

[6] https://github.com/mozilla/rust/pull/11585

[7] https://github.com/mozilla/rust/issues?direction=asc&labels=...




>* Turning on native threading by default, in lieu of the green thread runtime [3]

Curious about rationale for this. Have details?


The switch was inspired by this mailing list thread back in November: http://thread.gmane.org/gmane.comp.lang.rust.devel/6479


A select quote:

> Memory mapped I/O is also an incredibly important feature for I/O performance, and there's almost no reason to use traditional I/O on 64-bit. However, it's a no-go with M:N scheduling because the page faults block the thread.

This is more or less why Java switched to native threads a decade and a half ago. Although in that case, it was page faults from hitting swap rather than memory-mapped IO. And in both cases, compatibility with existing native code which makes blocking system calls was also a consideration. It's reassuring that Rust is following a path well-worn by other serious languages.

Now it's just a question of waiting for Go and Node to do the same.


Note, be very careful with "mmap is the fastest way to do IO". That's not true 90% of the time. mmap is the fastest way to do IO when the OS already has file contents in memory and it's more than a few pages so setup of mmap() call is cheaper than memcopying data from kernel space. However mmap is terrible for cold IO. The problem is that mmap is IO-by-sideeffect-of-pagefaults. One has to use madvise() very carefully to make sure that the OS reads useful parts of a file during a pagefault. mmap style of IO is also susceptible to access-pattern bugs, eg even the Linux toolchain gets it deadly wrong and ends up doing IO backwards: https://blog.mozilla.org/tglek/2010/05/27/startup-backward-c....

mmap is even worse on Windows. Windows has no madvise(), OSX equivalent is pathetic. OSX and Windows read mmaped files in bizzarely small chunks, etc.

mmap has the worst error-handling semantics of all IO methods. Linux gives you a super-hard-to-wrap SIGBUS, Windows forces use of slightly-less-horrific SEH http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...


Google has been pushing for performance improvements in native threads for a similar reason. If that's successful, I think the plan is for Go to switch too, but I can't find any links about it atm.


https://www.youtube.com/watch?v=KXuZi9aeGTw

That might be the talk you are thinking about. I am keeping an eye on this. If we can have our cake and eat too w.r.t green threads and performance I will be very happy.


And this is not an issue with Erlang?


Your [5] is broken. Looks like it should be http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval....




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: