Rust is nice. But the article miss one important point. Modern software engineering is a collaborative effort (well, it has always been, afaik). I write code for others to understand. I find Rust code significantly hard to read (I am saying this as an experienced C/C++ programmer and as an intermediate haskeller). Yes, one can write write-only code in any language. I think it is extremely important to write code that others can understand and imho, it trumps all other reasons. Not trying to underplay the value of type safety. It is fantastic. My Haskell programs have much much less bugs and I tend to get it to work, much faster than when I do C/C++ code. I would expect some of that goodness to be in Rust programming as well.
It would have been fantastic, if Rust took only a few steps further from Cyclone. I also wish that Rust authors stop adding more and more features. The target audience, namely low level system programmers, tend to work close to hardware and think along those lines, so bombarding them with type theory concepts is only going to shoo them away.
And as a Rust and Python programmer, I find C++ hard to read (I can never shake the feeling that the ampersands are always in the wrong place), and I'm nearly hopeless at deciphering Haskell. :P I suppose this is just something that comes with experience.
Haskell syntax is really nowhere near as complex as C++'s or even Rust's. It's not indecipherable, it's just different and not C-like. It's in the same family as SML, OCaml and F# so if you learn one of those, the others come easily.
I suspect Haskell's syntax isn't as much of an issue as the typical style that Haskell code tends to be written in; really short, abbreviated variable names, and very high code density.
> I also wish that Rust authors stop adding more and more
> features.
I'm not sure what this is referring to. Rust hasn't added any features since the stable 1.0 release last May, and I also don't believe it added any features in the six-month beta period prior to that. And it's not an especially feature-heavy language in the first place, likely comparable in size to Python (e.g. a medium-sized language).
We have and will add language features; though we haven't added any HUGE things in a while. You are right that RFCs contain language changes. A lot of them are small. Some of them are big, and there's certainly more big ones on the horizon.
The most recent one off the top of my head is the ? syntax RFC, which should reduce the amount of error-handling boilerplate.
The big ones though are:
* Specialization. This will allow you to write ultra-performent generic code by special-casing when you have the knowledge. It also will be a building block for the next few features.
* The bag of features colloquially known as "inheritance", though that's not really a good name.
* Non-lexical borrowing, and various other borrowck usability improvements.
* Abstract return types, which will allow for you to remove some allocation and make certain type signatures much better.
* Incremental compilation.
Those are the ones on the short list. There are others too, like higher kinded types.
Great. They all look great. The ones like higher kinded types are the ones that I am highly suspicious of. The typical C programmer who pokes around hardware data sheets and writes drivers and stuff will likely not pay much attention to Rust if such complex features are added.
Also features like that makes me wonder if you folks are really targeting C/System programmers. Sorry if I sound negative, that isn't my intention.
Systems programming does not preclude a language from having a good type system or higher level abstractions.
A good example is Phil's OS. http://os.phil-opp.com/. He's designing an operating system in Rust, and it has surprisingly few "unsafe" parts. The rest of it is made safe using some neat zero-cost abstractions.
Higher kinded types isn't going to happen anytime soon. It's something that crops up often in discussions when people want to model something complicated with the type system; but it's a very nontrivial feature that would probably need to wait for Rust 2.0, if ever. Even if it would exist, you can just not use it. Like most of the other features being added.
> Systems programming does not preclude a language from having a good type system or higher level abstractions.
I didn't say that system programming does not need a good type system. I am also not saying that it is impossible to design operating system software with Rust.
As someone who had been on both the sides of the abstraction and having closely interacted with the system programmers, I think it is just too hard to convince them to use Rust. It is not just about the language alone, it is about what minimum you need to bootstrap a system (among many other things).
Anyway.. good luck to the OP in "rewriting everything in rust" and also getting it to the same quality/feature parity as others in the game and also get others to use it as well.
Yeah, I'm just saying that "higher kinded types" (which, again, Rust isn't getting anytime soon), does not make Rust something that isn't targeting systems programming; in response to "you folks are really targeting C/System programmers".
Many of Rust's designers are experienced systems programmers. A _lot_ of effort goes into making it systems-ready.
> it is about what minimum you need to bootstrap a system
Rust works on any target LLVM compiles to, and you can opt out of the standard library if you're writing baremetal things. There already are people writing low level Rust things.
But yeah, I know the skepticism you refer to; seen it in action before. But in the case of Rust I've rarely seen any concrete points being brought out (aside from perhaps "LLVM doesn't target enough things", which is fair). The language developers do try to take input from everyone and make it more systems ready; but there really isn't much that can be done when there isn't any input other than a strong preference for C.
They are specifically there so that you can write zero-cost abstractions. Yes, people who are hardcore C programmers may not have experience with more advanced type system features, but it's all in service to the goal of writing expressive code that goes as fast and as safely as possible.
As a practical example of higher kinded types, you can't say "this function takes an Rc<T> or an Arc<T>. I just want something refcounted, but I don't care about how." HKT would get you there.
Another common problem it would solve is "I don't want to write both a &T and &mut T version of my function."
Another gripe I have is that the Rust Book examples are all targeted at non-system programmers. It would have been nice if certain programs written in K&R book or from one of those books from the Bell Labs Unix folks (like "The practice of programming" or "software tools") is written in Rust as a demonstration.
You should be much happier with the second edition of the book.
(One of the reasons it's this way is largely historic: so much was changing in the lead-up to 1.0 that I couldn't add many examples, as things kept changing out from under me.)
Since no one mentioned Plan 9, I thought I will mention one of the many features that makes Plan 9, one notch above Unix to make it easy in the web era.
In Plan 9, literally everything has a file abstraction. This also includes sockets. So, even shell programs can be network programs without external programs like curl or wget or anything like that. For anyone interested, look at webfs(4). You may say that this can be implemented with fuse. But having something first class, designed to operate well within the file abstraction, is very different from something that has been added as an afterthought. In some sense, the BSD folks who added sockets into Unix really screwed it up and missed the Unix philosophy altogether.
Modern 'Linux' systems are full of programs that violate Unix philosophy.
cdrecord, ffmpeg, emacs, dbus, imagemagick, all modern browsers ... the list goes on and on. plumber(4) does what dbus is trying to do, with very little amount of code and text file based rules.
I see it as a missed opportunity for linux kernel and hence to the wider audience to experience a computing environment that is a joy to use.
