
This Week in Rust - cmrx64
http://cmr.github.io/blog/2014/02/23/this-week-in-rust/
======
bjz_
> 89 pull requests were merged this week. This is the most pull requests
> merged in a week, ever.

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.

~~~
theknown99
Reinventing the first 90% of the wheel is quick. It's that last 10% that takes
all the time.

~~~
bjz_
Indeed. There is a ton of polish that has to be sunk into the language and the
libraries to get them to a state where 1.0 can finally be declared.

~~~
Pacabel
But when is that sort of stability going to be achieved by Rust?

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.

~~~
heydenberk
There are already a lot of programming languages that made it to x.0 without
making all the breaking changes they should have, leaving warts all over the
language and the standard libraries. The fact that Rust is still making lots
of breaking changes is good, IMO. They seem very cognizant of the fact that
they should make all the breaking changes they can while they still can.

~~~
Pxtl
Absolutely. I'd hate to see Rust go through a Python 3 debacle, or deal with
the .NET approach where half the framework libs are completely superseded by
new libs in every major release.

~~~
Pacabel
Python 3 wasn't a "debacle" in any sense. In fact, it has proven to be an
excellent approach. Users with large Python 2.x code bases haven't experienced
any disruption. Users who needed Python 3's features were free to upgrade as
soon as they wanted. Libraries and frameworks have gotten Python 3 support
when it becomes feasible and worthwhile to do so. It may not be the fastest
adoption possible, but it has been quite pain-free, and totally optional for
those who have no need for it.

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?

~~~
pcwalton
> Python 3 wasn't a "debacle" in any sense. In fact, it has proven to be an
> excellent approach.

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.

------
gmjosack
I've been learning Rust lately and people like cmr and the rest of the guys
over at #rust have been super helpful. While Rust is moving fast the This Week
in Rust posts make it very easy to keep up.

Overall I'm loving the language and the community and can't wait to see more
wide adoption.

~~~
sanderjd
Their IRC room is the best I've lurked / asked questions in. They frequently
discuss way-over-my-head language design proposals and even more frequently
answer noob questions in a friendly and patient manner. It's a great
community, and I hope it stays that way!

------
moron4hire
The progress being made on Rust is amazing. I'm not sure I've ever seen a
language developed in such earnest before.

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.

~~~
Codas
The rust compiler itself would certainly not be the best resource, but I thing
servo[1] would do just fine. Also, you can just look at some rust
repositories[2] on github.

[1]: [https://github.com/mozilla/servo/](https://github.com/mozilla/servo/)

[2]: [https://github.com/trending?l=rust](https://github.com/trending?l=rust)

~~~
sanderjd
This is a few entries down in the trending list you linked, but rust-http[1]
is currently my favorite example of a very non-trivial and actively developed
rust library.

1: [https://github.com/chris-morgan/rust-http](https://github.com/chris-
morgan/rust-http)

------
vanderZwan
That looks like quite a list of breaking changes (although I don't know how
much real code is affected). I guess that's good in the sense of being willing
to fix things.

Does the Rust community have a gofix-like tool to keep up with this?

~~~
bjz_
Well, the language is still pre-1.0. It is better to fix things now than be
stuck with supporting poor design decisions years into the future. The good
thing is that the semantic changes to the language have decreased
significantly over the past year, and feature flags are now provided to force
users to opt-in to experimental parts of the language. Much of the churn is is
now on the library front.

There is no gofix tool, but you can use [http://rust-ci.org/](http://rust-
ci.org/) to get immediate feedback when things break.

~~~
coldtea
I don't know about the gofix tool, but I sure believe the language needs a
standard gofmt tool before it's 1.0.

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.

~~~
Ygg2
That's a moot point. Many languages go without any kind of formatting tools. I
definitely think a format and test coverage tools are HUGE productivity
boosts, but I don't think it's time to spend on them when things like DateTime
are still missing from language.

~~~
coldtea
> _Many languages go without any kind of formatting tools._

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.

~~~
Ygg2
It's a moot point because:

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.

~~~
coldtea
> _..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?_

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...

~~~
Ygg2
So? As long as you have same style on your project - any style, your code will
be readable and with less WS conflicts. I don't see what a built in formatter
does, other than allow to minimize bikeshedding about format, which will just
pop up as BS about libraries or VCS or something.

That is assuming built in formatter doesn't have configurable options. Which
some formatters do.

~~~
coldtea
> _I don 't see what a built in formatter does, other than allow to minimize
> bikeshedding about format_

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.

~~~
Ygg2
That strikes me as a minor quality of life issue. Great, you've removed about
1% of all Bikesheds (which library,which framework, etc). Not, something that
NEEDS to exist.

------
shadowmint
Hmm... is the removal of std::to_bytes something that's been pending for a
while?

The commit
([https://github.com/mozilla/rust/commit/efaf4db24c92e119e26dc...](https://github.com/mozilla/rust/commit/efaf4db24c92e119e26dc575ffd6bfd3b91fb87d))
is recent and it breaks a bunch of libraries (eg rust-sdl2).

Feels like it deserves a mention.

~~~
dbaupp
That commit is "just" clean-up after
[https://github.com/mozilla/rust/pull/11863](https://github.com/mozilla/rust/pull/11863)

But yeah, probably worth an explicit mention.

------
ilaksh
I am not associated with nimrod in any way, just an enthusiastic new user.
Before I found out about nimrod I thought Rust was the best new language.

~~~
bjz_
Nimrod, like D, does great things in terms of metaprogramming and static code
generation whilst providing a GC that abstracts away from memory management.
Rust on the other hand thrusts memory management into the programmers face,
excelling at providing safe, deterministic control over allocation and a
relatively advanced type system compared to the incumbent systems programming
languages. Nimrod and D seem like worthy alternatives to Go and C#, where as
Rust is providing a much needed alternative to the venerable C and C++
languages that have dominated systems progamming for the last forty years.

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.

~~~
dbaupp
To add to this: Rust puts a _lot_ of emphasis on memory safety, including in
parallel code, while neither D nor Nimrod have such a strong focus on that.

~~~
bjz_
Agreed. The language defaults to safety and immutability, and linear types and
regions are built into the type system. With the addition of mandatory RAII
and unsafe blocks, safe allocation and concurrency primitives can be built as
libraries rather than being baked into the language.

------
namelezz
What kind of problems are Rust trying to address?

