Rust Priorities after 1.0
internals.rust-lang.org
internals.rust-lang.org
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.
Why would you have to rewrite code because of an expanding std lib?
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).
In practice there will be minor breakages due to unavoidable bugfixes.
Expanding the stdlib will never break your code. All changes now are being made with backcompat in mind; older code should never have to update.
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.
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.
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.
... 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]:
pub fn lock(&self) -> LockResult<MutexGuard<T>> {
unsafe { self.inner.lock.lock() }
MutexGuard::new(&*self.inner, &self.data)
}
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].
[0] http://doc.rust-lang.org/std/sync/index.html
[1] http://doc.rust-lang.org/src/std/sync/mutex.rs.html#196-211
[2] Well, strictly speaking a RwLock is a closer runtime approximation to the borrow checker's rules, because it allows multiple simultaneous readers: http://doc.rust-lang.org/std/sync/struct.RwLock.html
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.
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.
Hey you reading this! Yeah, you! If you happen to be an expert in integrating native compilers with MSVC, we desperately need your help!
I did some REALLY REALLY MINOR code in Windows before doing it on Ubuntu, and I had no issues dependent on OS.
Have had 0 issues, and I have no idea what the fuss with windows is about. 0 ICEs nowadays, and it works like a champ speedwise (obviously)
Compared to Ruby, Rust is basically C#, windows wise. In the past I have gotten ICEs and shit, but nowadays its perfect.
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.
Would you mind filing a bug about this? (with as much configuration details as possible). Thanks!
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.
Any cool projects I can take a look at?
Go has been ready for years.
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.
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.
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.
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 think experimentation is a good thing, I don't know if I want to be the guinea pig though.
it does have some marquee names behind it, though. I suppose if you squint, that can make up the difference.
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.
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.
Can you explain this or point me to the relevant documentation or code please?
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.
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.
In most cases using iterators will avoid them.
I don't know how well Mono C# compares to Microsoft's version, but looking at:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
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 ?
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.
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.
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.
[1] https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...
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.
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 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.
Was not part of the original comment I answered to.
a := mk(array[10] of int)
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 still seems to be changing stuff like crazy even after the "stable beta" release.
[1]: http://internals.rust-lang.org/t/regression-report-beta-2015...
I get that the language is a beta, but be warned. One example I saw - http://internals.rust-lang.org/t/memcpy-is-backwards/1797
That particular change caused heartache, yes, but it was purposely made before the beta release, exactly because it was breaking.
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.
http://internals.rust-lang.org/t/regression-report-beta-2015...
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.
Would anyone like to compare Rust to ATS instead? Maybe Erlang? Anybody??
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.
> For example, Rust has destructors for RAII whereas ATS
> requires manually calling functions to clean up
> resources.
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:
http://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memo...
Well, to be fair, talking about a language is also about talking about what makes it different from others.
Go is mentioned 45 times in that thread about Rust...
There are plenty of people in this thread also complaining about aspects of Rust and its development.
Meaning: GO was dead at birth from out of the sphincter of the NSA.
(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.)
Sorry rust thread. :(
(now kicked off the front page)