> 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.
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.
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.
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.
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?
> 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.
> 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.
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.
I would rather have a good 1.0 release than a quick one. If Go really is a better language for the applications Rust is aiming for, then it's fine for Rust to fall behind.
Very complicated things that require high performance. The main demo project is Servo, a web rendering engine on around the same level of abstraction as gecko or WebKit.
Java, C#, Ruby, and Python are all interpreted/VMed languages. I'm curious why you would liken Go to them. Other than garbage collection, I can't see any significant similarities in their design or usage.
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.
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.
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!
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.
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.
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.
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?
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/ to get immediate feedback when things break.
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.
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.
>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.
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.
>..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...
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.
>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.
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.
> And I don't think it's a moot point -- if with moot you mean "open for debate".
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".
You're arguing against a point he didn't make: he's not saying that it's a high priority now in the larger scheme of things, just that the formatter should be there before it hits 1.0. The latter usually meaning "when we really intend to unleash it on the public".
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.
It works, but it's not perfect. The groundwork has been done, but as the language is still shaking out, it's not something that a ton of effort has been put into improving.
I too, hope that it will be psudo-mandatory upon 1.0. We'll see.
Nope; just the IRC channel, these newsletters and http://www.rust-ci.org/ to inform people when things break (it triggers Travis CI builds each day, when a new nightly package is built).
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).
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.
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.
I don't know enough about Oberon and the Modulas as I should, but I'm guessing GC was the default and was required for safety? The libraries required GC too?
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.
Ahh - your comments about Unix taking the wrong path in another story have more context now - I wasn't aware that GC had been integrated into an actual working kernel in the wild. Very interesting!
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.
For example: realtime systems, rendering threads, embedded systems that require minimal runtimes. Smaller subroutines on the whole don't really need it, and those small performance gains can add up considerably in an intensive system. GC is mainly useful for things with undetermined lifetimes. Glue code essentially.
Eh? It doesn't do that. It doesn't provide any context or assertions why one is better over the other. It comes of as a way to market a different language in a thread about Rust.
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.
Here is the lay of the land as I see it – I could be wrong though, so take it with a grain of salt:
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.
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.