This Week in Rust
cmr.github.io
cmr.github.io
The activity of this community never ceases to amaze me. Contributions and improvements are coming in thick and fast, and yet still we still seem to be keeping on top of it. Only 54 PRs are currently open on Github, despite the churn.
We keep hearing about how "it's happening" or it'll be there "soon". But yet we still see a language and standard libraries that are evolving significantly on an ongoing basis, breaking existing code along the way.
If Rust wants to be a viable option, at some point this indiscriminate change needs to stop. It may mean that this initial version of the language has some flaws, but at least it may also be usable for serious development at that point.
The sooner that happens the better. The longer Rust delays stability, the greater traction we see competitors like Go or even existing languages getting. Rust is starting to get a Perl 6-style reputation, where there's great promise and lots of hype, but never a version we can confidently use for software that's remotely serious.
Besides, Rust should be happy to get anywhere near the number of users that Python and .NET have. That surely won't happen until there's a version of Rust that's stable for more than a couple of months.
And what makes you think that Rust still won't end up in a situation where some desired future functionality requires backward compatibility to be broken, regardless of how much effort they put in now?
That's… not an opinion shared by anyone else I've heard of. Python 3 has been a disaster, mainly because it didn't offer enough of a reason for users to upgrade. In other words, Python's so entrenched that Python 2's warts are effectively staying with the language forever. That is hurting every user of the Python language, and is actually an argument for fixing Rust's flaws now, while we still have a chance to.
> Besides, Rust should be happy to get anywhere near the number of users that Python and .NET have. That surely won't happen until there's a version of Rust that's stable for more than a couple of months.
We explicitly don't want so many users right now that we can't break things. That's not to say we don't want users—we do, of course—but we need them to know that the language will be unstable until 1.0.
> And what makes you think that Rust still won't end up in a situation where some desired future functionality requires backward compatibility to be broken, regardless of how much effort they put in now?
You're arguing that we shouldn't bother fixing anything because Rust will not be perfect. Yet in many of your other comments you criticize the Web stack for its lack of forward thinking design in many areas. Do you see the cognitive dissonance here?
The time to fix things that can't be fixed later is now. Just because Rust will not be perfect at 1.0, and there will be things we wish we could have changed, doesn't mean we shouldn't do the best we can.
Rust is moving very quickly now, but they clearly have a cutoff in sight, and their explicit goal is a stable language spec and standard library for 1.0.
They are also building on LLVM, which gives them a fairly solid base; in contrast to perl6 that was trying to make a multi-language VM while reinventing the language.
Sure, the usual implementations all use a VM. So what?
> I'm curious why you would liken Go to them.
Because for many of the things people would consider using Go for, one or more of those languages would be the top competitor.
Control over memory management is a major, major design point. In my opinion, it's a lot more significant than whether it runs in a VM or uses native code.
For one thing, running in a VM vs. native code is usually an implementation detail. But the only language I can think of where memory management appears to be an implementation detail is Ada.
And even Rob Pike admitted that most people come to Go from Python/Ruby, whereas he expected that to be from C++.
This year.
You can see the issues here: https://github.com/mozilla/rust/issues?milestone=20&page=1&s...
> It may mean that this initial version of the language has some flaws, but at least it may also be usable for serious development at that point.
Right now those "flaws" include "not memory safe", and we can't fix that without breaking existing code. We are hard at work on fixing that, but we can't freeze a language that's designed for safety that isn't safe.
Overall I'm loving the language and the community and can't wait to see more wide adoption.
The tutorial on rust-lang.org is pretty good, but I find myself confused about the exact nature of the utility of some of the features. The Linked List example is certainly better than any old Foo/Bar/Baz one, but it's still pretty limited.
Are there any suggestions for existing Rust applications that can be read to get a better handle of how the language is intended to be used "in the wild"? It'd be great if there were, say, a CRUD website, or a user-options config GUI utility, something really basic that does stupidly simple work of a non-trivial nature. I feel like the added overhead of learning how compilers in general are supposed to be designed would make reading the Rust compiler source anti-productive.
Does the Rust community have a gofix-like tool to keep up with this?
The language moves too fast for maintaining a gofix tool to be feasible or a productive use of time (IMO much better to spend all the effort on getting the language nicer and nicer as fast as possible).
There is no gofix tool, but you can use http://rust-ci.org/ to get immediate feedback when things break.
It saves the Go community so much bikeshedding and BS, and I've never seen anyone (except an insignificant minority bent on "freedom of expression" on their brace style) not like it.
Good standardisation and automated tools to help with it are not quite as irrelevant when you reach the stage of trying many people to work with the language in big projects.
Well, actually that's a moot point too. Lots of languages go without any kind of closures either, but I wouldn't much like a language that doesn't have them.
I'm not saying it's necessary -- I'm saying it's very nice to have.
And I don't think it's a moot point -- if with moot you mean "open for debate". In Go, nobody debates that gofmt is very beneficial (well, the few complaints are on the level of statistical noise).
>but I don't think it's time to spend on them when things like DateTime are still missing from language.
You can add DateTime at any time. Java only recently added a decent one. But if you don't come with a tool like fmt from 1.0 and force it down people's throats (like Go), nobody will adopt it later.
While "moot" itself has several definitions (and is, in fact, a contranym), the phrase "moot point" generally means a point about which debate is irrelevant, not one which is "open for debate".
A)Rust team deemed it low priority because syntax is in flux
B)Lot's of great languages go without formatting tools, so it's not THAT necessary
>You can add DateTime at any time.
DateTime added after will likely be in a form of several incompatible and buggy libraries. A formatter is nice, but personally I think a good test coverage tool is way more functional than a pretty formatter. And a date time library is often way more needed to deal with the insanity of DateTimes received from databases and other sources of information.
>but if you don't come with a tool like fmt from 1.0 and force it down people's throats
..they will invent an IDE that does automatic formatting, for them? Like Eclipse, IntelliJ IDEA? Or a library that does the same like JSLint/JsHint?
As long as your tools agree on common formatting, it's not that difficult to achieve similar results to gofmt.
That's not the same. All those tools allow different styles, and people use them. You'd be hard pressed to find 2 javascript projects with the same formatting style on GitHub, whereas in Go it's like the default way or the highway...
That is assuming built in formatter doesn't have configurable options. Which some formatters do.
That's exactly what it does -- and it's an absolute wonderful experience to see it in Go. I'd say it again: very few people don't like, and most that tried Go were singes the praises of this idea.
$ rustc --pretty foo.rsI think it also needs the "push it down people's throats a la Go" thing going to really benefit from it.
I too, hope that it will be psudo-mandatory upon 1.0. We'll see.
The commit (https://github.com/mozilla/rust/commit/efaf4db24c92e119e26dc...) is recent and it breaks a bunch of libraries (eg rust-sdl2).
Feels like it deserves a mention.
But yeah, probably worth an explicit mention.
https://mail.mozilla.org/pipermail/rust-dev/2014-February/00...
The same way when a critic reviews a movie, he also mentions and compares to other movies.
Here is example how I see OP in lieu of your analogy:
"I liked movie Gravity until I watched movie Her ..." and continues to ramble about movie Her.
It seems to me like a marketing failure that Nimrod and D seem to be attempting to go after the low level systems programming domains when they should really be competing at a higher level of abstraction.
In Oberon's case, full GUI single workstations systems were used during several years at Swiss Federal Institute of Technology in Zurich (ETHZ).
OS vendors just don't care to bring into the mainstream such systems.
GC was originally intended to be the most common form of allocation in Rust, but once linear types and regions were properly implemented it turned out that GC wasn't nearly as necessary as was previously thought. It is definitely useful though for some use cases, which is why it will be built as a library, with language hooks to make it clean to use, but users definitely won't have to pay for it if they don't use it.
The whole operating system was implemented in Oberon, just with Assembly for the usual parts there is no way around it.
Both languages have value types and stack allocation as well. GC is only used for explicitly allocated heap data.
Modula-3 allows for declaration of untraced references as well.
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/
Afterwards, there were improved systems which provided a better experience, improved the programming language and had some parts moved from Assembly into proper Oberon. Namely EthOS and Active Oberon (AOS/Bluebottle).
If such systems had got industry support, who knows how mainstream computing would be now.
How can anyone possibly think that is necessary or a good idea?
Garbage collection is great, but not for everything.
Julia is dynamically typed and leverages LLVM's JIT support to generate efficient code at runtime. Julia has a clear goal of taking on the scientific and statistics domains where R, Matlab and Sci/NumPy are currently dominant. It is an elegantly designed language that provides blazingly fast bindings to established Fortran and C numerical libraries.
Nimrod is statically typed and compiles to C, C++ or Objective C. It seems to be aiming to be 'general purpose', but there has been efforts to position it as a systems level language. The biggest draw seems to be its expressive metaprogramming capabilities[0] and clean, python-esq syntax.