> It's a pain to get working, it sucks to program in, it requires so much though, it's just a bloody fucking fuck
What sucks about programming in Rust? What makes it a bloody fucking fuck? I disagree on both these points:
* Rust enums and move semantics make writing state machines a pure joy. Far nicer than in C++ or Go.
* Pattern matching (both fallible + infallible) is very developer friendly.
* Option<T> and Result<T,E> are totally brilliant.
* It's trivial to add and version-fix a dependency on an external library with Cargo.
* Rust's ownership and move semantics help you to write cleaner, easier to understand code.
People who say Rust is hard are probably skipping on reading the really well written Rust book. I'm not a genius in any shape or form, but I am able to write decent Rust apps just fine. I've written an IRC bot in Rust and am working on a file utility now.
It took me longer than 4 days (almost two weeks) to just read the rust book (part time), so yes you're not going to get from 0 to 100 in just four days. If that's your benchmark, how fast you can get going, then you're right Rust isn't for you. But nobody would expect anyone to get up to speed with C++ in just four days.
Rust is a systems programming language with a focus on security and performance, not a play toy for people looking to write small scripts.
> not a play toy for people looking to write small scripts.
IMO this tone or slights against Go will hardly endear Rust to people. Rust's superiority should stands on its own. Not just you I have seen this sentiment many times by Rust enthusiasts on reddit and elsewhere.
Go already has successful companies like Docker, CoreOS etc literally built using Go. There are 100s of companies using Go productively. Very large software like kubernetes, docker, etcd are written in Go and they are not toy scripts.
I encourage everyone in this thread to not take things personally. Rust vs. Go conversations are going to cause a lot of angst on both sides. I also encourage people not to assume or read into comments, where someone states that "Rust is not a play thing", they are not implying that Go is.
For some people who've spent the time with it, Rust is a godsend, but that does not mean that by believing so they implicitly hate Go in anyway.
Go clearly has a lot of people who love it as much as people who love Rust, and because they overlap, there will constantly be a conversation of which language to pick for cases where it looks like both could be used. As such, the learning curve for Rust will always be an impediment, to its adoption, which is sad, b/c in all my experience it's the only language that I've used which inherently answers every core issue or fundamental bug that I've encountered in my career. This is why I'm really excited that the Rust core development team has decided to focus on development experience heavily this year.
I did not mean to imply that Go is a toy language. The Go developers are very smart engineers and they made a great language. Sorry if it came across that way. I was more making a point about putting some effort into learning Rust. I did not mention Go anywhere in my comment but I understand why people thought I intended to slight Go. I didn't.
Adding a quick opinion here: I worked for one of these companies (working with libraries written by all of these) and it's just a matter of personal taste. Docker, CoreOS, Hashicorp, etc. are "successful" (which is hard to confirm for now) because they can gather a lot of open source contributions thanks to the easy Go learning curve. I don't think this would be the case if they used Rust instead. Go is definitely not a play toy and you can build scalable and reliable software with it. The problem with Go in my opinion is also its ease of use, it's incredibly easy to write sloppy/buggy code with panics/data races that become increasingly hard to debug. I've had my fair share of frustrating experiences debugging concurrent code with hundreds of goroutines or investigating random data races on complex distributed systems code. I've yet to see that happening with Rust after four months of using it, the compiler does an incredible job at preventing these.
While Go's frustration often comes from debugging sloppy concurrent code, the frustration with Rust is often about having your code to compile. But once it compiles, it runs beautifully. Some prefer the former, I personally prefer the latter. Also, I think the argument of increased productivity with Go should not be the main argument, because the time you save writing a large program, you will probably lose trying to debug a deadlock (which could still happen in Rust but harder to make happen) or a random data race that the race detector couldn't catch (or in a vendored library).
If I had to define the experience with both languages, Go is the instant gratification option, you feel productive quickly, the language is easy to learn with a forgiving syntax sometimes at the expense of correctness. Rust is the delayed gratification option, frustrating at times, very hard to learn and master but offering strong safety guarantees with an elegant syntax (which is a personal opinion).
Also it's a controversial topic in the Go community but the lack of generics...
Rust has its downsides too, for example the slow compile times or the lack of maintained libraries for some core functionalities but overall, programming with Rust is a much more enjoyable experience once you start getting ahead the learning curve.
One last thing: It is hopeless trying to learn Rust in four days without very good resources/books. I recommend "Programming Rust" from OReilly if you really want to dig into the language. It's incomplete at the time of writing but still one of the most useful resource out there (with the free Rust ebook). My knowledge of Rust dramatically increased after reading it and I felt much more confident writing larger programs.
Go is a language that is used to write on top of things. Rust can, maybe, be used to write the things Go are written on top of.
This sentiment (or slight) is the same as always said of C and C++, that they are used to make real things (systems and infrastructure, foundations), and the sentiment (and slight) is there because there's a lot of truth to it.
Which language was used to write our *nixes, windows, the biggest web servers (apache, nginx, IIS), haproxy, mysql, postgresql, oracle db, etc, etc? C/C++, of course. What else?
Docker is just a front end/abstraction layer for the features already in the Linux kernel (written in C). You can write, what's essentially just automation tools, like this in any language.
I don't think what you write in this post is a testament to any strength of Go. If currently there exist a testament to its strength it must just be the fact that it's used; adoption rate/popularity, although I have not seen the numbers.
> not a play toy for people looking to write small scripts.
That's actually a reasonable beginner's use for Rust though [0]. It's easy to do and will expose you to enough of the language to be a learning experience, but not so much that you could get badly stuck. And the benefit is that it's a lot easier to share binaries than it is to share scripts that rely on a particular interpreter being installed.
The big thing for me in this regard is not worrying about dependencies (in a lot of cases). With Rust, when someone asks me for a script that does X, I can compile and ship a binary and they run it end of story. With python, I say "ok, now install python version whatever, then install pip, and then pip install all this stuff, and finally run my script"
You could store them as source files with a hashbang, and make something like "rustrun" which compiles a single Rust source code file and runs the resulting executable? That should take ~15 minutes.
"being interpreted" in not enough to have useful repl. You also need to be dynamic and introspectable. There are interpreters for C, but it doesn't make it suitable to use with repl.
there's nothing bad about interpreting a systems language. there are C interpreters available, too. i'd argue it'd be a very useful feature since the compile times of rust are one of its biggest pain points right now.
There is a dead project named `rusti` (fails to build on Rust nightly >= 2016-08-01) that can interpret Rust source, and a newer project named `miri` (last commit 3 days ago) that interprets MIR output from the compiler. Several of us in the community, me included, would like a REPL, so I'd keep an eye on these projects to see if they go anywhere.
I've went through the rust book, unfortunately I learn better through actually trying to do things while looking at the API reference. And the rust documentation is frustrating for that, simply because everything is expanded by default and there's no concise list of functions available.
(In my case, I wanted to print out the name of the executable. Having to convert OsStr to something I can print, I understand - the filesystem encoding can be different from the console encoding. But it took longer than it should to find a path between the two.)
I never had to print an osstr yet but it seems fairly straightforward when looking at the docs? There are three obvious functions one could use, each for different use cases: https://doc.rust-lang.org/std/ffi/struct.OsString.html
os_string.to_str() // returns Option<String>
os_string.to_string_lossy() // returns Cow<String>, replacing illegal characters
os_string.into_string() // returns Result<String, OsString> - String if the data is valid, stays OsString for error handling otherwise
There are certain languages which are different enough from traditional semantics to need an explanation. While others are similar enough to be "obvious" if you've used a semantically similar language before.
To give a specific example, Powershell. It is semantically a very different scripting language from almost anything else in the market. Extremely well designed and powerful, but you'll want to sit down and read an actual book on how it works to get to handle on it because you won't have the mental map already to do so.
Overall this is why the programming language market is so predisposed for new languages looking and feeling like old languages. People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).
Yeah one of the best things about Go is how familiar it is, you can pick it up and run with it very quickly.
One of the best things about Rust is that it's a paradigm change, it takes time to get your mind around it but it is worth it if the language fits your use case.
> People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).
I'm not sure that's fair. It seems more likely that people who choose "boring" languages do so because they have things to build, and want to pick a language with a good risk/reward value. Not out of some academic interest or comfort calculation.
I think that focusing on how long it takes to be productive is a mistake, within reason at least. How well does it hold up once I'm knowledgeable with the language matters a lot more. If it takes me 4 days or 3 weeks to be productive, ok, that's fine, but it needs to be a good solution once I'm there, because I'll spend years using it potentially.
The really, really important thing about the time it takes to be productive in a language is selling the language to other people. If it takes 3 weeks to learn enough Rust to make interesting projects, then it's going to be absolute hell convincing a team of largely ambivalent co-workers to use Rust, because 3 weeks is equivalent to months of weekend tinkering. You're restricted to using Rust either when it has mass adoption, it interests your devs, or the domain needs provable safety guarantees.
On the other hand, if someone can pick up Go and produce a side project with two weekends worth of messing around, they're much more likely to be supportive of the language.
Obviously this isn't ideal, but I don't know how you'd fix the problem.
Do you really want people on your team who think that having to read a free book and investing 3 weeks to learn a new language is too much of an effort?
Firstly, when the initial impression of a language is that it's not fast to code in, people seem to assume that it will remain unproductive in regular use. This is clearly the case with ESR, and is a problem that's relevant to the Rust community in general.
Secondly, as per the Rolling Stones, you can't always get what you want.
Maybe they are spending those three weeks learning something else. There are thousands of things that "every programmer should know" and thousands more that "every human should know", and you will never have time to learn them all.
It may very well be out of your hands. I wasn't able to convince my coworkers to use Kotlin for an android app, even though at the end of the day I was the only one coding it. And Kotlin takes a few hours to pick up if you know Java.
If you've come from an ML background you'd need a good book to be productive in Go, and jump straight into Rust. Go is more C-like which makes it easier to pick up coming from C, not absolutely easier.
Do you have the sources for your IRC bot somewhere? I have a bot written with Ruby in a quite big channel and I have this tendency of writing it with a new language every couple of years. An IRC framework with Rust and Tokio would be fun...
I have the source, but it was more a process of me learning than something intended to be used by others. The source code is not online. It can read from a toml config and connect to multiple servers and respond to commands. It's pretty cool. I had it up at Github for a bit, I can put it back up, but this is an anonymous account so I wouldn't share it from my Github. I'm not sure how to share it. :\
Instead of writing an IRC bot, I have written an IRC client in Rust here: https://github.com/FreeFull/ircclient . Beware, I haven't put much effort into making the code clean or well documented. Writing an IRC bot would be easier than a client, because you wouldn't have to deal with reading from stdin, and you'd be able to keep everything single-threaded. The IRC library I use doesn't have any tokio support yet.
I could see how this statement could be construed as inflammatory, but I don't think he was implying that Go is a play toy. He was implying that you can't make a judgment on the language based on making play toys (the toy IRC client mentioned in the article).
Yes this is correct. I do not in anyway think Go is a toy. It's a fine language. I love kubernetes and it's written in Go. A lot of people took that statement to mean that I thought Go is a toy and I didn't mean that, so I apologize.
I'm learning rust now, this isn't even my first attempt. I know Go really well and C reasonably well and I can say Rust is much harder. If you want specifics: I can tell you that I've found changing a type from HashMap<String, u64> to HashMap<T: Hash+Eq, u64> within one of my projects to be extremely hard. I've read the rust documentation, and had to resort to reddit several times. I'm stuck dealing with mutable/immutable borrow issues to accomplish relatively simple tasks like searching for entries and removing them. In go these issues don't exist. I'm sure I'll figure them out eventually, and I'm a fan of rust, but it's a confusing frustrating grind.
My understanding is that the rust team has put 2 priorities ahead of everything else: zero cost abstraction and safety. Given those constraints they've done a fantastic job in the area of ergonomics, but I don't know if it will ever be easy. Maybe rust is as easy to use as it can be.
I can take a wild guess that T is a generic type defined on either the method, struct or impl in which this HashMap is declared. It's on the method/struct/impl. You don't necessarily need the type bound on the struct, but you do on the impl declaration:
Please don't hesitate to ask for help on #rust-beginners. I was in your situation last May, and hanging out on IRC was an excellent experience. Rustaceans, generally speaking, will bend over backwards to help you work on your project.
The biggest hurdle people seem to have with Rust is that it makes you very aware of the difference between stack and heap allocated data. For someone coming from a garbage collected language (or even in some cases C) that's a pretty big hurdle to get used to. I've found Rust to be amazing to work with, but it does feel like a struggle sometimes when all I want to do is allocate some structs without having to faff about with Box types.
Honestly I feel like peoples biggest issue with Rust is that they're trying to write things in Rust that don't actually need Rust. They want the ease of use that you get with a garbage collected language and then get annoyed when Rust forces them to worry about allocations and cleaning up after themselves. C++ should have the same issue but its been around long enough that most of those details have safely been wrapped behind STL and other abstractions to the point where most people don't need to worry about them. Perhaps in time Rust will reach that point as well and everyone will be using the equivalent of Boost that abstracts worrying about whether something is a Box<ARC<Foo>> behind a nonthreatening layer of macros.
Go has the same distinction (stack vs heap), but the GC means you don't need to care about the lifetime of the data.
To your other point, it saddens me that Rust isn't well-suited to higher level applications. You need very strict performance requirements before it makes sense to pick Rust over Go (you can squeeze a lot of performance out of Go, and even optimizing Go is friendlier than writing naive Rust IMHO).
I think this might depend a lot on how you approach Rust. I find the functional/procedural mixture to work nicely, and find I'm much more productive in Rust than Go (or Python or Java, modulo available libraries). I'm writing web services and code generators, so not particularly low-level code.
I've written a decent bit of Go, and I understand why a lot of people like it, but I don't think it's inherently better for application development.
Maybe, but I think your case is atypical. I came from a C++ background, so I'm well-acquainted with navigating a huge feature matrix and thinking about memory management, but I'm still much more productive in Go simply because the feature matrix is always very small and I only need to think about memory management in hot paths.
I want to be comparatively productive in Rust, I just never seem to get there because of the huge volume of decisions (even if the decisions are mostly easy) that need to be made for even straightforward code units. I think what I really want is Rust lite, or Go with generics and abstract data types.
I could absolutely be atypical; prior to using Go and Rust as my main tools, I primarily wrote Scala, and I'm sure the functional and type-driven approaches have left deep grooves. But that would still be a way of approaching working with Rust, wouldn't it?
None of that is to make a value judgement, just an observation; but I would still argue that the language can be used in a highly productive manner. Nonetheless, it's perfectly reasonable to argue it's not worth adapting to it, especially if Go is already solving your problems and keeping you productive. I switched because Go's design doesn't seem to fit me very well, and I continually tripped on issues that I don't encounter in Rust. (So yes, perhaps I'm quite odd.)
I do understand the want for a Rust-lite; the thought has crossed my mind more than once. So far, Swift seems closest in many ways and may get close once the Linux/cross-platform story starts looking good.
> I could absolutely be atypical; prior to using Go and Rust as my main tools, I primarily wrote Scala.
I'm not saying Rust is easy, but I have also a long Scala and some Haskell background which made it easier to learn Rust. For me the hardest part was that I've never really wrote any proper C++ or C, although I could read them quite good. Refereneces and RAII caused some gray hairs, the type system not that much.
> I just never seem to get there because of the huge volume of decisions (even if the decisions are mostly easy) that need to be made for even straightforward code units.
Well this is true for all languages! You need to think hard for every decision you take with languages like Ruby or Python. Things like how will this look like after a year, will the junior developer be able to extend it, will there be data races and so on.
Rust just enforces you to do this. And it makes life much easier when you don't need to worry about some silly mistakes you made, because the compiler will catch them.
Rust has a brilliant solution for some really burdensome issues that C++ developers have. A lot of C++ code tends to make assumptions about ownership and lifetimes that are not formally spelled out anywhere in the code. It's all over the place, it increases cognitive load, it makes the code brittle and less modular than it could be. Rust fixes that without negatively affecting performance whereas all C++ workarounds like shared_ptr and defensive copying are incomplete and/or have a negative performance impact.
But Rust also insists on enforcing its ownership rules between variables within the local scope where it doesn't help much and feels needlessly restrictive and convoluted. I can't say I know Rust well enough to tell whether working under these restrictions can become second nature and stop being a burden.
Also, users of garbage collected languages don't have many of the ownership and lifetime issues that C++ developers are forced to think about. Especially where objects are immutable, ownership is not a concern at all.
So I think Rust is an answer to one question: How can I have detailed control over resources like in C++ without inheriting all the hazards of C++ as well.
While I agree that programming necessarily involves a lot of decisions, I hope we can agree that there is a spectrum of complexity among programming languages. My point is that the likes of Rust and C++ introduce a huge volume of decisions that wouldn't exist in a simpler language, like Go. That said, if you think all languages are as complex as C++, I'm not sure we can agree on much...
Yes, it does have the distinction. From your link:
> When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors.
As you can see, Go uses both the stack and the heap; however, unlike Rust, it doesn't require users to know where their variables live to write correct programs.
I believe, the distinction that orclev mentioned was that in Rust, you specifically have to be aware when something is allocated to the stack or heap, but in Go, you don't have to since the compiler deals with it. Obviously Go allocates to both stack and heap, it's just that the user doesn't need to know which.
Fair enough. I simply meant that Go's semantics let you reason about what lives on the stack vs what lives on the heap much like you can in Rust (though in Rust it's clearer still because there is no escape analysis at all). While you don't need to know from a correctness perspective, you can reliably reason about what will live on the stack vs heap in a way you can't in, say, Java.
No, you can't really reason properly about what lives on the stack. As the Go FAQ say, you can safely assume a variable will be allocated on the stack if you never take a reference of it, but that's not always clear as it seems. For instance, if you call a method on your variable, you can't immediately know by looking at the method whether the receiver is by-reference (pointer receiver) or by value. If you're using a pointer receiver, the variable's address may be taken, so the compiler has to perform escape analysis.
Once you take the address and escape analysis is performed, you've got no way to easily reason about what's on the stack vs. what's on the heap, without delving into the gory implementation details which may be changed in future versions.
Since Go isn't C++ and doesn't have a huge and complicated standard that guarantees compiler optimizations, you can't really reason about what's going on.
This is essentially the same situation as Java, although the Hotspot JVM's escape analysis is probably less 'basic'.
That is one reason to choose Rust, but that is far from the only reason to prefer Rust over Go. I've found that algebraic data types and pattern matching have become irreplaceable parts of my programming toolbox, to the point it is painful to work without them. Rust also has a powerful macro system that Go cannot match.
This is not to say that Rust is better than Go in every way, but performance is far from the only facet when I compare the two.
> The biggest hurdle people seem to have with Rust is that it makes you very aware of the difference between stack and heap allocated data.
What do you base this belief on? I'm very comfortable with C and assembly. I am very certain I understand the difference between stack and heap allocated data, but I've found lots of other hurdles in learning Rust.
One difficult aspect of Rust relative to Go must surely be generics and trait bounds. This is something it shares with Haskell and Scala. For people coming from those languages (like myself) the stack/heap thing is the most salient.
> One difficult aspect of Rust relative to Go must surely be generics and trait bounds.
Conceptually this isn't bad at all. I understand the value and mechanism of specifying the required traits for types to a generic function. However, I just posted an example elsewhere in this discussion where there simply isn't a trait for the method I want to call. That was certainly a hurdle for me, and the workaround wasn't satisfying.
I mostly understand the semantics of borrowing mutable vs read-only references, and I'm pretty sure I understand the purpose and value of the concept. However, specifying lifetimes is completely different than any other language I've ever used, and I've used a couple dozen languages over several decades in my career. I haven't gotten past that hurdle yet.
> the stack/heap thing is the most salient.
I'll stick with my statement that I understand the stack and heap well enough (from a C or C++ point of view), but composing Box, Cell, Ref, RefCell, and friends is a non-trivial hurdle.
Theoretically yes, for a C/Assembly programmer you're aware of the difference between stack and heap allocated data, BUT the cognitive load is different because those languages don't differentiate them in a particular fashion, it's all just pointers and offsets at the end of the day. Rust on the other hand, because of the Box type makes it very explicit where exactly some piece of data lives. It's also relatively uncommon to stack allocate any kind of larger structure in C or assembly, almost by default that kind of thing is done in the heap, where Rust makes it really trivial (default even) to do so on the stack even though that's rarely the correct decision.
Depending on your background there probably are various hurdles to overcome in learning Rust, I'm not discounting that, but the most uniquely Rust one is the stack vs. heap issue, particularly since that combined with issues around shared state are the sources of most of the headaches you'll run into when fighting with the borrow checker. Pretty much every other feature of Rust is similar enough to another language that if you have experience elsewhere you won't find it particular troublesome. References are easy to understand if you know C/C++ (and to a lesser extent C#). The type system is easy to understand if you know Haskell or Scala (and to a lesser extent JavaScript/Python). The generics system is pretty much the same as Java, C#, Haskell, Scala, or C++ (and probably others).
Rust IS a complex language, but it also provides a unique feature set and has some fairly unique goals. IF you need or desire the features Rust provides, pretty much ONLY Rust is going to get you what you want. C, C++, or Assembly potentially can deliver the same functionality, although it's questionable whether their ergonomics will be better or worse than Rusts for a given task, and they almost certainly will be more bug and error prone. Rust lets you have all the fine grained performance tweaking (or just plain low level access) you can get with C/C++/Assembly, while also giving a strong peace of mind that your code is correct and error free. It's also arguably easier than C++ although that comparison is a bit Apples and Oranges, C++ has a great many years of tweaking and experimenting behind it so things like Boost go a long way towards providing something like a most optimal (from a ergonomics standpoint) C++ experience that ignores all the languages pitfalls and sandtraps. Rust on the other hand has just barely hit 1.0 and the community hasn't even discussed, let alone come to any kind of consensus on the best way to tackle various issues yet. Rust will get there in time, but it's still early in the process and it shows.
Bottom line, if you need the features Rust provides, but aren't comfortable with how young the language is and want more hand holding, C++ (or maybe C) is probably the language you want. This isn't to say Rust is a bad language or you shouldn't use it, I think learning and using a new language is reason enough and the certainty Rusts type system and borrow checker provide is a very strong argument in its favor, but you need to be aware of what you're signing up for when you make that decision.
> the most uniquely Rust [hurdle] is the stack vs. heap issue
I can only speak for myself, and I politely disagree. So far, explicit lifetimes (both the syntax and the concepts) seem like the most uniquely Rust issue.
> [if you] want more hand holding, C++ (or maybe C) is probably the language you want.
Heh, if you think C++ holds your hand, I'm not sure we're on the same page. What I know of C++ was hard-won after reading many books and fighting with the compiler for many years.
Sorry, it wasn't exactly clear from the context but by hand holding I meant more in terms of the resources available. C++ by its very nature has tons of great libraries, tools, and various kinds of documentation. If you can think of it, someone has most likely written a tutorial about how to do it in C++. Additionally there have been entire forests worth of books written about various facets of C++. Rust in contrast has few libraries, fewer tools, and little to no documentation for most of what it does have. This isn't to say Rust is bad, it's simply new and building up documentation takes time.
> [...] Rust forces them to worry about allocations and cleaning up after themselves. C++ should have the same issue but its been around long enough that most of those details have safely been wrapped behind STL and other abstractions to the point where most people don't need to worry about them.
Also, C/C++ comes with the venerable "kill the process GC" that makes it easy for beginners and other mortals to feel good about code even when it not strictly is good. Rust is all about making that kind of quality mandatory.
Well, let's see. I was following rust's development for a while, but waited until 1.0 when it seemed it might be kind of stable. All that trivial and obviously correct code turned out to be a kind of wrestling match with the compiler. Far from a pure joy, it was rather frustrating. Set it aside for a while, but then came back recently figuring maybe I'd take another look but instead of starting from scratch I'd pick an existing project and poke around with it. First project I looked at had a requirement that one use the nightly compiler check out, but not just any nightly, specifically the one from last Tuesday. Then I looked at another project, and this also required nightly, but this time it was the one from the Thursday before last. Fuck. This. Noise. I'm not learning a language where every project requires a separate compiler.
That's basically an artifact of the combination of Rust's immaturity and its conservative stability policy - once a language feature or API is supported by a stable compiler, it needs to keep working more or less forever. So a bunch of features still require nightly, so some projects target nightly, and the big ones may pin to specific nightlies. But the amount of breakage is vastly lower than it used to be (especially pre-1.0), and even in the year-and-a-half since 1.0 a lot of different bits have been stabilized, so that sticking to stable Rust no longer feels like being handcuffed. The biggest unstable feature left is compiler plugins, which should get a rudimentary version stabilized Real Soon Now. With that and maybe specialization in place, there should be little reason for projects to stick to nightly.
I'm totally fine learning the borrow checker. It's a investment I see value in. Even if it's just in me learning about solid rules for sharing variables. But that nightly shit you describe is scary as fuck and makes me very concerned about the future of the language. Post 1.0 this shouldn't be an issue!
There are a couple of fairly popular libraries that were nicer to use on nightly Rust (serde and diesel), but could otherwise work on Rust stable. The "nicer to use on nightly" is going away with the next stable release of Rust. Other than that, the vast majority of the ecosystem is on Rust stable.
Unfortunately "the next stable is the one you want" has been the story for quite a while now. Since this is ostensibly a thread comparing with go, I'll note that their story is more like "the next release will be better, but don't wait for it".
> Unfortunately "the next stable is the one you want" has been the story for quite a while now.
I don't recall anyone ever saying this, where "the one you want" means "the one that supports procedural macros".
We have had this discussion for a very long time, and it has always centered around serde and diesel. Those have been the biggest nightly users since 1.0, and probably before then.
> Unfortunately "the next stable is the one you want" has been the story for quite a while now.
Not really. serde and diesel have been more convenient on nightly for a long time now. It is only just now that we can say the "next stable" because that's when the particular feature they need will be stable.
> I'll note that their story is more like "the next release will be better, but don't wait for it".
I can't wait to use Go's `sort.Slice` function[1], but I'll have to wait for the next stable release.
Seriously though, I'd say the key difference between Go and Rust on this venue is that while Rust is stable, there's still more stuff we'd like to add. To that end, we encourage experimentation by making the acquisition of a nightly Rust compiler really easy. This naturally leads to people experimenting with nightly and publishing crates that either use it or require it. This is a necessary part of experimenting with new features and getting feedback.
Go's scope for experimentation is much smaller. Their changes are much more incremental and conservative. It's a really nice benefit of using Go.
My point is: this is a trade off and it should be presented as such. In Rust land, it requires that you---the user of Rust---ignore crates that require nightly or ignore features of crates that require nightly.
I consider libraries using a nightly Rust to be proofs of concept, not actually usable tools. This might be possible in the future, let's push these features to the stable Rust and maybe we could have this kind of libraries in the future.
I always use stable compiler. Never had a need for nightly.
The main blocker on stable was a feature called "custom derive" or "macros 1.1" which will be stabilized in the 1.15 release in February. At this point any library tied to a specific nightly is using some extremely cutting edge features.
I feel like every other crate I've run into claims to require nightly.
In reality, they often work perfectly fine on a reasonably-modern stable, and simply haven't updated their documentation and READMEs to indicate "oh yeah, this nightly feature is now in stable, so just use a stable that's newer than version so-and-so".
> Until they don't again because clearly the authors have no interest in being on a stable compiler release.
Then use an older version of the package. Unless the package in question was relying on some "nightly" feature that never made it into stable, then you should be fine.
I'm not convinced the problem will just go away. Not as long as people are obsessed with the new hotness language features that require a compiler from the tuesday before last.
Cargo also makes me wary. How do I know what I'm choosing is any good, and if it is will it still be around next year. Nature of 3rd party libs I guess.
Cargo doesn't require that you use things from crates.io without vetting them. It's possible to, say, write everything yourself, or only use specific crates that you've decided are good (whether that's by reading the source, or only using the ones published by the Rust developers, or some other criteria) and even go as far as explicit pinning to specific versions of them in your manifest (although this isn't particularly necessary: Cargo pins versions by default, and won't upgrade without you explicitly asking for it).
The problem really is that you have to vet them at all. With golang's standard library, it's all going to be supported to some degree. (I believe the same happens with rust's standard library, it's just much smaller.)
Basically, some people like having a curated library set; others do fine without and are happy to find things to use. The former set doesn't like rust as much in its current state.
The crates published by the Rust developers themselves seem quite similar to the standard library for this purpose. (But, yes, things like this are not as discoverable as they should be; it is one of many things people are working on.)
Welcome to the downside of version pinning. Now that we have version pinning, developers don't need to make versions forward compatible. Misery is when one program needs packages which use different pinned versions of something. There's probably some namespace hack to allow that.
This is compiler version pinning. At least .toml files don't support that. Yet.
Do you really expect any project to have nightly builds that are forward compatible? The whole point of regular development builds is to have a place to test and do experiments... which is pointless if every experiment needs to be supported forever.
The "namespace hack" in Rust is having the "stable" namespace: a compiler that rejects all unstable code (and is forward compatible), so that people don't accidentally get pinned.
If someone wants to pin to a specific development version (of anything), there's nothing the project can do about that, other than being closed source and only publishing stable artifacts. Tooling like rustup that makes it easier to pin means that people who choose to experiment can still use stable by default (easy to switch back) and that others can easily collaborate on the experiments, both of which seem like strict positives.
Perhaps another incarnation of the rule that work expands in response to productivity improvements. You can improve efficiency, but instead of saving work people will find more ways to create new work.
I went through a similar experience in Haskell. It is worth going through until you get to the point where it is no longer a wrestling match, because then you are just as productive but any code you write is checked much more thoroughly than in a more weakly typed language.
> Fuck. This. Noise. I'm not learning a language where every project requires a separate compiler.
It's right now, with 1.0. Just don't use libraries that require nightly. Libraries are not the language. The language is stable. If your requirement is stability, then use the stable version of rust with stable libraries. That's what I do.
Are you unfamiliar with semver and the promises it makes?
This is a rhetorical question, as there's no way you've been around here so long without knowing what it is. For everyone else, however, the notion is that code written for 1.0 will continue to work for additional 1.x releases. It says nothing about iterating on not-yet-baked features--that's what nightly is for, and as they become baked they become part of 1.x releases. They're not breaking backwards compatibility; the major version remains the major version.
Touche! I remember a place where I worked where the first version was 3 because they figured customers wouldn't trust a version 1. I guess these guys went for version deflation.
I talked to burntsushi last week about stabilizing SIMD in Rust, and he says he's got about to release an RFC very soon. :) Due to this, I'm hopeful that stable SIMD will land this year.
How does move semantics make writing state machines better? I can understand powerful enums, but I'm not familiar enough with move semantics to envision what you are referring to. Do you know of an example available somewhere?
Nice example. I was learning Rust over Christmas so I see how it works. But one issue I have is that from the outside it's not obvious that your `close()` method will take ownership of `self`. I'd probably prefer it if there was some (compiler-enforced) convention that made it obvious to clients that `close()` would consume `self`.
As it stands, Rust code can break the principle of least surprise, since what happens in a method can affect the associated instance variable (in this case `open_socket`). A user could easily write several lines of code and only discover that `open_socket` has been moved into a method at compile-time.
I found myself having very small coding-compile iterations when writing in Rust to catch issues like this (but that was also undoubtedly due to the fact I was learning).
> it's not obvious that your `close()` method will take ownership of `self`
I'm in the middle of reading the Rust book right now, so this may be dumb, but... Isn't this exactly the point of using a naked `self` instead of the reference `&self`? If it's not a reference, `self` is consumed by the method. At least that's my current understanding
If you mean that the one-character difference is very small for such an important semantic distinction, I might agree.
As for the state machine example, I like it a lot as well. It's very similar to the idea of "making illegal states unrepresentable" from the OCaml world: http://fsharpforfunandprofit.com/posts/designing-with-types-...
(This particular post is F#, but the idea is general.)
> Isn't this exactly the point of using a naked `self` instead of the reference `&self`?
Yes it is, but you only see it's a naked self if you look into the method. From the outside there's nothing in the name to indicate that it doesn't take a reference. So potentially it means that for every method call you need to check that it takes a reference to `self` instead of ownership. This would be especially annoying with third-party libraries.
The alternative in other languages is the error (using a socket that has been closed/resource that has been semantically moved away) is only found at runtime. The compiler flagging a mistake like this exactly the point of having the compiler and is a great example of how Rust helps defend against mistakes. Compiling early and compiling often is a great way to develop, IME.
In Rust, I personally don't think about moving vs. not until the compiler tells me I have to, because it usually doesn't matter. Rust previously required moves to be explicitly marked, but it wasn't worth it in practice: http://smallcultfollowing.com/babysteps/blog/2012/10/01/move... (see "Wait, doesn’t this make it hard to know what your program does?" in particular.)
Sure. It is a private field(no pub) preventing you from constructing that type with a literal. It is of type "unit" '()' so it does not add up space for the type. "unit" has only one value that makes it "zero-sized". because i did not supply an "constructor" to that type it is not constructable outside the module and can only created by types in the scope of the enclosing module. Its more or less a private constructor known in C++/Java ... etc.
If a struct is public, and all its members are public, you can just create a new instance of the struct with braces (in that case, it would be `OpenSocket { data: 12 }` - or whatever value you like), not what is necessarily correct. By having a hidden zero sized struct member, you need to use the library's api to construct them.
It ensures that you consume a state at most once. You can kind of visualize state 'moving' through your functions - going in through the arguments and out through the returned value.
All but the last point will make your code easier to understand and program with. It's not an appeal to emotions at all - those are exactly the features I liked about Rust, and wish more programming languages had.
What sucks about programming in Rust? What makes it a bloody fucking fuck? I disagree on both these points: