Rust's 2017 Roadmap
blog.rust-lang.org
blog.rust-lang.org
What it comes down to again and again with projects I think about using Rust for is "how much extra effort is it going to be compared to a language with good libraries for this?" Often I don't use Rust just because the cost/benefit of having to (re)write code that would otherwise be in a library doesn't make sense.
I'm still bullish on Rust. I know it takes time and it's an unfair competition against the likes of Node and Python (with a zillion library authors), or Go (with a huge company dedicated to a kickass standard library). But nonetheless that's the playing field, and I think a stronger library ecosystem is probably the most important thing for Rust adoption right now.
Well, that and not having to use nightly rust for serde, but you already fixed that.
On the other hand, if you're looking to fill out your resume or get some open source credentials, you can see this as another frontier opening up (depending on how popular you think Rust will be in a few years). Become the solution for that need in the Rust ecosystem, and there are probably massive reputational benefits to be reaped. In some ways, reputation is better than money, because when invested wisely can have a much higher rate of return, and depending on location and circumstance, can be levered into high-paid employment.
One person's problem is another person's opportunity.
You should consider publishing an official, printed book. I would totally pay $30-40 for something like this. And once it's already written, the actual publishing shouldn't be too time consuming (but idk lol). I think that there's a lot of people who'd buy it just to support the project.
On one hand, I do have environmental concerns, but on the other hand, I feel like my retention rate with print is like 70% as opposed to like 40% with digital.
https://www.amazon.com/Programming-Rust-Fast-Systems-Develop...
For one, I would be surprised if a non-"expert" (which is, I presume, why you're so dismissive of Rust developers) could write a book that gives an accurate/useful mental model of Rust: teaching is the true test of one's knowledge about anything. Additionally, people paid to work on Rust and on Rust documentation/teaching materials (i.e. "Rust developers") are the people most regularly interacting with all sorts of beginners, and thus are likely to have great insight into, for instance, the common difficulties people hit, rather than just anecdoata about their own personal experience/background (which is good too, but is only one point of reference for things that people find hard).
Rust developers can write beginners books (indeed, the Rust book is designed to be this, and the second edition succeeds better the first, I've heard) just as much as non-Rust-developers can write expert books.
A C programmer, a Python programmer and a Java programmer should write the book together, with expert insight from a Rust pro.
As an example, I found the explanation of trait objects incredibly confusing when I read the book. They confused the subject by immediately talking about static vs dynamic dispatch of functions, which is really an implementation detail and performance consequence of using them and not a part of what they are logically. An outsider might have started with a simple explanation of what a trait object is (an instance of a trait where the compiler cannot determine the concrete type at compile time) and make that clear before diving into the consequences of choosing to use one in your code.
I think the specific case you mention was a problem more caused by a desire to have some documentation for 1.0, even if it isn't perfect, rather than just leaving the feature undocumented. That page is originally[1] based on a blog post[2] that is targeting people who want to know how they work internally, and there wasn't much time before 1.0 for feedback, revision and iteration of it (there was one cycle, which improved it in the direction you want, but more is always better). The second edition[3] doesn't have the 1.0 crunch date, and benefits a lot from feedback on the existing teaching material (like yours here) and the extra experience the team has had teaching Rust, so, by all reports, does a much better job. (It doesn't seem to currently have anything about trait objects, but I'm sure it will soon.)
[1]: https://github.com/rust-lang/rust/commit/dbccd70a5736fd2e898...
[2]: http://huonw.github.io/blog/2015/01/peeking-inside-trait-obj...
(And the second edition will have trait objects in it, it's not there yet though.)
One of the sections that was most useful to me was comparing how memory is laid out in a few different languages with a few different concrete code examples. These comparisons really helped me "get" borrowing.
https://www.packtpub.com/application-development/rust-essent...
I have purchased it and it's pretty good. Although it really seems to be geared more towards experienced systems programmers. The online book is much better for beginners, IMO.
The main problem I have with Rust is that it's not up to the task of dealing with C APIs, particularly POSIX. The issue I got stuck on was https://www.reddit.com/r/rust/comments/47a0s3/dealing_with_v... . There are two possible things Rust could do that would make me give it a second chance: either commit to maintaining bindings for all of POSIX and libc as part of Rust core, or fold rust-bindgen into core and get it into shape.
Creating higher-level libraries like Tokio is nice for some use cases, but right now Rust doesn't have a working safety valve for things C can do that Rust can't. This greatly magnifies problems like lack of bindings for select() (see http://esr.ibiblio.org/?p=7294&cpage=1 ; I too ran into that problem, and lost a few days to it.)
rust-bindgen has been improving a ton, and it is in fact on that roadmap, under
> Integration with other languages, running the gamut from C to JavaScript.
I didn't try the nix crate at the time, but looking at it just now - it doesn't solve the portability issue. It defines struct Termios in https://github.com/nix-rust/nix/blob/master/src/sys/termios.... , with something #ifdef-ish branching on operating system, but not on CPU architecture. On quick inspection, I think it's probably incorrect on x86-32, and this crate is definitely a major liability for portability.
(Also, I'll stop here and only reply on our Reddit conversation, ha!)
(The first few comments are mirrored between here and Reddit.)
Anyway, huge fan of what the Rust devs are doing. It's truly awesome.
What do you mean by saying mutability is for safety? That's a very unusual opinion.
Copying everything every time isn't a solution in a multithreaded world if you actually want your threads to share data.
No. Two threads on the same CPU core really access the same data(1) without the delay and no locking happens unless the programmer wrote some locking code.
Synchronizing the different cores or processors is another topic, but it's also typically dependent on the software.
----
1) But there is also reordering https://en.wikipedia.org/wiki/Memory_barrier and out-of-order execution https://en.wikipedia.org/wiki/Out-of-order_execution
Most of the time the implemented techniques do significantly speed up the execution. And it's mostly software design that initiates the slowdowns, not the CPU.
> And it's mostly software design that initiates the slowdowns, not the CPU.
This is quite vague statement and I'm not sure what you really meant here. Software written using a simplified abstraction model (e.g. flat memory with stuff shared between threads, ordered sequential execution) much different than the way how CPU really works (hierarchical memory, out-of-order execution, implicit parallelism etc.) is very likely to cause "magic" slowdowns. See e.g. false-sharing.
Also algorithms designed around the concept of shared mutability do not scale. Sure, you may hide some of the problems with reordering, out-of-order, etc. To some degree it will help, but not when you go to scale of several thousands cores in a geographically distributed system.
It's also an effect of a badly written software, not something that is constantly present in the CPU execution. You based the claim to which I've replied on "sharing is illusory", "if two threads" and "the CPU deals with it" like it's necessary to happen all the time in the CPU as soon as the threads exist and they access the same data.
> when you go to scale of several thousands cores in a geographically distributed system.
There you are not describing "a CPU" (as in, the thing that's in the CPU slot of the motherboard) which is all I discussed, and I'm not interested in changing the topic.
Since the borrow checker happens at compile time, the whole mechanism is "zero cost". This results in more efficient code, because you can do things like safely hand out references (pointers) to privately held pieces of data without needing a heap allocation to track the pointer (e.g. shared_ptr in C++); the final code needs no lifetime checks, because the compiler did all the analysis for you.
I imagine the combination of ownership and immutability also lets the compiler reorder, eliminate and simplify generated code better than most other languages (Haskell being a possible exception here). Not sure if Haskell-style automatic parallelization is planned.
I like Rust, but IMO no language will ever again be Java-level popular (not even Java!) in the same way that e.g. there will never again be a band as big as the Beatles. Technological contexts have changed such that niche languages can now successfully thrive and counteract the lower switching cost that comes with a monoculture; while certain languages "in the middle" will still dominate, the long tail will get longer and subsequently lower any dominant language's market cap.
What I actually would like is a few "Books" like "Rust for C++ people", "Rust for Go people", etc. Those would describe in many examples how things that are achieved in language X using A, B, and C can be done with D in Rust.
Personally, I would like a "Rust for Gophers" book that would describe things like how does Rust do composing (that is, how to do what Go calls embedding), interfaces in Rust (with dynamic vs static dispatch), HTTP in Rust (this may be waiting for Tokio?), how to model your application's types and not get into who-owns-what traps.
Also, what I really want is some kind of a list of Rust "warts" and their explanation. Like the fact that sometimes you can't do a.b().c(), but have to write tmp = a.b(); tmp.c().
I fully agree that more of this kind of thing would be great.
Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just
- take a random C++/Go/Python developer
- ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust
- look and take notes on their struggle with it
This might shed some light on why people (like me) have so much trouble getting into Rust.
I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf...
I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things.
More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sample. It's one of the reasons you'll see me pushing for details in Rust threads here, for example.
Agreed, and Vec should just be Buf! Let's fork the language. :)
1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}.
2. You can still use {} for blocks if need be
3. Everyone uses elastic tabstops in their editor
I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.
- No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594
- Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_retu...
If the next push is going to be for ease-of-use, those would be two nice things to fix.
https://github.com/rust-lang/rust/issues/34511
Who knows when it'll be stabilized, though.
Basically, I tried to create a very basic HTTP server the way I would in Go, but I kept getting all sorts of lifetime errors and kept adding stuff go get away from them. So the code has issues, lots of them. Arc<Mutex<>> was recommended by a guy at the job, I don't even know why I need an Arc here, for example.
The compiler says
consider using an explicit lifetime parameter as shown: fn handle<'a,
'b>(&self, req: server::Request<'a, 'b>,
mut res: server::Response<'a>)
error: `user_index_handler` does not live long enough
I _think_ the issue here is that Request and Response both have lifetimes. The compiler suggestion you're seeing was recently removed for having too high of a false positive rate, which I believe is what happened here. By doing that, you say that the handler must live as long as the Request and Response, which is not true, since it's created inside the functions but they're passed as arguments.
I will check your example app out (thanks for that!) but the problem in my code still remains and I hate the fact that I can't understand what's going on. That might be my biggest issue with Rust compared to Go. Something doesn't match and I don't know how to find the issue without going to IRC or /r/rust; with Go I've never had an issue that wasn't resolved by carefully reading the language/library docs or StackOverflow.
Yeah, it was removed literally last week, so it hasn't made it into a release yet.
Without knowing what version of postgres you're using, I can't _totally_ get this to compile, it complains that SslMode isn't there. But, I did fix your issue:
fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>)
The issue here is lifetime elision. http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html...
Specifically, rule 3:
> If there are multiple input lifetime parameters, but one of them is &self or &mut self, then the lifetime of self is the lifetime assigned to all output lifetime parameters.
So here, Request and Response both have lifetime parameters. This means that your original signature is the same as
fn handle<'a>(&'a self, req: server::Request<'a, 'a>, mut res: server::Response<'a>)
The fixed signature says
fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>)
You're no longer connecting &self to the request and response, and so things are just fine.
Honestly, this isn't the simplest signature; it's not surprising that you got stuck. This is also what people mean when they say "I fought with the borrow checker for a while, but then got over it", as it took me less time to fix this error than to write out this comment explaining how to! But until you've got that intuition and understanding, it can feel like hitting a brick wall.
impl server::Handler for UserIndexHandler
impl UserIndexHandler
Which brings me to a question, how does implementing a trait prevent this code from compiling? Sorry for comparing apples to oranges again, but in Go implementing an interface is an invisible operation, that doesn't affect compilation. What's different with Rust?
The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht...
So yeah, my idea won't work, because those types conflict.
> Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked.
I'm surprised it works on first glance, as I was assuming that you were implementing the trait for a reason, not just because. If you don't need the trait, then yeah, it's much easier.
> What's different with Rust?
See my StackExchange link elsewhere in the thread for a summary.
I'll maybe poke at this after my meetings, or maybe tomorrow. We'll see how amped I am for coding after all that ;)
Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough.
So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it.
I bet there's something larger you could do as well, but I don't have enough experience with this interface to give good advice. Hyper's undergoing a huge docs drive for 0.11; I'm sure that'll help.
I haven't benchmarked this particular application because I haven't had the time, and it's never going to see particularly higher load.
You might be interested in this
On top of handling errors (which I understand is necessary, and which the ? operator makes easier), it requires importing BufReader and BufRead, and wrapping a reference to a file handle in BufReader.
Nobody is going to know how to do this unless they come across it in Rust By Example or on Stack Overflow. Shouldn't a standard library be able to abstract over fiddly details like this? Why is it my job to tell it how to buffer?
I say this as someone who is enthusiastic about Rust, but still learning.
In other languages, you might do File.ReadAllLines("foo.txt"), and bam, you're done.
In Python you can just loop on anything declaring the __iter__ method, and it will lazily yield results little by little.
IO related objects implement it plus an additional layer of interface so that you can do:
with open('file', [mode, encoding]) as f:
- for `line in f` to lazy read it line by line. This calls __iter__.
- `f.read([byte_count])` to read it all or some bunch of bytes. `f.seek(index)` to move around, etc.
- `f.readlines()` to get a list of all lines in memory.
- `f.close()` if you wish to close the file manually instead of letting the `with` keyword doing it work you.
This interface works for most IO, including files, sockets, in memory buffers, etc.
So you can choose an automatic lazy loading, a manual loading, load everything in memory, etc. And still have a lot of control.
I think rust should get some traits to expose such a common high level interface on top of the current way it deals with files, to ease simple operations. Just make sure the documentation states what you can do to go lower level.
There is a similar trend with many basic topics trying to do that as 3rd party libs too. click makes creating cmd UI very easy on top of argparse which is lower level. pendulum is higher level than datetime. requests higher than urllib. etc. Those all make doing those very common operation super easy.
Now rust is not meant to be Python/Ruby/whatever, being very low level, and checking safety at compile time implies very different requirements.
But those communities have some good concepts on API ergonomics and it would be a shame to not steal ideas from them.
The interface for reading is split into multiple parts. Read is the lower level interface for any stream of bytes, and is what lets you read a specific number of bytes into a preallocated buffer. Seek is implemented for files, but not all streams, because in most cases it makes no sense. There are also a number of file-specific methods directly attached to File for handling permissions and sync and such.
BufRead is the trait that lets you read all the lines, but it is explicitly not implemented for File, since using it for a File would be slow, and generally the wrong way to do things. It does have an implementation for Stdin, because that is already buffered, but if you want to associate a buffer with a file, you have to do it yourself by wrapping it in a ReadBuffer.
If I were to find a problem with the File documentation, it is that it does not mention BufReader.
It's not so much that it's hard, as is there's lots of options. Can you afford to read it all into memory as a String? Do you need to only read it bit by bit?
> Why is it my job to tell it how to buffer?
Systems langauges need to expose these kinds of details and levels of control.
> Nobody is going to know how to do this
I googled "rust open a file and read by lines" and got these results:
https://users.rust-lang.org/t/read-a-file-line-by-line/1585
https://doc.rust-lang.org/std/io/
https://doc.rust-lang.org/std/fs/struct.File.html
The first two show you directly how, though the first one is dealing with the error message. The last one shows reading it all in. I have some more work to do :)
However, many languages make a reasonable assumption that you can afford to fit each line in memory, and provide an obvious way to do this.
Again, it's about control. Maybe you're only loading a small configuration file, and so fetching it all in one go is better than dealing with a buffer.
> an obvious way to do this.
If you search for 'line' or 'lines' in rustdoc, the correct thing is right near the top, which will show you how to use it with BufRead.
If it's small, it can't be that much worse to buffer. What's wrong with reasonable defaults?
Can you tell me what it means to search for 'line' or 'lines' in rustdoc? Is this a command-line tool? I'm aware of the 'rustdoc' that generates documentation, but not of anything by that name that searches documentation, and Googling isn't turning up much of anything except the Rust book here.
It would be great to have an offline way to search Rust documentation and examples, as things like this make it very hard to write Rust on a plane, for example.
Googling often gives answers that are wrong or pre-1.0. You seem to have better luck at searching for the right things, perhaps because you are an expert in the language and know exactly what to search for.
(Amusing related anecdote: I googled for "how to return self in rust" and got a suicide prevention website. Jeez, Google, it's not that bad.)
Rustdoc has a search bar at the top. with 'line' it's the third result, 'lines' is the first https://doc.rust-lang.org/stable/std/?search=lines
and the short description makes it clear that the first two results are irrelevant in this case.
> It would be great to have an offline way to search Rust documentation and examples,
It all works offline. These docs are pre-installed for you when you install Rust, and 'cargo doc' will generate them for your whole project.
> perhaps because you are an expert in the language and know exactly what to search for.
I copy-pasted my search term exactly in the previous post.
I'm bringing up a problem with how the language presents itself to beginners, not asking you to solve a specific problem for me. If searching is the answer to everything, then there needs to be a concerted effort to take Google-juice away from bad or deprecated answers.
Incidentally, the search result you're describing for "lines" says "An iterator over the lines of an instance of BufRead.", which only appears to be the answer to "how do I iterate lines of a file?" if you already know what the answer is.
I think we have two searches confused. When I meant "my exact query, when we were taking about Google, here: https://news.ycombinator.com/item?id=13585902
I find it interesting that we got different results.
I thought "an iterator over lines" would be enough; maybe not.
>> It all works offline. These docs are pre-installed for you when you install Rust, and 'cargo doc' will generate them for your whole project.
Not by default, anymore[0], as I found out when I wanted to read the book offline.
To set up offline documentation, do:
rustup component add rust-docs # One-time thing
rustup doc
rustup doc --api
rustup doc --book
[0] https://users.rust-lang.org/t/psa-rust-documentation-is-now-...
Let me assure you that I mean only the best for this language and I appreciate your persistent willingness to help, but I want to help debug your use of internal terminology that doesn't help beginners.
"rustdoc" is not how you should be telling beginners to look for documentation. As far as I can tell, "rustdoc" is the tool for generating documentation, not searching it. I assume you use rustdoc a lot and that's why the name comes to mind.
Maybe the term is overloaded, but I cannot find anything called "rustdoc" that involves a search bar. Googling for "rustdoc" gives many forms of Rust documentation, none of which have a search bar. DuckDuckGo-ing for "rustdoc" (as some documentation suggests instead of Googling) gets me some of the same things, plus rustdoc.com, which is a big honking security warning on top of someone's broken personal blog.
I know that exact link you gave me includes a search bar, but that's an example of finding the answer because you already know it.
And if you know to go to doc.rust-lang.org and go to the Standard Library API Reference, you get a search bar, but that's not where I would think of going to answer the question "how do I iterate lines".
That's why I end up Googling and getting to Stack Overflow, full of wrong answers and someone named Shepmaster yelling at newbies.
Sorry, as I mentioned elsewhere I was in a meeting; I should have just waited to apply to you. It's true that "rustdoc" is overloaded, people use it to mean "rustdoc's output" which would mean the standard library docs in this case. My bad!
Please make sure to leave a comment and/or downvote any answers that are wrong to help people coming after you. I also apologize for whichever specific way I harmed you.
I understand why &str and String are different, but why do they act like they've never heard of each other? Why do they implement such different sets of methods? Why can't they be compared for equality, so I don't always have to type "literal".to_string()?
Haskell has problems with too many string types as well (worse than Rust, because the type of their default string literals is best avoided entirely), but they fix much of the problem with the OverloadedStrings extension, which uses the type checker as something that helps you coerce string literals, instead of arguing with you.
String gets all relevant str methods from Deref; it has some additional methods, but it should largely be shared.
> Why can't they be compared for equality,
Hm? They both compare just fine with ==.
I get why that's different, but it would be great if the type system could figure that out, so that the literal Some("foo") could be an Option<String> if necessary. Maybe I'm still being spoiled by Haskell's OverloadedStrings.
foo() -> Option<String>
foo().as_ref() == Some("str")But yeah, it would be nice if Rust had better ergonomics regarding coercing the insides of wrapper types. Though I'm not sure how exactly that would work.
There are pretty rough type inference issues preventing this impl from existing. Too many people are doing `opt == None` & the compiler would no longer be able to infer the type of None. (You should not be one of them, just call `is_none()` instead)
I'd like to see this impl some day but its not clear how to make it happen.
Maybe you were running into something else?
a.b().c()
let temp = a.b();
temp.c();
I love it. Short and simple, describes what Rust is. Between that and "an anti-sloppy programming language", pretty sure the marketing is there. Well done community leads, this is exciting.
https://en.wikibooks.org/wiki/Ada_Programming/Types/access#W...
There having a GC is perfectly fine.
If you need to write a library to implement the latest protocol, or render the latest image format, or parse the latest serialization format, then Haskell seems great. Unfortunately, the resulting library will be useless except to other Haskell programmers. Nobody wants to link in libXYZ.a and get the entire Haskell runtime, starting threads and doing GC and sending and catching signals.
I tried implementing a handler in postgresql so that you could write user-defined functions in Haskell. I made little progress, even with help on IRC and elsewhere. Any non-trivial function would need to define its own types and use some libraries, but it was far from clear how to do that and the best advice I got was to dig into ghci and try to use some ideas from that. I started down that path, ran into runtime issues, and that was the last straw and I ran out of steam. And that was only to get the most basic functionality: call into haskell to do some computation and return.
New products succeed based on how much better they are than the other solutions in their market. Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still beholden to backwards-compatibility, which makes it unable to adopt several of Rust's more interesting features.)
But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't.
And then Rust implements reference-counted pointers in the library, which is the slowest possible way of collecting some, but not all, garbage.
Honestly, if Rust is to become popular, it needs (a) to get rid of this elitist "we are awesome systems programmers" mindset, and (b) a good, optional way to use a GC where it makes sense, with good support for migrating away from it (i.e., by giving you a list of "I cannot determine the lifetime of this object, so it will be allocated on the GC heap" diagnostics on request).
Good cases can be made for having a no-GC mode, but having it exclusively is just premature optimization.
It's huge, but specialized so may not be on your radar: small embedded devices. Think RAM size from 10s to 100s kB, and Flash from 100s kB to few MBs as rough ranges.
The interest for IoT, and the need for battery operated devices with lifetime of 10+ years, make such platforms very important. And cost and process constraints (like embedded Flash) lead them to be implemented in conservative nodes: 55 to 40 nm typical, will go to 28nm in time but unlikely to go lower. So the amount of processing won't change much in this space I believe. An any gain would not be used to get a bigger CPU/RAM, but to reduce cost and power (less power is smaller batteries => cost too). So this space will stay on the very small side for the foreseeable future.
These are devices that run on very small micro-controller cores and are too small even for a striped down embedded Linux distro. It's either RTOS, or even simple run-to-completion preemptive schedulers, or even bare metal. No room for GC here, and Rust with its focus on performance, leanness and safety is very well suited as a language.
As a platform, the fact that there's only one LLVM based compiler for Rust is a limitation in this space. In the deep embedded space there are a lot of architectures for which there's no LLVM support (Cortus, Andes, BA Semi, LM32, Nios, ...). But I hope this as temporary. GCC is the most common toolchain there, and hopefully at one point GCC will gain a Rust front end. Or maybe LLVM will become more popular in this area? We'll see.
True, if you're talking about tiny embedded systems where you would not use GC (nor any dynamic allocation), you shouldn't have much difficulty using Rust. Nor many of its benefits.
If you write a library in C#, you can use it from .NET languages. If you write a library in Java, you can use it from JVM-based languages. If you write a library in Python, you can use it from Python. If you write a library in Rust, you can use it from any language that can bind to C, which is virtually every language that matters.
That is not a "vanishingly tiny" market. It might not be your market, but that's okay: Rust doesn't have to be for everyone in order to be important.
> And then Rust implements reference-counted pointers in the library, which is the slowest possible way of collecting some, but not all, garbage.
That might be the case if you were to replace the JVM's GC with reference-counting, but Rust enables a data layout strategy in which a lot fewer allocations of larger individual objects take place (because not every object requires its own heap allocation). This way, RC in Rust is probably not slower (maybe even faster) than the GC in the JVM, while having a lower memory overhead at the same time.
Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other.
> not every object requires its own heap allocation
Sure. That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were stack-allocable before.
But then you have to include a foreign language runtime! Together with all the headaches and interoperability complications that entails. How many .NET applications do you know which include a JVM runtime, or how man Java libraries include on the Python runtime? Now compare that to the number of applications or libraries (in any language) that directly or indirectly depend on a library written in C or C++. Rust will have the same advantage.
> That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were stack-allocable before.
My point is that a GC probably won't have a positive effect on most programs written in idiomatic Rust, therefore there's no need for it (contrary to what you claim).
Every significant C++ library I've ever used had its own stupid intransparent memory use conventions and invariants and segfaulted on you if you unknowingly violated them. The only difference is that you call some libraries "libraries" and other libraries "runtimes". I don't think that divide is all that sharp.
> a GC probably won't have a positive effect on most programs written in idiomatic Rust, therefore there's no need
It would allow new idioms that many people would find useful because not all code is code where performance is more inportant than clarity.
> (contrary to what you claim)
I didn't claim that Rust needs a GC to be Rust, I claimed that Rust needs a GC to be a more popular, more-widely-regarded-as-useful language than today's Rust.
Even if that's true (which I don't believe), tiny markets have a way of expanding when new offerings are available.
New people are getting involved in OS development in rust, for instance. We might see some really interesting stuff happen there. The same thing may happen with databases and rust.
And you didn't address my example, which was all of those "-devel" packages you need to install to get all of those libraries that so much software depends on: libssl, libjpeg, etc.
"Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market."
And this has what ill effect?
> New people are getting involved in OS development in rust, for instance.
Tiny market. Expanding it to be slightly less tiny doesn't make it non-tiny. More importantly, positioning Rust as an operating systems programming language will not get people to use it for more general application programming.
> The same thing may happen with databases and rust.
Also a tiny market. Also, not sure how wrestling with the Rust compiler will advance database theory or practice. Even more importantly, the implication (in the context of the thread) that it's impossible to write a database system in a GC language is false. To optimize the implementation, you may probably want to avoid GC in the innermost hot parts. That would be possible with the hypothetical Rust-with-optional-GC I mentioned above.
> And you didn't address my example, which was all of those "-devel" packages you need to install to get all of those libraries that so much software depends on: libssl, libjpeg, etc.
I don't know what exactly you mean by that since you even need those packages for C programming, and you need them (or something equivalent to the headers they provide) for Rust, but yes, language interoperability is hard, and yes, some language runtimes make it harder than it should ideally be.
> And this has what ill effect?
Many people will read stuff about OS kernels and database systems and vaguely elitist but never concretized ramblings about "systems programming", coupled with "OMG, everything must always be super-fast at the expense of programmer productivity" and decide that they are not in this market. And then they will keep using Python. Or, just to rub it in, Go for "systems programming" like NTPsec. <shrug> I never said that that's a bad thing; I just said that this will not drive more general Rust adoption.
I don't know if I'd pick Java as a comparison point because the ecosystem is unimaginably large, so it's hard to compare to Haskell/OCaml. A better one might be Golang or ruby.
I think ML languages just never made the case that other languages are bad enough for the particular thing someone is doing now, e.g. a web app. If you hit a NULL, you get an exception, track it down, probably not a huge issue. The best case could be made for ML on security grounds, but unfortunately nobody cares about security.
On the other hand, people were convinced that C/C++ were bad after decades of people saying so. But people didn't feel like they had an alternative until rust came along.
Rather, if you are in a problem domain like web-development or server-side microservices where a GC is fine, there are lots of decent options for programming languages. Python, Ruby, or PHP. Go. Any of the JVM languages - Java, Scala, Clojure, Kotlin. Swift or Objective-C. dot-NET. Many of these have had continuous attention over the last twenty years, they've got major corporate backers, and so a lot of the recent research in PL theory gets ported over to them.
If you are in a problem domain where you can't use GC - like computer graphics, games, databases, information retrieval, operating systems, or embedded - you have basically one option. C++. C++ has gotten a much-welcome facelift recently with C++11/14/17, but the core of the language is still 40 years old, and the language as a whole makes serious compromises (like memory safety) for backwards-compatibility. The excitement about Rust largely stems from its competition being C++; if you pit Rust against say Python or ES6 in the domains in which the latter are used, it's very much "Why would I use this?"
Then, I saw rust. I fell in love with it. It is indeed what I see as the future for one who isn't tied to using C++ or C from legacy, programmer-knowledge or programmer-availability constraints. I, decided that I will place my bets on rust and am willingly giving up all the investment I made in C++. If I am their target audience, then they've definitely reached me!
I wish more people knew this, because it's probably the thing most people try to install as it has the most downloads. It's no longer maintained and doesn't work correctly with current stable. There's a fork that is being updated that's just called "Rust" in the VSCode addons.
I highly encourage people to drop any MS misgivings and give it a try (honestly that was the biggest thing for me to get over).
Also, a nice history for UI native widgets will be a plus. This is ask a lot, I know.
Right now I have some projects where the less-worse option is .NET, swift if only iOS+Linux, Delphi is because cost (and free pascal is unfocused). Then obviously C++, but that is where I draw a line (ie: For a C-like language Rust is the only that look nice to me. I wish pascal instead or similar)
Because it compiles directly to C, I've found it reasonably easy to bring into different environments myself, though I've not attempted iOS yet :)
Edited to add: Also check out https://github.com/yglukhov/nimx
I saw the long awaited Non-Lexical Lifetimes tentatively mentioned in there, and I can only hope this will help move things forward, since it's pretty frustrating spending time fighting the borrow checker and refactoring correct code that really ought to run as-is.
Cheers and happy 2017 to the Rust project!
I'm extremely new to rust so I don't know if fighting the borrow checker is in my near future or something I will largely avoid.
I'm still learning Rust, but I thought the fact that you could have as many immutable borrows as possible would limit what errors the borrow checker could throw at you.
In penance, here are some links: https://www.reddit.com/r/rust/comments/5ny09j/tips_to_not_fi... https://m-decoster.github.io//2017/01/16/fighting-borrowchk/
I do find the image of "fighting the borrow checker" is quite harmful to how people view Rust. As those links state, an important aspect of teaching Rust is educating people about why the borrow checker complains, so that they might adjust their mental model.
- GTK is a painfull to install.
- Conrod: I was unable to do an hello world application with it. It just miss some tutorial.
- KISS-UI: some dll to install
- Qt: not totally free
- Neon to plug on Electron: I'm not sure if I can do some callback from Rust to the GUI with this method.
I finnally give up to play with Electron in javascript.
Also pretty bad on Windows AFAIK?
My personal wish would be for an easy way to use Servo to render the UI.
Qt has been free for decades and is LGPL these days, about as free as it gets. Is there some Rust-specific issue, or is this just decades-old FUD from the GNOME project?
Also no longer cross platform. LibUI (https://github.com/andlabs/libui) looks promising but I don't think the rust bindings are being worked on.
At the end of the day, the primary thing I want from my PL is to boost my productivity. In the kinds of software that I write, I can tolerate bugs and GC. Does Rust actually make me more productive?
You might want to rewrite that statement. Or at least clarify, what kind of software that you write that can "tolerate bugs" and what kind of bugs you're talking about.
1. I write many kinds of software, but specifically at that moment I was talking about web applications.
2. "Tolerating bugs" is true of literally every software, except maybe things that are proven to be correct in the mathematical sense. Web applications often have parts that may cause inconvenience if there is a bug, but data is not lost, productivity is not lost, and certainly no lives are lost.
If you want to remain relatively productive while building things that are one or more of (large, fast, safe), it's an excellent choice.
I can type reasonably correct code much faster than I can reason about how the program should work.
Compared to C++, Java, or even Go, it's anywhere from competitive to significantly better.
If you're using a language with garbage collection, it's obviously not going to result in segfaults, but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. More generally, if your object is stored in multiple places in your code, you have to remember to clean up all references to it properly, in all the different states your system can be in, and your compiler can't verify you're doing that correctly without a borrow checker.
> but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea.
Mostly I think this is sufficiently handled by not mutating shared state as a practice. However, since Rust has mutable borrows, it seems to me that you're still in danger of running into this.
For example, in C#, you need to Dispose() objects that are logically no longer used, to have them properly cleaned up. Using an object after it's disposed typically results in an ObjectDisposedException. This isn't as bad as a segfault, but ultimately it's still a crashing bug in the app - and solving it requires figuring out who needs to call Dispose when - i.e. figuring out the lifetime.
End result: This app spends about 30% CPU time on malloc/strdup/free.
In Rust, you simply wouldn't have this design in the first place because it's so easy to avoid. In C, it's super intrusive to fix once it's obvious this is a bottleneck.
Though this isn't necessarily a fuzzy concept of ownership, just more of a pain-to-deal-with thing.
However, what I still miss is bootstrapping from source. It would make porting to other platforms much easier. It confuses me that Rust is proclaimed as a safe language while anyone is forced to install a binary with wget | sh.
Can I create a Windows executable for Windows on Linux?
> Can I create a Windows executable for Windows on Linux?
Yes, but it's a little gross at the moment: https://github.com/rust-lang-nursery/rust-forge/blob/master/...
We do plan for all of this to be much, much easier in the future. Working on it.
> I've heard that it is ready and that it's not quite ready.
The foundations are strong, but the details are tough. So like, doing the cross-compilation is there, and is the simple bit, it's all of the stuff around it: linkers, other platform stuff, things like that. But the foundation to make all of this easy is in place. It just needs time and effort.
Rust has been putting much effort into "l33t features" in template land. I fear Rust may be going down the C++/Boost template metaprogramming rathole.
From that C++ thread on HN right now:
https://news.ycombinator.com/item?id=13584167 https://news.ycombinator.com/item?id=13583935
Call me skeptical, but I do not believe ADDING stuff to C++ is going to make it more competitive against Python in ease of use. Especially as programmers will still always be free to use all features, and any large enough project is going to end up with all of them.
Rand is a vocabulary crate (traits Rng and Rand are used for inter-crate exchange), so it's very sensitive to version coupling.
"vocabulary traits" like this are a good candidate for the stdlib for exactly this reason, maybe a good compromise would be putting _those_ in the stdlib, but leaving the implementation outside.
How would this interact with the orphan rule? Wouldnt this mean the vocabulary traits would not have default or std library type implementations and would have to be wrapped in newtypes, defeating the purpose of having them for inter-crate exchange? I guess you could wire types explicitly with Into/From in user code. Are there any traits unimplemented in std now that these vocab traits would look like?
fn random<R: std::rand::Random>(r: R)
I also might be missing something.
Rand is at version 0.3 and stagnating. I'm worried about 0.3, 0.4, 0.5. Those that have rand as a public dependency cannot release 1.0 now, if they do, they need to release 2.0 when rand goes to 0.4 and so on.
The Rust stdlib is mostly core abstractions and platform-dependent stuff.
Given that, why should they be in the stdlib? The rand crate is officially blessed and the one everyone uses.
* Are guaranteed to work correctly on all platforms where the language works.
* Will always work with the latest stable release of the language.
* Will be available under one single permissive license (with a single copyright holder (body) for any purposes of required notices etc.)
* Will be supported (security patches, bug fixes, etc.) with backward compatibility, more or less indefinitely (with reasonable long time frames for deprecation windows and recommended transition plans etc.)
* Are under no danger of being abandoned simply due to lost interest of the author.
* Crucial: Will only depend on other code in the standard library. (So all these guarantees are transitive!)
And anything that's not in the standard library usually implies there are no such guarantees. This is immensely more helpful and important than the comparatively trivial ease-of-installation.
If the Rust team really does explicitly extend such guarantees to non-standard library crates, that should be clearly and widely communicated. So far the focus seems more on how small the standard library is. What's the advantage for the language user? I see advantages for the Rust team, and mainly I see disadvantages for the (professional) language user. Easy-to-use cargo is nice (especially for casual language users) but is nowhere close to really making up for that.
https://github.com/rust-lang/rfcs/blob/master/text/1242-rust... has some of the motivation behind this.
According to that link, regex is also in the nursery. According to crates.io, regex depends on other crates maintained elsewhere, by a "random" single developer, under a different licenses, with zero obvious guarantees.
That person isn't random; they're on the libs team and the primary author of regex. (there are a few crates by other people as well, but most of those crates were extracted from regex as they can be useful on their own.)
I think it would be important to include in this pledge:
* Transitive closure rule. (No external dependencies not covered by the pledge. Possibly with certain exceptions e.g. for bindings to big known obvious third party dependencies like SQL databases or Operating Systems.)
* Uniform licensing rule. (Everything must use the exact same license, with a single group name as copyright holders and for any purposes of required notices etc.)
* Maintenance, backward compatibility and platform compatibility rule. (100% compatibility forever everywhere is not even necessary, but an _explicit_ rule of thumb of what reasonable time frames for deprecation windows and recommended transition plans can be expected would be nice.)
Or maybe this already exists and I'm just uninformed?
https://crates.io/crates/regex
(Regex moved out of the nursery a while back)
The nursery is more of a "These crates are officially blessed and we wish to make them part of rust-lang, unless the community comes up with something better".
The guarantees aren't advertised, they're known. We can do a better job of advertising this, some of the work this year is related to that.
I'm sure the Rust team knows and trusts these (or they even are Rust team members), but how should outsiders know this?
Researching trustworthiness of individual authors, getting approval for different licenses, tracking and updating required notices in documentation etc. for every single dependency transitively(!) seriously takes a lot of effort. Updating dependencies that switch sub-(sub-...)-dependencies freely can turn from a simple cargo command into a month of work. A big standard library (or an equivalent construct) can really save the day there.
> The guarantees aren't advertised, they're known.
It is known. -- Jhiqui
Glad to hear improving this is in the works anyway.
For context, I'm a Python programmer by day and well used to the comforts of its expansive standard library. From that perspective, splitting your stdlib into a first-class and a second-class stdlib seems weird, and I'm trying to make sense of it.
There's no inherent reason to put them in the stdlib aside from "other languages do it".
And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up people can switch to that; without being tied to the language version. These libraries will still be maintained, but may no longer be the recommended way to do things. Being outside the stdlib gives some liquidity to the crate.
This applies to your last paragraph as well -- I do want to be using code that folks are trusting to be the way to do things forever (well, at least for a few years). I'm not trying to learn yet another CADT language / ecosystem.
Also note that both crates mentioned in this subthread (regex and rand) are at version 0.x; to a not-really-a-rust-person like me, it signals "experimental API, avoid avoid avoid". I assume that is the reason to start a concerted effort to get everything to 1.0 levels.
(I'm mostly commenting because the roadmap under discussion seems to be heading towards the sort of promised stability that I want to see; so having somebody known to be rather close to rust development saying the exact opposite rather unsettles me. Sorry.)
> It means any code that uses the old (inferior) urllib continues to work,
Rust lets you have multiple versions of a transitive dependency in your project, so they would continue to work.
That being said, lifetimes and traits being both complex and unfamiliar features, there's always going to be quite of a learning curve. But one can always reduce the amount of papercuts. If nothing else, one can at least make the documentation better, the ecosystem libraries better and error messages even smarter.
It's old enough that it's before Rust 1.0, so some of the syntax is a _teeny_ bit wrong (int isn't a type any more, you'd use isize) but the macro picture is the same.