I think one thing that we need to emphasize is that Rust 1.0 does not indicate that we think the language is "complete". It is merely the result of recognition that getting to that "complete" state can, as of very soon, be done in a stable and backwards-compatible fashion. I expect the post-1.0 releases to see a flurry of activity as we flesh out deficiencies in existing features and add new features to address pain points, but over time the rate of feature growth will slow. Rust has no intention of becoming a ball-of-mud programming language.
Hi! I'm sure you get asked this a lot, but it wasn't found in a quick skim of the FAQs, so:
How long do you (the Rust community) expect Rust to remain backwards-compatible? That is, once 1.0 ships, on what sort of approximate timescale would significant effort be made to ensure code that worked with the initial release (assuming no experimental features / libraries in use) would keep working? On the order of months, years, decades?
I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0. But given e.g. the prevalence of Python 2 versus Python 3, it seems like there's quite a lot of people who think similarly.
Background: I used to write Firefox extensions and things like that. Stopped being active around Firefox 4, when they declared that they are fine with breaking backwards API compatibility (and, IIRC around that time or soon after, put in arbitrary checks to force recompilation). This was just before the short releases started.
> The hope is for all of 1.. I forget what the plan is for 2.0, but I think we want to keep things the same (mostly).
Right, but how long is that 1.? 2.0 is a good time to have (hopefully small) backwards compatibility breaks, so having a rough idea of an order of magnitude of the timespan would be helpful.
> Expanding the stdlib will never break your code.
But having it obsolete the non-standard libraries (from e.g. crates.io) will. Code is, unfortunately, not static; things suffer from bitrot, as the toolchain etc. changes.
> I'm interested in writing some random things in Rust, but very much not interested in _re_writing Rust code in newer Rust. This probably means it's still too early for me, if the standard library is expected to expand soon after 1.0.
Why would you have to rewrite code because of an expanding std lib?
No one knows, and I don't think there's been (a public) discussion about it by projects leads. The only guarantee is that 1.x will not break anything (according to some definition of "break").
There needs to be more experience with widespread use and multiple releases, to see how far that backcompat can be held. Perhaps after 10 releases, it should be a lot more clear whether or not a Rust 2.0 will be needed.
Thanks; I'm not sure in that case saying 1.x is guaranteed to not break things is very useful at all. Systemd (as far as I know) follows semantic versioning, but their version number is up in the hundreds. Without some sort of guess at how long a release might last, 2.0 might as well ship the minute after 1.0 ships. (Okay, probably not...)
The core team has reserved the right to break backcompat without changing the major version if they find a serious problem in 1.x series. So I expect that it will be a while (at least a few years) before 2.0 is created.
From the proposals: "Perhaps the biggest is the lack of "privacy" or "unsafety" hygiene (meaning that it's not possible to define macros that have privileged access over normal code). This prevents macros from being used to define abstraction barriers."
That may be a misfeature. One would like to reduce the need for unsafe code, not make it easier to write unsafe code. Unless you're talking to hardware or another language, you should not need unsafe code. If you do, the language has a problem. I'd suggest identifying each use of unsafe code in a large system and then looking at why it was necessary.
It's important to keep Rust from going off into template la-la land, as C++ did. C++ generics are starting out with roughly the complexity level it took C++ two decades to achieve. Try to keep the metaprogramming fanatics from driving the language design, please. That doesn't end well.
> Unless you're talking to hardware or another language, you should not need unsafe code.
... or if you're implementing safe abstractions on top of data structures or synchronization protocols that the type system cannot automatically infer to be safe.
Of course that is going to be a smallish subset of Rust programmers that gets smaller with time as the standard library fills out, but an important one!
For those who aren't as familiar with Rust, the std::sync [0] module can be a fun way to cut your teeth.
For example, here's the implementation of Mutex.lock [1]:
Note that the self argument is immutable: "&self" instead of "&mut self". This may seem odd: doesn't locking a mutex require a change to its innards? Which is why you should not be surprised to see the unsafe, which allows us to bend the immutability of &self in order to acquire the lock.
In fact, how could it be otherwise? Rust prevents there ever being more than one &mut to something, so if the signature of Mutex::lock was "&mut self", there could only ever be one usable ref to the Mutex! That would be pointless, of course -- multiple threads need to have references to the mutex.
We're still safe, though, because the "mut-aliasing" that Rust normally prevents via the borrow checker at compile time is being replaced with a run-time mechanism that achieves the same thing via the Mutex and the MutexGuard [2].
Rust's own Aaron Turon put this nicely in a recent talk at Stanford. A data race requires all of the following: aliasing, mutation, and a lack of synchronization. Rust's usual ownership rules already make aliasing exclusive with mutation, so out of the box you're safe. But when simultaneous aliasing and mutation is exactly what you want, as in a mutex, it's safe to subvert the type system as long as you make sure to uphold the synchronization aspect on your own (which Rust nicely helps with by leveraging ownership on the synchronization mechanism itself).
In a sense, what you need there is not "unsafe", but "atomic", declaring that the contained operation is atomic. That's less general than "unsafe", and atomicity of code is checkable.
I'm not sure what Niko Matsakis means by that comment, but I think it is not exactly about the `unsafe { }` block kind of unsafety. Nothing about the macro_rules! system right now stops you from writing an `unsafe { }` block inside a macro_rules! macro.
The wording makes me think that's it's purely about allowing non-hygienic macros[1] in some sensible way. (At least a quick glance at the Rust book/manual suggests that macros are always hygienic in Rust.) Hygiene is a good default, but it does prevent certain other useful uses of macros.
It's the opposite: macros currently leak their internals in certain circumstances with unsafe and privacy/name resolution, i.e. are slightly non hygienic (they are properly hygienic with respect to local variables, which is the major advantage of hygiene). The changes would make macros more hygienic in those aspects.
I really wish better Windows support was available now. Solid cross-platform support has allowed me to move some Python code to go. My attempts to do the same with Rust have been failures, on multiple occasions, but as recently as their 1.0 beta and nightlies (both 32/64 bit were tried).
After giving it a few hours with the IRC channel riding shotgun and hello_world.rs still crashing on Windows, I've again hit snooze of Rust. A pity too... I am quite re-interested after seeing some Rust demos/discussion at PyCon.
Not to be funny, but you've been saying this for years now. Might be time to either give up on windows or accept you're going to have to make your own experts.
Worst-case scenario is that Mozilla lends us some of their Windows experts when it's time to integrate Rust components into Firefox (which uses MSVC) later this year. But that's not a satisfying answer to people who want to develop on Windows today!
"cargo" doesn't work for me on Windows (it crashes). I can compile things with rustc but the executables crash. I've spent a fair bit of time purging/uninstalling stuff, and rerunning the installers or even picking up binaries. No success.
Obviously my system is a hostile environment for it. OTOH it's a pretty ordinary enterprise Win 7 box with plenty of dev tools happily running. I'm sure there is a series of steps to fix it. So one aspect of "Better Windows support" for me means the installer doing a better job at getting things going and complaining about missing things, incompatibilities, etc. I do hope mine in an exceptional case.
I'm guessing that the parent poster was trying to do a "hello world" equivalent of calling Rust from Python (as per the Pycon presentation), which would definitely cause grief on Windows if Python isn't compiled with the same toolchain that Rust is.
Does "ARM support" include bare-metal arm at all? I know there are several projects that move in that direction, but it's not obvious to me how mature they are relative to the rest of Rust (granting that everything in the ecosystem is in an early state)...
Rust exists to support Servo, and Servo's most important platform may very well be Android. I expect that Rust will see a lot of interest by hobbyists who hack the compiler to work with various fringe platforms, but in terms of official support I wouldn't expect Mozilla and Samsung to contribute anything beyond what's required for Android.
I have a vague memory that the Samsung work was partly done by their non-Android Bada OS team, which would make sense as Android is in many ways tied to Webkit/Blink/Chrome.
Now we only need to dependencies for Servo to move along and it could work. I would imagine this would be a lot of work for the OpenGL implementation they use.
I should try building Rust with Mer SDK. Would be useful for Nemo, Sailfish and Plasma Active. Weren't Samsung also working on Servo? Did they consider it for Tizen as well?
I wonder if Rust would support something like the following. Say, I have a mmapped file, and in this file I'd like to store data-structures such as maps, sets, lists, etc. Basically, they are the same data-structures as one would use on the heap. Because the mmapped file is offsetted at a different point in memory every time it is opened, the actual pointers used to access these data-structures will be different every time. But the pointers inside the data-structures will be the same every time the file is mmapped. So, this requires some special pointer arithmetic (and perhaps a special type system). It would definitely be a very interesting and useful feature!
After using Go for a couple of pet projects in the last couple of months, I came out bored. Many people seem to be quite excited about Rust. I'm setting up my (new) Emacs end for Rust.
ATS is more like a safe version of C wrapped in ML syntax vs Rust as a safe version of C++.
ATS is lower level. You can do memory safe pointer arithmetic whereas in Rust you'd use unsafe blocks.
Some things are implicit in Rust but explicit (and more verbose) in ATS. For example, Rust has destructors for RAII whereas ATS requires manually calling functions to clean up resources. The type checker tells you when you need to do this (via linear types) but programmer still needs to do the call.
Borrowing is automatic in Rust. In ATS it requires keeping track of borrows in proof variables and manually giving them back. Again the type checker tells you when you get it wrong but it's more verbosity.
ATS has a restricted form of dependent types - Rust is not dependently typed.
With current implementations, ATS compiles to C which can be compiled independantly of an ATS install. You can ship the C code to someone to build without them needing ATS. Rust uses LLVM.
The two languages feel very differently when programming.
This is awesome, I'm so happy to finally hear from somebody with experience in ATS. :)
> For example, Rust has destructors for RAII whereas ATS
> requires manually calling functions to clean up
> resources.
This especially intrigues me, as recent events have shaken my faith a little in RAII. Who knows, maybe Rust will one day regret not embracing linear types wholeheartedly...
I much prefer explicit over implicit so I'm not a big fan of RAII. I find it hides things that are happening in the code which makes it hard to find performance and other problems from inspection. ATS has tail call optimisation and destructors would make it hard to tell when TCO can't be done due to the hidden destructor calls.
Another nice thing ATS has is the ability to specify the API for a C function to a level of detail that enables removing a whole class of erroneous usage of the C API. I have an example of this where I start with a basic API definition and tighten it up by adding type definitions:
Because there is a battle going on. The lines are being drawn. People who where fighting this battle will see this happening before those who were unaware to start with; however, the lines are now being drawn thanks to Edward Snowden, and this battle is becoming visible to all.
Meaning: GO was dead at birth from out of the sphincter of the NSA.
Rob Pike has been working on Go's design since Newsqueak in the 90s, and further explored the same space later with Limbo. For reference, Newsqueak is a C-inspired language that features CSP for concurrency (which should sound familiar to Go programmers). Here's some example syntax (which should look familiar to Go programmers):
a := mk(array[10] of int)
Given this lineage, it seems disingenuous to compare the ages of the two languages. Modern Rust is to early Rust as Go is to Newsqueak.
Indeed, it may ultimately turn out that modern Rust is to early Rust as Limbo (rather than Go) is to Newsqueak. I expect Rust will experience growing pains over the next few years as people begin employing it on an industrial scale and discover where the dark corners of the language lie. But nobody's saying that Rust will be the last systems programming language to ever be written. :)
This comment is very strange. Go was made public when it was stable (or maybe shortly before?), Rust was made public long before it was.
Rust will be stable in 4 weeks, Go was stable several years ago. So what? If we judged languages by how early they were stable, we would all be writing Fortran 57, Algol 58, and COBOL 60.
The team is emphatically not changing things like crazy. Every week the nightly unstable branch runs against the stable packages on crates.io to automatically smoke out potential stability regressions. Here's last week's:
Two regressions out of 900 packages, and one of those was due to a bug that was fixed (the other was due to a new warning being added, which caused breakage in a package that had opted in to turning all warnings into hard errors; a plan to keep this from happening in the future is being formed at https://github.com/rust-lang/rfcs/issues/1029 ).
For this week, the big breaking change will be the deprecation of thread::scoped due to its API being found unsound. This is exactly the sort of thing that you want to cause breakage for, and does not happen lightly.
I think you have the wrong impression about the recent changes, e.g. a recent "regression report"[1] found only two regressions between nightly and the original released beta. Furthermore, several changes have been rejected due to being breaking. The team is seriously committed to stability.
I also just skimmed the issues page and saw people who are contributors discussing whether a memory leak is classified as unsafe behavior and changing api's based on this. It feels like this sort of thing should be put to rest before you declare any sort of stability.
The notion that memory leaks do not constitute memory unsafety has been the party line for a long time, since last year at least (since we can't prevent memory leaks statically: imagine sending something across a channel to a deadlocked thread (remembering that Rust cannot statically prevent deadlocks in general, only data races)). The disruption this week has been due to a stdlib API that made use of a very specific pattern involving a mix of unsafe code, ownership transfer, and destructors. Previously it was believed that this particular unsafe code could not lead to memory unsafety, but that happens to be untrue when memory leakage is thrown into the mix. As a result of this coming to light people will need to reevaluate unsafe code in destructors in a way that had previously not been considered, which is why there's been a general tizzy about it.
of course, if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way, go isn't ready at all.
it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.
It's ready when people use it in production.And that's the case so it's ready.
> it does have some marquee names behind it,
So does Rust,or are you saying Mozilla isn't a strong brand?
I don't think its fair to compare both anyway.
Rust looks like it wants to compete with C++, while Go is used by scripters coming from Ruby,Python,Js and PHP. Go devs aren't interested in memory unsafe programming.
you skipped the "if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way" part.
> you skipped the "if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way" part.
You skipped the fact that user oldmanjay heavily edited his message, and the current one has little to do with the one I answered too. Not going to edited mine, I quoted his previous message and answered to these specific points.
"go isn't ready at all" is still a substring of the parent comment, so one perfectly valid interpretation is that the quote was taken out of context, especially since HN provides no edit histories or even indication of edits.
> you skipped the "if you're interested in rust's memory safety, performance, low-level control, and expressive type system, then in a very real way" part.
Was not part of the original comment I answered to.
Go performance is going to converge on C performance with new optimization's being written after go 1.5.
Any gains from rusts expressive type system are lost by all the memory lifetime annotations imo.
I still think rust is probably going to be the best language for embedded software like router firmware, as they need to be fast, low overhead and secure.
As an upper performance bound for a GC language, I don't think Go will be able to surpass C# (which has stack allocation in the form of structs, ahead of time compilation, and many other goodies). Rust, on the other hand, has more potential as a non GC language, though at the end of the day it might be hard to tell given equivalent applications.
The upper performance for garbage collected languages (and rust) is potentially higher than C. The reasons are non aliased pointers allow more aggressive optimization, and batched garbage collection plus memory compaction can perform better than regular mallocs.
Rust still has these advantages though, time will tell. Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.
> The reasons are non aliased pointers allow more aggressive optimization
Rust's type system is all about controlling aliasing. But virtually all garbage collected languages, including Go, have much weaker aliasing guarantees than C does. At least C has "restrict".
Granted, if you compile with "-fno-strict-aliasing", a C compiler will have a tougher time of alias analysis, but that isn't strictly C anymore.
In any case, alias analysis here has nothing to do with garbage collection and everything to do with type safety.
> Does rust have a way to avoid bounds checks on arrays? I suppose that requires unsafe annotations.
Rust essentially never wastes cycles on bounds checking thanks to the design of its iterators. The Servo team tells me that bounds checking has never shown up in any performance profiles.
I wonder if after Mozilla writes Servo in Rust 1.x and Google sees how fast Servo is, even compared to its own JS engine, it will also consider writing a new JS engine in Rust 2.x (I assume, by then), as I doubt they'd use Go for that. Same for the whole browsers. Due to the safety features of Rust over C++ we might see both Firefox and Chrome be rewritten in Rust over the next 5 years.
The gist is that an iterator has enough information about the thing that it's iterating over that we, as library authors, can avoid unnecessary bounds checking and just perform unchecked indexing while retaining all the safety. LLVM is also surprisingly good at automatically vectorizing our iterators.
Shows that Go certainly beats Mono #C in these benchmarks (often by a very wide margin).
From a technical standpoint I don't see any reason why Go would not be faster than C#, how would 'ahead of time compilation' bring C# a performance benefit over Go ?
Mono is considered slow in the .net world. Lets hope the new stance on open source makes things better.
Go and C# are dealing with similar constraints, there is no language design advantage in go with respect to performance, and the resources applied to implementation are similar.
> Go performance is going to converge on C performance with new optimization's being written after go 1.5.
Do you have more details. It would seem like it would be rather difficult to do that. Sure it can rival Java in some workloads, but C performance is a tall claim.
Go is currently pretty fast, maybe half as fast as C. There is a new backend for the Go compiler being planned which uses more modern techniques.
This plan[1] estimates at 10 percent speed improvements initially, I just think they will continue to progress further over time once the SSA framework is built. They will be able to port essentially every optimization llvm uses eventually, and add a few new ones that can rely on memory safety and pointer aliasing guarantees Go provides.
Go can also do whole program analysis with the ssa form because all source is present at build time.
An addition of a moving garbage collector may also improve cache locality. We will see, google cares about making servers efficient, as it saves money in power.
What guarantees does Go provide about pointer aliasing? I have no production code in Go, but from what I have played with, Go has no way of indicating that a pointer is not aliased, so how can it optimize that, other than through static analysis, which will not catch the majority of cases.
I ctrl-f'd "alias" on your paper that you linked, and no mention is shown.
edit: in fact, I forgot to look for "escape analysis." So it does get mentioned, but only to point out that it is a non-goal of the project.
Well, once you compare both languages you can see why. Hint: inovation/complexity (not that either is a good or bad thing). Anyway, that's only one possible reason... I think Go is actually 2 years older.
Go hasn't changed much from its initial versions, iirc rust is unrecognizable compared to early versions. Rust didn't know what it wanted to be from the start.
I wanted to give rust a crack years ago, but I am glad I didn't because it would have required constant updates for anything serious.
Go hasn't changed much from its initial released version, or initial internal version? As I understand it, Go was released in a much more final state, whereas Rust was developed in the open from very very early. Rust has always known what it wanted to be, it has just taken a while to find the best way to actually fill that goal. That isn't really a fundamental problem with the language (in fact, I see the constant iteration and change as a good thing: the language was developed empirically, removing features that didn't work/pull their weight, adding ones that did), although it is definitely a good reason for people to have not used Rust historically.
In any case, this discussion seems like a non-sequitur: whether Go is boring to hanlec or not is orthogonal to whether Go is more stable than Rust or not. The fact that a language has been stable for years rather than only just now approaching stability might be something you value highly, but clearly hanlec has a different utility function.
Go hasn't changed much, because it is the natural extension of plan9 C and other languages from the past. If you look at the project layout of the plan9 source tree, it matches the Go project layout now.
I think plan9 C even used CSP channels in the form of a C library for most of the servers. They just took what they already knew worked, and tried to polish it and add garbage collection.
Rust is trying many things at once then letting things die off as they prove useless.
> Rust is trying many things at once then letting things die off as they prove useless.
Yes, this is perfectly true. I cannot tell from your phrasing whether you think experimentation, learning from experience and removal of pointless code is good or bad. I personally think all of those are good, but you're perfectly entitled to differ.
Go was designed with the lessons learned and experienced gained from plan9, Rust was designed with the lessons learned and experienced gained from iterating on Rust itself. Seems pretty similar. :)
I wish I could use 'type' as a variable name or as a field on a struct. It's one of the most used identifier names and the inability to use it is frustrating.
(See my valid but then NSA downvoted answer to the question below regarding GO vs. Rust that no one else could answer and were forced to make jokes about -- if you are wondering what I mean.)
For a language that was written by Mozilla, I find it very annoying that they steal my browser's built-in ctrl+f functionality that I'm perfectly fine with using. Also, my vimium plugin doesn't work. This is the first time I've encountered something like this. This better not become a thing.
The forum software has nothing to do with either Rust or Mozilla. It's Discourse ( http://www.discourse.org/ ), and personally I agree that it's kind of a pain. :)
Please use something different. Something utterly broken like this (keyboard navigation?) casts a bad light on a project that's - at least mentally - connected to Mozilla.
This is a comment on http://www.discourse.org/ , the software used to drive the internals.rust-lang.org forum, which is not written in Rust nor developed by Mozilla.
