I'm pretty stoked about this. I've been following Rust since 0.4, and it's been super fun to play around with. I have two major problems with it, but none of them are Rust's fault -- purely flaws of my own:
1) I have no idea what to do with it. I'm primarily a web developer, and I really want to get into systems programming, but I have no idea what to do with it or where to start. I wound up implementing about 50 different Rosetta Code things in Rust 0.9 and 0.10, but I still never came up with a really solid use-case that I could start and finish.
2) Given that the last time I touched systems programming was in college (15 years ago), I've found it difficult to wrap my head around some of the concepts (ownership in particular). I actually hung out in the IRC chat room for awhile, but I felt more than a few times that people were treating me like an idiot because of my questions ("Ha! You did X? Why in the world would you do that??"), so I wound up not really going back. I'm sure it was all my imagination and that I'm just being sensitive, but I think it would be very helpful to have more people interested in getting new people on board -- specifically people like me, with over a decade of programming experience in higher-level languages.
I guess the TLDR of this is: I love Rust, but I don't know what to do with it.
Congrats to the Rust team, though. 1.0 is a huge milestone. Good job!
I'm in your boat, I'm a web developer who's always been curious about systems programming and has been following Rust as a way to get into the domain without all the tedious runaround and rampant paranoia associated with manual memory management. But, I still don't know what I should actually do with this knowledge now. :)
> I actually hung out in the IRC chat room for awhile,
> but I felt more than a few times that people were
> treating me like an idiot because of my questions ("Ha!
> You did X? Why in the world would you do that??")
Unacceptable. I'm an op in #rust (bstrie), so feel free to PM me their nicks and I'll see to it that they treat new users better in the future.
As a counter-anecdote, I'm in a very similar boat as the parent comment, and I have been astounded how consistently all the people in irc who definitely could make me feel like an idiot are unwilling to do so. It is a really refreshing experience after years of going into rooms full of arrogant people who actually don't know very much, as opposed to Rust's irc where everyone seems to know everything and are humble nonetheless.
I don't disagree! The vast majority of the IRC group was very helpful! I should have mentioned that in my original post. There was just one particular day where I was struggling with a concept and I felt like people were making fun of me and it just really made me not want to touch Rust for a few months.
But that's not really the point. I think the point is that there's a need for a sort of onboarding process for people who have never had to deal with some of these basic concepts. For instance, in web development, there's not a lot of need to know much about ownership or memory. The popular languages (Java, PHP, Python) kinda handle those things for you. So when you dig into Rust, you spend a lot of time thinking things like "wtf is a pointer?" and "wtf is a reference?" instead of actually building something useful.
That's a really frustrating part for me. I can build anything I want in PHP or Python or Java. I know those languages like the back of my hand, and if you give me a problem, I can solve it.
But then I start with a language like Rust, which concerns itself with all kinds of things I've only vaguely heard of, and then I'm completely lost. Super, super, super frustrating. It's a struggle to do a basic blackjack game -- something I could do in my sleep with Python!
So you don't know these concepts, which is already frustrating, and then you go into chat and you say "WTF is a pointer?" and hopefully people say "Oh, dude, it's so easy, imagine. you have this..." instead of "That's basic computer science, man. RTFM."
To be fair, I think Rust's documentation back at 0.9 was great. I'm positive it's way better now. But back at 0.9, it didn't answer the questions I had, which is why I had to go to chat in the first place.
But yes, most people were very, very helpful and I really did learn a lot. :)
If you're still stuck on pointers (although sounds like you eventually got past it), Kernighan and Ritchie have a very no-nonsense, straightforward presentation of the concept.
Of course, the basic concept of a pointer is not really that tricky. It's how to use them, what you can do with them, and how to avoid accidentally shooting off your foot with them that are the tricky parts.
Anyhow, if you know any other programmers who want to understand pointers, I don't think you can go too far wrong pointing them towards Kernighan and Ritchie.
I, for one, found the arrays and pointers chapter in K&R Edition 1 to be mostly useless (per my other comment in this subthread I used the Lions Notes). Do you know if it was significantly improved in the 2nd Edition you recommend?
I happen to have both editions handy. Some sub-sections seem to be 30%-50% rewritten. A big change is there are lots of graphics. 2e seems to be improved, but it's hard for me to estimate how much of an improvement it really is.
I scanned the first couple of pages again in the PDF, and still like the simplicity of the presentation, avoiding indirect metaphors ("a pointer is kind of like...").
I never got a copy of Lions, unfortunately. Seems a shame to not have more books in that style.
Hmmm, I read the first N pages of 2nd Edition of the chapter and it sure looks clear and good to me, and one area where I found it confusing looks like it was improved (but who can say 33 years later?). I won't make an anti-recommendation of this edition, but would be curious if anyone has problems with it.
So one obvious solution is to annotate a body of real code ... but in general you're suffering from trying to learn a moving target, and good documentation tends to trail....
That Version 6 UNIX(TM) was updated/reimplemented as Xv6 https://en.wikipedia.org/wiki/Xv6 ... maybe someone should do a pedagogical Rust version??? Maybe x86_64 and/or ARM?
"it baffles me people don't get pointers nowadays"
If you continue to be baffled in the face of consistent evidence then the problem is probably in you rather than in reality (or you're not actually baffled, but instead are feigning confusion as a way of projecting superiority). Honestly what's there to be baffled by? There are many programming environments that are both common and quite productive that have no pointers at all. I've gone literally years of my working life without touching a single pointer in production code.
That's an unusually harsh response I know, but I find this sort of attitude incredibly toxic, and it has hollowed out several communities I've been adjacent to. Some people know some things but not others. You can make them feel crappy by signalling that they are damaged or deficient, or your attitude can be positive and inviting.
> I've gone literally years of my working life without touching a single pointer in production code.
But you did use references, right?
What baffles me is how many young developers code without caring about the underlying infrastructure. Not caring to understand what makes their coding possible.
I have met many that deal with programming like car owners that just want to drive down to the supermarket, so to speak.
> You can make them feel crappy by signalling that they are damaged or deficient,
I explicitly stated I wasn't targeting the OP with my comment.
> or your attitude can be positive and inviting.
That is why I pointed out a few, quite good, books where the subject of reference vs pointers happen to be described quite well in a programming language that isn't as intimidating as C or C++, while allowing for the same type of coding.
One of them even shows how to build an entire computer.
A couple other people have jumped on this, but it's also worth pointing out the specialization that goes on in the field now.
For example, I'm almost exclusively writing web applications, and have been for years (coming up on 15 years soon).
Granted, I do know a bit of C and some other more systems-y languages (and more than a little bit about the underlying implementation of Python, which is the language I prefer to use), and I even know a fair amount of underlying fundamental theory, but... ultimately my brain is of finite size and I have only finite time. So I have to prioritize like everyone else, and choose what I will spend time learning and what I will devote brain cells to remembering.
The result of this is that there are things which, to someone outside of web development, would seem horribly arcane and irrelevant, but which I have to know, and as a result there are things those other people have to know which, to me, are horribly arcane and irrelevant.
And the further result is that when I see people wading into web development from other fields of programming, I often see them make mistakes -- sometimes big, security-hole-opening, money-losing mistakes -- that are on par with someone blundering into C with no knowledge of pointers, memory management, bounds-checking, etc.
So just remember that what seems hugely important and required-learning to you may not be to someone else, and that something which seems irrelevant to you may be hugely important required learning to them :)
The link to reference material was nice but what I'm hoping to draw attention to is about about tone. Your tone is scornful, judgmental, and aloof. If we worked together and I had a question on a subject of your expertise I might think twice before consulting you for fear of being dressed down publicly for my ignorance.
"What baffles me is how many young developers code without caring about the underlying infrastructure. Not caring to understand what makes their coding possible."
Our industry has many layers of abstraction, and there's always something to be gained by exploring more of the space (e.g. application domain, high level language, low level language, compiler, compiler IR, assembly, process, os, hardware apis, hardware implementation, electrical engineering, theoretical physics). However it is destructive to the social dynamics of a community when members scoff at or impugn the motives of those who do not know what they do. Both sides probably know things that the other doesn't too, why not learn from one another?
If instead of being content with being baffled with these colleagues of yours who are incurious about pointers, why not show them something cool that you can build with them! E.g. walk them through that elegant implementation of a hashmap in C that uses pointers to pointers from the front page of HN a couple of days ago.
Just saying you're not targeting someone doesn't stop them from feeling bad about not understanding something that is apparently obvious.
You have a different background to many programmers, is it unreasonable that they don't understand/know something that you do? It certainly doesn't make them stupid and statements like "baffled that people don't understand pointers" definitely imply that they are somehow deficient.
In any case, why does everyone have to care about in inner workings of everything they use? It seems perfectly reasonable for computers and programming languages to be things that people can use without having to understand the details, like cars, microwave ovens, aeroplanes, TVs, radios, analog watches, GPS (the list goes on).
> That is why I pointed out a few, quite good, books where the subject of reference vs pointers happen to be described quite well in a programming language that isn't as intimidating as C or C++, while allowing for the same type of coding.
Pointing out books is nice, but it doesn't make up for effectively abusing people who might need them: "read this to learn more" is way more pleasant than "I can't believe people don't know this, read this to learn more".
What baffles me is the number of programmers who use technology like cars, cell phones, fridges, planes, trains and advanced medicine without understanding what makes the underlying technology possible.
You don't do processor microcode or memory controller code, why should you care about that? People who work in managed languages don't care about pointers. I don't remember which register stores the result of a division either. Why should I care about it?
Except Java hasn't had them for 20 years and most Java programmers don't even think about how it takes 4 levels of indirection to just read something that would be a struct in C.
> There are many programming environments that are both common and quite productive that have no pointers at all.
This is a bit misleading. The vast majority of languages have pointers (languages without object identities exist - functional languages for example - but they are relatively the exception). However, those languages tend to give them other names.
What non-systems languages lack is pointer arithmetic and native notions of pointer-to-pointer (though it is always possible to simulate the latter).
I agree the person you responded to showed a toxic attitude. I believe/hope that the first step to improvement for people who think they don't get pointers is for them to realize they've been working with pointers all along.
The concept of references was introduced in my introduction to Java course I guess at the same time that the concept of objects were explained more fully. At least in Java, I feel that you have to understand the concept of references, to be mindful of aliasing, the fact that primitive values can't be aliased (I've tried twice to make a method to swap two primitive values, of course failing at that), and so on. Pointers don't really feel like a conceptual jump, coming from Java - the fundamental concept of indirection is still there. The fact that you can do pointer arithmetic and such on them, while error prone and harder to deal with than references, did not feel that hard to understand, conceptually. Granted, I have very little experience with C-level programming, so I be missing some subtle points.
There might be a difference for people who are used to languages which are more consistent than Java (like: "all values are really objects"). Do people not have to know about references in languages like for example Python?
This may largely be because we don't actually know everything, thanks to the fact that Rust changes so quickly that even the experts must constantly re-learn the language. :) But I'm very invested in maintaining that atmosphere of respect as we progress towards stability.
For 1, it's true that it's not clear Rust is going to be great for web development. http://arewewebyet.com sums things up. That said, Rust does run the backend of Crates.io, and I've been toying around with it as an Ember backend, so we'll see :)
2) I'd love to hear your thoughts on my new ownership guide, which landed last weekish: http://doc.rust-lang.org/guide-ownership.html thoughts very welcome, either here, email, or on the issue tracker.
Ownership is the one concept in Rust that hasn't really existed at the language level before, so it's the most unusual thing to grok.
> I felt more than a few times that people were treating me like an idiot because of my questions
Sorry to hear that. :/ We try to keep it 100% welcoming, but sometimes, people slip through the cracks.
> I've been toying around with it as an Ember backend
Care to divulge some of your experiences so far? Like others here, I'm a webdev searching for a point of entry in Rust, and seeing that there's web frameworks out already I thought they'd might work. I want to start a side project with a Backbone/Marionette front but have been wondering whether to use Rails (day job), Node, or now even Rust. Thanks.
Just saw your rustforrubyists...definitely going to follow that!
I haven't had the time to make it great, just hacking away.
> Just saw your rustforrubyists...
I appreciate the sentiment, but you probably shouldn't bother. Once I started working on the Guide, I stopped doing more than minimal upkeep on R4R. I consider it deprecated at this point. :)
I don't necessarily need web-based ideas, but I don't know enough about the systems programming ecosystem to have an idea of where to start! A text editor? A game? A virtual planetarium? Machine learning? I have no idea! (Like I said, not your/Rust's problem...)
There are a lot of web-based tools that have C implementations, so fun projects may include writing pure-Rust implementations of these. Imagine, say, the CommonMark markdown parser (https://github.com/jgm/CommonMark) implemented in Rust. Making it as fast as the C version would be a challenging optimization problem, but I bet it's doable. :)
I feel like the projects where where rust is best positioned in terms of comparative advantage fall into two categories:
1) Large and complex systems that are slow to evolve due to being written in languages that are unsafe or are relatively poor in abstraction (in addition to the immense domain complexity). Examples: SQL and/or distributed databases, Paxos-ish systems, Operating Systems, IDEs, GIS, etc.
2) Extremely high performance systems on the fringe of research. Examples: MIP/LP/CP/SAT Solvers, Theorem Provers, Formal Verification tools, Rete-based Rule Engines, Machine Learning algorithms and frameworks, Statistical Samplers for MCMC, etc.
Unfortunately (maybe, I don't really know if it will turn out well or not), most of the hype for rust comes from back-end web developers. That is fine...I'm sure there is some performance to eek out there...but it is also trying to compete in an area where garbage collection has its greatest competitive advantages (namely, long running server processes). The comparative benefit is relatively small.
> most of the hype for rust comes from back-end web
> developers
It may seem that way because 1) most of the hype for anything programming-related these days comes from back-end web developers, and 2) because back-end web developers are the primary audience of HN. At Rust meetups that I've attended I've seen interest in people doing video games, robotics, AI, numerical work, databases... they just don't have as public and excitable a forum as this. :)
I honestly wish we could get some of HN's mobile crowd hyped on Rust. A Rust-y take on Xamarin's ideas would be phenomenal, and with resource constrained phones, the performance gain from not having garbage collection or reference counting would be certainly welcome.
I suspect that crypto libraries and embedded systems might also be good areas for Rust. Basically anywhere that a buffer overflow or memory leak is a relatively high-penalty failure.
> compete in an area where garbage collection has its greatest competitive advantages (namely, long running server processes)
I thought it was the opposite that was true. A garbage collector can/will leak memory over time (days) and will use up to 6-8 times more memory and can have performance problems etc. All long running server processes I know of (database, mail, http servers) manage their own memory. Exceptions are VM based systems and it is not unheard of to have a trivial Tomcat app use up to 1GB of memory.
Here, I come from the Lisp world where PDP-10s had magnetic core memory, and a max of 1MiB (of 9 bit bytes) in address space. Lisp Machines used DRAM, but at least early on less than an address space (64MiB of 8 bit bytes), and keeping your working set inside that was an issue if for no other reason than GC by the time I showed up was incremental copying without generations (i.e. an increment of GC would tend to trigger a page fault).
So I assure people like sovande that this can be done correctly, even if it's convenient to "ship it now!" and later find out what's "leaking" (keeping unneeded stuff from the tender mercies of the garbage collector).
Think client side native apps. Like a cross platform layer for a mobile/desktop app suite. With web dev, you have the advantage of being able to accept the JVM's relatively long spin up time and it's resulting speed over time. You have the flexibility to use things such as clojure or erlang. Client apps can't accept that kind of restriction very well.
I know of many client side libraries that are in C++ because it works everywhere(tm). Being able to maintain them in something like rust would be far nicer.
Right now they are failing to build due to a recent breaking change, which made structs not implement Copy by default any more. The library is in active development, so that should be fixed soon enough.
Web developer here, i just srarted to write a interpreter for a small lisp, granted not system programming but I can still use the low level features to my advantage.
Its pretty fun, but im looking forware to stability too.
Writing a Lisp "in a week" (that would be putting most of your time into the project) is a classic thing to do, and while it indeed isn't exactly system programming, if you keep it simple (e.g. maybe limit it to atoms, lists and fixnums), but include precise GC, you'll learn a lot of things you need.
Hmmm, I've been wanting to learn Rust, but I always need a project to learn a language, and I haven't written a Lisp "in a week" yet ^_^. Yeah, thanks for the idea.
Well the project actually goes beyond just that, its a bytecode interpreter and I want to experiment with a JIT (something I have wanted to do for years).
Sadly its not working currently, I started a new job and Im moving so I had very little time the last 2 weeks and I didn't manage to keep up with the changes in rust.
You're a web developer, and you don't know what to do (in terms of how to spend your time) with a language geared toward systems.
That makes a lot of sense! At a certain scale, they're different types of work. It's like saying, "I'm a race car driver with a fighter jet. I've always admired them, but I'm just not sure where to fly!"
These types of languages, and more broadly any compiled language like C or C++, are very well suited to solve problems that your dynamic or scripted language can't solve at scale. Say, for example, as a web developer you built a website on Ruby on Rails that converts user-uploaded photos to morph, based on some algorithm, into a cute, unique photo of a kitten.
You have several concerns here:
- Processing the image, hopefully in the background so it's non-blocking and you can control resource needs.
- Storage. Is it on a local disk? S3? Something close by but on the network? If you have a performance bottleneck, is I/O an issue?
- Memory/CPU. How many resources are needed for n- jobs? Is it starving resources from serving additional web requests (really a separate concern, when you think about it!)
I would say for these types of problems (and this is admittedly a contrived example), Rails + some Gem or even pure Ruby might just absolutely suck and eat it.
These specialized languages can be a super useful tool for figuring out "simple problems with complicated solutions." They also offer the comfort of compiling down to a binary that might have no external dependencies (so, very portable depending on the compiler/runtime, and probably very reliable).
Is that the right thing for a pure web developer to play? Depends on the developer, but it's not surprising you're not quite sure what to do with it. It's possible you just don't have the right type of problem to solve yet.
That being said, Rust or Go are still fun to play with! Good for you for exploring.
That's exactly what I mean. :) A lot of the things I rely on for web development are so advanced under the hood that I don't even know where to begin. Like, let's say I want to write a tool that will let me take photos, resize them, crop them, add watermarks. I don't even... where do you start?
I wrote an LZW compressor in Rust 0.9 way back when, and it sucked pretty badly, but I wouldn't even know how to open a JPG or PNG, much less the mystical art of resizing it!
Call up graphicsmagick - either through spawning processes or binding to the library. All of those are solved problems, so if you don't have time/inclination to learn how they're solved, just use something that already did :)
> 1) I have no idea what to do with it. I'm primarily a web developer, and I really want to get into systems programming, but I have no idea what to do with it or where to start.
I'm thinking profiling some stuff and writing native accelerators, in Rust instead of C. More of an excuse than a need, but hey.
> I've found it difficult to wrap my had around some of
> the concepts (ownership in particular).
Have you tried reading the Ownership Guide (http://doc.rust-lang.org/guide-ownership.html)? I actually haven't read this particular guide myself (it didn't exist when I got started with Rust), but it sounds relevant :)
My main use for C code is embedded / bare-metal programming, so I was curious if Rust could run directly on ARM boards. I found https://github.com/hackndev/zinc but haven't given it a try yet.
I have found the IRC channel to be an incredibly supportive and helpful place, despite my barrage of dumb questions. I've been on IRC since the mid 90s and never seen anywhere so friendly, welcoming, and tolerant.
I'm getting less optimistic about Rust. At first, I liked that they were willing to make breaking changes pre-1.0 to get the language right. However, leading up to 1.0 they've decided to leave cruft in, in the name of getting the release out.
For example, the current build system is functionally equivalent to #including a bunch of C files in your C project and only passing one file to cc. I brought this up and had a long discussion about it and how it might be improved with the community, but then when core contributors showed up, the discussion was shut down with the justification that "1.0 comes in a month". I've heard other stories about poor management of the project and I'm just not as excited about Rust as I used to be.
I'm genuinely curious what you mean by "leaving the cruft in". I haven't been following the release discussions very closely, so I don't know exactly what "crufty" things there are in the language/standard libraries.
Also, on the subject of the build system, while I too found it a bit confusing, only passing in the "main" file and having the compiler automatically compile and link all dependencies, over time I've come to love that feature. Especially coming from a (admittedly amateurish) C background, where I had to explicitly compile all of my source files into object code before linking them together, having the compiler manage everything for me cuts down on a lot of mental overhead (in my opinion, anyway). I wish the process was explained a little bit better in The Guide, but that's a documentation problem and not an implementation problem, which is much more easy to fix.
> I brought this up and had a long discussion about it and
> how it might be improved with the community, but then
> when core contributors showed up, the discussion was shut
> down with the justification that "1.0 comes in a month"
Can you cite a source? If it was on IRC, I'm willing to sift through logs to find it for you if you give me your IRC nick.
> I've heard other stories about poor management of the
> project
What stories are those? We have our fair share of people who like to spread FUD, so I'm curious which one you ran into. :)
At no point in there is anyone that you're engaging with a part of the core team (which is to say: eddyb, zwarich, kmc, kimundi are all community members). So I still don't see how you can argue that the devs have shut you down with the 1.0 argument.
I also see that your proposal seems to be to add header files to Rust. What everyone there failed to mention is that Rust did use to have header files (called crate files, with a .rc extension), and we removed them to a great chorus of rejoicing. Rust is unlikely to tread that path again, after having discarded it once.
Thanks for looking that up. I was under the impression that at least kmc is a part of the core team from my chats outside of there (and because he was +o), but it seems like I was mistaken. He was certainly in a position to ban me to shut the discussion down ;)
As for header files, that's just one possible solution (and one that I think would work very well and was surprised to hear had been removed). The problems are there, but header files isn't neccessarily the right solution - it's just better to present a solution than to complain with nothing to suggest.
Heck, I'm +o in there too, but they'd be crazy to put me on the core team. ;) Imagine waking up in the morning to find all their precious semicolons, vanished...
(Personally, I agree that the module system is Rust's weakest point. I have yet to come up with any concrete solution for fixing it; it's a legitimately challenging problem.)
Well, operators have the power to direct the discussion and silence people they disagree with, which kmc has done. Whether or not that's abuse is up to you but it does put them in a position of power among decision makers in the Rust world.
At the risk of repeating some arguments you've heard, does that really need to be in 1.0? Incremental compilation doesn't destroy backwards compatibility (unlike, e.g., moving threads out of the stdlib), and it isn't a "showstopper" feature (e.g. unboxed closures), it's a convenient trick that can be tacked on later. It's hardly the sort of thing that needs to delay stability for the majority of users.
If it's about incremental compilation, this is indeed correct. We've talked about doing incremental compilation post 1.0 and the module system is irrelevant to whether that is possible.
Nah, there are plenty of reasons other than "mimicing C" to use a similar model. One example is incremental compilation - right now, you have to recompile an entire Rust project every time you change even one file. Like I've said before, I don't want to rehash this argument here on HN, so let's not get too far into it. I just want to make it clear that I'm not just pulling this out of my ass.
I'm... not sure what you mean by this. Something like #include technically exists, but is absolutely not used everywhere, and is certainly not the 'default build system'.[1]
That is one, very, very tiny aspect of the C preprocessor.
And https://github.com/SirCmpwn/rust-poc/blob/master/includes.rs... is significant: the code included from another file is under a namespace, and isn't going to clash like randomly throwing #includes around will, and you don't need to worry about things like double inclusion...
In other words, I think this is a very superficial comparison, and I'm not even sure why it upsets you so. Rust won't be a perfect language for everyone, and that's okay.
Well, you could move the mod { } to the included file to accomplish the same result (like the `namespace` keyword in C#), but that'd break the example I'm trying to give. I don't really want to rehash this argument on Hacker News, I'm just providing context. There are numerous flaws in the module system that derive from this basic point.
#include in C is just textual substitution of the contents of the specified file in place of the #include statement, there is not a concept of namespace in C.
I can't really effectively explain how all of this works without providing a lot of background on systems languages in general, especially background on how linking works. Sorry.
I too felt the management of the community contribution in the project was kind of poor. At least that's what I saw last year; now sure how it's now since I didn't follow it after my enthusiasm waned and moved on. I still believe Rust is a very promising project and wait for its final release before doing anything.
Unclear design/coding/development guidelines on contribution submission resulted in effort wasted in developing the contribution. Slow review process. Took more than a month and repeated requests to get a resolution. Arbitrary rigid design decision that couldn't be circumvented even when resulted in bugs. No channel for design decision escalation in the event of a disagreement.
At least that's what I've encountered before. May be now is better. The thing for community contributors is that we all have other jobs to do. After spent huge amount of effort in development and exhaustive testing and the review process went nowhere, I just didn't care to bother about it anymore.
Dang, that's a shame. I've generally had a good experience, and been impressed with the speed at which changes are reviewed and merged, but it only takes several instances to tarnish everything. If you can link to a specific issue/PR, I can pass it on. The team has been generally very good at fixing governance issues when they arise.
This isn't necessarily all bad, as people use it more this and OTHER problems will show up and will be worked out. As long as we don't get into HUGE breaks (like Py3) it's fine.
Well, it's been irritating for NPM to at least me. And presumably all the projects that have reinvented namespacing using dashes in their project names.
Agreed. At this point Rust is already looking rusty. A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool.
> " A solution desperately searching for a problem. We need something to replace C (so we are told), but maybe Rust won't be that tool."
As someone who works with Rust on a daily basis to implement a browser engine, I can confidently say that Rust is not a solution in search of a problem for our domain. As an example, I implemented CSS "letter-spacing" the other day, and it worked first try after compiling. The layout code I write has a remarkable resilience to crashes; in the rare cases that it panics, it aborts safely. And I get parallelism "for free" as I implement more layout features, because the compiler stops me if I'm about to do something non-thread-safe. None of this applies to C or C++, and the end result is that we can move faster and write cleaner code.
For what it's worth, I've been using Rust for over a year in my product (http://skylight.io) and it matched my needs pretty closely. Our product is a performance monitoring tool that runs inside of Rails apps, so it's important to us to keep the overhead of our "agent" small and controllable.
Since the agent runs inside of a Ruby program, our only good choices are Ruby itself or a language without a garbage collector (embedding a language with a GC inside a language with GC is asking for trouble -- take a look at the bug tracker for TheRubyRacer for some color). Our initial version of the agent was written in Ruby, but carefully controlling memory usage or performance in Ruby isn't really feasible.
We prototyped a new version of the agent in C++, but I personally didn't feel comfortable shipping a binary that would run in thousands of customers' Rails apps in a language that could segfault if you're not careful. We took Rust very seriously last November, even thought it was still very young, because it gave us a language with direct control over memory with compiler-verified guarantees that our program wouldn't segfault.
TLDR: Rust is a very good choice for writing performance or memory-critical code that will be embedded in a high-level-language.
Also, because it offers compile-time guarantees about safety, I expect it to expand the number of cases where people feel justified in embedding a low-level language for performance-critical problems.
I'm using Rust at my startup. The prototype version was written in F#, but that means you're anyways fighting memory allocation, which was the single biggest performance issue in my program. My system works on network traffic at line rate, so every allocation per packet is noticeable.
C programs doing what I'm doing have traditionally had security issues. Since our code often runs in privileged locations, that's an unacceptable risk. Plus, Rust is vastly more expressive than C and not messed up like C++. And abstractions are cheaper, too. For instance, we use Generics + Traits as a way to keep flexibility and a plugin model per frame, while keeping the performance of static dispatch. C wouldn't be able to do that in an easy way.
The C and C++ hate comes mainly from web developers and language hipsters. They dominate the echo chambers of HN and /r/programming.
When you mention you are a C programmer or like coding in C, they begin to blabber about C being legacy, Rust this, and Go that (languages they think are more like Python). All in an effort to cope with the insecure feelings they have because the C programming language and C++ (read: pointers) intimidate them.
> All in an effort to cope with the insecure feelings they have because the C programming language and C++ (read: pointers) intimidate them.
You have to know pointers and manual memory management to program in Rust. Rust isn't there to save you from having to learn about pointers. Rust is instead a reaction to the empirically observed fact that nobody [1] has ever written a multi-million-line program with a large team in C or C++ without accidentally making dangerous memory-management-related mistakes, and "just program better" is an approach that has been tried, and failed, again and again and again.
[1]: OK, maybe the Mars rover and the like are counterexamples, but the extreme amount of verification required means that this approach is far too costly to be practical for most software development.
Sure, Rust's goal isn't to convert all users of C everywhere. C is immortal; that'd be unrealistic. Our goal is indeed to exist alongside C—and to provide a more productive, more secure alternative. :)
Rust will replace C in some new development that would have been done in C had Rust not existed, and some existing projects may switch from C to Rust (presumably, by components, rather than as big bang conversions.)
But, sure, its not like C will disappear just because Rust 1.0 exists. But it's not like anyone, ever has argued that to be the case.
Definable not entirely true. I might be a language hipster (http://xkcd.com/297/) but I'm definitely not a web developer, except for back ends. The first time sharing system I used was a UNIX(TM) Release 6 system in the summer of 1978, and I started learning C after that, programming professionally in it starting in 1980. C++ in 1995, and I did several intense projects in it.
I loathe C++, think it's way too dangerous, and C is obviously dangerous. I really want something safer to do systems programming in, that's successful (pretty much every prior alternative has failed in one way or another). Maybe Rust will be that.
C++ is not a solution to anything I'm interested in (aside from the special case of perhaps wanting to use LLVM). If I was doing e.g. VLSI stuff that might be different.
C99 and C11 add a variety of nice things, but they don't make the language markedly safer.
How long have you spent tracking down wild pointer and using freed memory errors? Every have to convince your boss to spend $$$ on a hardware debugger to find one? (ATRON, back in the 8088 days.) Or look at Mozilla's very real world motivation for this project.
You hit the nail on the head but you didn't drive it far enough. You forgot to mention how those poor stupid little web programmers also secretly want to be awesome like you and that's why they keep doing this.
I do wonder if Rust 1.0 is being branched just a little bit too early. I understand that you have to draw a line in the sand somewhere, and the rolling release model means new features can be rolled out quickly. On the other hand, I'm rather disappointed that the ergonomics of error handling may change substantially after 1.0. This is something that is going to affect every single Rust program written, and people may be surprised if 'the best way' to do this changes after 1.0.
There's always going to be some feature that would make something nicer and that seems worth waiting for. At the limit we'd be holding off 1.0 until Rust has higher-kinded types (which has never had a concrete proposal nor is anyone really sure it can be incorporated nicely with the rest of Rust's type system), and that's a feature that would absolutely change the paradigm of error handling overnight.
The time is soon. I as much as anyone want error handling to be flawless, but I don't think that's enough of a reason to hold back the rest of the language. If we have to evolve our approach to error handling a ways down the road, so be it. Other languages have endured similar paradigm shifts.
However, this issue will be inherently subjective... all I can say for sure is, if nobody at all were saying "no, it's too early!", it would certainly be too late. :)
I do get that, but the distinction I'm trying to make between a feature like this and HKT is that you would expect changes in this area to impact practically every Rust program in existence, while the same is not necessarily true for HKT. Sure the changes can be made backwards compatibly, but it still means that the definition of 'normal Rust code' will be quite different, which people may find odd for a language that just hit 1.0.
Ultimately I do appreciate reaching 1.0 is a difficult set of tradeoffs and everyone has their pet feature they're sad isn't going to make it in. Bring on 2.0!
By far the biggest demand for HKT is from people who are requesting Haskell-like do-notation for error handling. HKT would affect everything! Given this, I absolutely agree with the notion that HKT is a 2.0 feature rather than a 1.0 feature.
> By far the biggest demand for HKT is from people who are requesting Haskell-like do-notation for error handling.
That hasn't been my experience -- we are constantly running into cases in the libraries where we need HKT to express signatures in traits. The simplest example is talking about iterator return types, which often need to depend on a lifetime. See the collections reform RFC (https://github.com/aturon/rfcs/blob/collections-conventions/...) for details on that example. There are many, many others.
I suspect that HKT's role in Rust will be much more about extending the trait system for generic programming, rather than full-blown monadic programming.
Thanks for posting this link. I struggled with this problem all yesterday, and hadn't realized that rust can't handle lifetimes over traits until you posted this.
Unfortunately without HKT you cannot model monads, abstractions that are useful for a wide range of use-cases, one of which is error handling.
In my opinion it is a pity that HKT wasn't there from day one. I had high hopes for Rust, because in comparison with languages like Go, it didn't take a stance like generics are hard, lets go shopping. And personally I can see problems with such pragmatic approaches, because such features have to be baked in, otherwise they'll either never make it or they'll suck.
And then we are back to square one - C++ and Java forever.
> In my opinion it is a pity that HKT wasn't there from
> day one.
I think this shows a misunderstanding of the genesis of Rust. :P Literally the only feature of early Rust that has survived to the present day has been the use of `unsafe` blocks to cordon off bits of code that cannot be statically checked for safety (I don't count things like generics as having survived from early Rust, because early Rust used Java-style virtual dispatch for generics rather than C++-style monomorphization (nor did it have typeclasses, because traits weren't conceived until later)). From day one, the goal has simply been to make a systems language that was safer than C++, and it's taken years to figure out how to do that effectively. And as a goal-oriented language, features are cheap: Rust has thrown out more features than most languages will ever have. The fact that HKT aren't there yet is because they're merely a nice-to-have rather than strictly necessary (in the way that lifetimes are strictly necessary), and because Rust has never particularly valued maximal expressivity in the way that e.g. Scala has. In the meantime, just because generic monads aren't possible doesn't mean that monads can't be approximated for specific types like Result and Option, and the lack of them isn't going to prevent Rust from its goal of being a replacement for C++.
We do plan to add some version of this RFC, but made a careful decision about not including it for 1.0. It will not completely change the error-handling design, but rather empower it with additional, finer-grained control.
It's possible that we will add at least the `?` notation to replace `try!` before 1.0 final; it remains to be seen.
Are they really ready for a 1.0? I'm looking at the standard library, and things (or core functionality of things) like file-system I/O, vectors, strings, _iterators_ … are marked as "experimental"; I was particularly curious as to how they were going to deal with iterators, since I think this is a particularly hard problem. (In many languages these are either pointers (C++) or close to it.¹)
I wouldn't really consider a language without a standard library "complete", and a good standard library is important to me in a language. (As it's going to help you get stuff done.)
¹Python, for example, doesn't specify iterator invalidation rules AFAICT; you just have to look at what CPython does. And in CPython, there are ways to make an iterator return a sequence of items that does not make any sense. (e.g., the same item twice, or skipping items…) In C++, invalidation is well-specified, but the compiler doesn't really help catch errors.
I completely agree that a strong standard library is essential, and we've been working very hard over the last months to set explicit conventions, revamp APIs, and generally get Rust's standard library into a 1.0 state.
You shouldn't read much into the "experimental" tags right now; they're part of an API stability tracking system that is heavily in flux at the moment. In particular, for most of the modules you mentioned, only the module name itself has not been marked "stable", while the contents have been. For example, if you look at the Vec type itself:
you'll see that most methods are unstable or stable, rather than experimental. (The "experimental" status is currently the default, to help us keep track of API "stabilization" progress.)
This stability tracking is part of our general story about API compatibility; you can read more at
These markers won't take on their full meaning until we ship 1.0.
For 1.0, all of the APIs you mentioned will be "stable", and indeed most of their internals already are. Over the next few weeks, we'll be updating stability markers to reflect the API scrutiny and design work that we've been doing.
More generally, for all but a couple of the modules listed at
we have already performed a detailed scrutiny of the API, and have either landed changes needed for 1.0 or will do so very soon. Most truly experimental APIs have already been deprecated or removed.
For IO in particular, you can read a very recent RFC that proposes the final set of API changes for 1.0:
1) in general, Rust 1.0 is about language stability. This means that any library not of quality will be pulled out.
2) this means Rust will have a small standard library. But we already have Cargo. So you end up getting lots of packages, they just aren't built-in: they require adding one line to a config file instead.
3) iterator invalidation is a compile-time error in Rust. Rust relies on Iterators quite heavily.
I worry about that too. In addition, I haven't seen any confidence that HKT can be implemented in a backwards compatible way, and that is one of the most-requested features (along with Async IO). I would hate to have to wait around for a 2.0 for this stuff.
The team has actually been pretty careful to design in a HKT-compatible way. While there isn't a fully-fleshed out design yet for Rust, there are designs in other languages, and we've looked at their pitfalls to make sure we can avoid them.
Can you elaborate? A panic is a panic, and it will either unwind or abort if unwinding is interrupted with a second panic. There's nothing silent about that.
If you do this:
spawn(proc() { panic!("hmmph"); });
Then "nothing" happens. The default, correct, behaviour for "unhandled" errors is to abort the program. Rust apparently thinks it doesn't need this, because "poisoning". Which is a great thing, except it still doesn't excuse silently swallowing errors. It's one way to end up with a half-dead process. And considering Rust's overall strict handling of errors, it seems bizarrely counter-intuitive to go with the silent route here.
The .NET team went through the exact same process and ended up taking a breaking change in v2 to fix their handling of background exceptions (so now they crash the app unless you opt-in to handling them).
Ah, I see, I wasn't aware that a panic in a child task no longer panicked the parent task. That was surely the case in older versions of Rust, but I have no idea when it changed. Thanks for the RFC!
Well it can't just panic the "parent" - the parent is an arbitrary thread running so you'd have to find a way to inject faults into the parent. I'm guessing with Rust's older task system, you could handle it there, since you owned the scheduler?
With the new, threads-only system, I think the only way out is abort.
It doesn't follow that it's not branching a bit early. Especially since the language five years ago bore little resemblance to what it is currently. I understand the justification that if Rust waits too long it will become irrelevant, but there are certainly plenty of reasons to think it should hold off. For example, the macro system is going to need to be completely rewritten after 1.0.
> I understand the justification that if Rust waits too long it will become irrelevant, but there are certainly plenty of reasons to think it should hold off. For example, the macro system is going to need to be completely rewritten after 1.0.
There are many, many people who have been waiting literally years for Rust to stabilize to start using it. (Just look at the comments in any other HN thread about Rust.)
Rough edges in the macro system (which can be fixed post-1.0 and doesn't need to be completely rewritten) and error handling changes aren't enough reason to force them to keep waiting. It would take years to get every single feature in that people want and it'd be doing a disservice to our community to force that huge group of people to wait even longer. And I feel it too—as someone who uses Rust every day, the issues that keep coming up are minor annoyances compared to the major pain caused by lack of stability.
Ha, we hate them too, which is why we're so eager to finalize their design so that we can replace all of that hideous garbage with just `impl Iterator`. :)
And who knows, it might happen for 1.0 if enough people push on the design and are willing to put in the legwork of implementing it.
Anonymized return types will sadly not be a blocker for 1.0, though they will be an enormously high priority post-1.0.
In particular, the biggest pain point for the lack of anonymized return types won't be the use case mentioned in that SO thread (which is heinously ugly and leaks implementation details, but at least it's possible), but will rather be the fact that without anonymized return types it will be impossible for a function to construct a closure and then return that closure without stuffing it into a box (though note that it will still be possible for functions to return unboxed closures if it accepted that closure as a parameter to the function).
Great to hear that folk are aware of this and that it's not considered a breaking change for a future release. Where is the best place to get updates on these kinds of features? I was following the github ticket until it closed and it wasn't clear where to go afterwards.
It actually does have the potential to break things, because to do this today requires you to explicitly list out all the types of the return type (which should really be considered implementation details). If a user of your function accidentally relies on one of these details, their code would be broken once you switch from the fully-specified return type to an anonymized return type.
Well, if you take advantage of it may break stuff. Although this doesn't really qualify as a breaking change since older code is going to compile when it's introduced.
Older code that uses specific features of that iterator will break. The slice iterator has its own methods (turn it into a slice), it's clonable and it is Copy.
It's only a breaking change to one's API to actually use the functionality, though. I don't think there's anywhere in std's public APIs where we would suddenly change from returning a concrete iterator to an "abstract" one.
The biggest question I have regarding rust-1.0, is what's the likelyhood of small/standalone binaries being possible? Last time I looked, while there was talk about lightweight core libraries on the website, but the basic hello world binary was 2MB+ and depended on a bunch of shared libraries. I spent a little time trying to figure out how to build static/smaller binaries without much luck.
This is incredibly exciting in that it means that you won't need to do any ceremony to link in Rust libraries from other languages (previously you had to opt out of the stdlib and reimplement lang items as needed). But it also means that static libs should be much smaller, due to no runtime being necessary (which should also make LTO more able to strip unused symbols, shrinking binary size further).
It shouldn't be _both_ 2MB _and_ depend on a bunch of shared libraries, it should only be glibc and libgcc. And you can make it smaller by asking Rust to do dynamic linking rather than static linking.
That must be under something other than windows. Rust on Windows definitely still has issues with static linking, dependence on gcc libs for 32bit exception handling etc.
Being able to build smaller statically linked binaries on windows is hopefully a priority.
As I said before, a dependence on libgcc and glibc are expected. It's not an issue with static linking, you don't generally statically link those two dependencies.
Is that expected to ever change and/or does Rust expect to work with other libcs (bionic? musl-libc?) Being able to build completely self-contained static binaries can be very nice at times, and for embedded use, glibc is pretty large...
I thought Rust used llvm for compilation? That makes the libgcc dependency seem a bit odd. Maybe I misunderstood?
Right now, it can't work with other libcs, but if you strip things down enough, it's not required to use glibc either, for example, if you're building an OS. You just end up throwing away a lot of the standard library. Check out stuff like http://zinc.rs/ for embedded Rust.
libgcc is used for stack unwinding, not for compilation. So it does seem a bit weird at first :)
Now Rust needs some killer app. Maybe a message broker, something like Apache Kafka, maybe even with Java Messaging Service compatybility as an option. Rust with its low level I/O and efficient memory management should enable creating something very performant.
1.0 only means "code that you've written against a stable release won't break on future stable releases". Rust will still be evolving quickly for quite a while, though we'll at least be free of this nonstop update-your-broken-code treadmill that we've been on for years. :)
So something that always holds me up with new languages: workflow.
What's a Rust development workflow look like at the moment, from editor, to reference materials, to debugging? I tend to be an IDE person (which obviously doesn't and won't exist for some time) so I'm pretty eager to hear how other people have been doing it.
I've only dabbled in Rust, but my setup for writing Rust in Vim is pretty similar to my setup for writing anything else: vim on one side of the screen, where I do my editing and type ":make" to try and build it (with Vim's makeprg configured to run "cargo test"). On the other side, a browser open to the Rust stdlib docs, and a terminal for interactive testing.
This is the biggest lie of all. Programmers have spent untold billions of man-years writing about code, how to write it faster, better, prettier, etc. and at the end of the day, it's not that significant. Code is ephemeral and has no real intrinsic value. The algorithms certainly do, sure. But the code itself isn't worth all this time (and shelf space! – have you seen how many books there are on UML diagrams?). The code, the performance and the features hinge on one thing – the data. Bad data equals slow and crappy application. Writing a good engine means first and foremost, understanding the data.
1) I have no idea what to do with it. I'm primarily a web developer, and I really want to get into systems programming, but I have no idea what to do with it or where to start. I wound up implementing about 50 different Rosetta Code things in Rust 0.9 and 0.10, but I still never came up with a really solid use-case that I could start and finish.
That said, I've been really impressed by rust-doom (https://github.com/cristicbz/rust-doom) and the new Iota editor (https://github.com/gchp/iota), and I wish I had the know-how to even start down that path.
2) Given that the last time I touched systems programming was in college (15 years ago), I've found it difficult to wrap my head around some of the concepts (ownership in particular). I actually hung out in the IRC chat room for awhile, but I felt more than a few times that people were treating me like an idiot because of my questions ("Ha! You did X? Why in the world would you do that??"), so I wound up not really going back. I'm sure it was all my imagination and that I'm just being sensitive, but I think it would be very helpful to have more people interested in getting new people on board -- specifically people like me, with over a decade of programming experience in higher-level languages.
I guess the TLDR of this is: I love Rust, but I don't know what to do with it.
Congrats to the Rust team, though. 1.0 is a huge milestone. Good job!