The amount of hype Rust is getting is not going to end well for Rust. This reminds me of Ruby during 2007-2010 where it went from Patron Saint to Scapegoat for every startup that failed using it. Ruby survived it, and I'm sure Rust will too, but that doesn't make it obnoxious for everyone else who inevitably gets swept up in the craze and crash.
Programming is hard. Programming will always be hard. Better/newer tools (and sometimes influences from the old finally making it mainstream, like Standard ML) make programming easier but not fool proof. It's misleading and harmful to hype the crap out of any language.
Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well.
The echoes of Golang hype right now are somewhat ominous. A few years ago it was "concurrency primitives are going to change your life" and now it's "lifetime/ownership primitives are going to change your life."
I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement. But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before. I suppose we can consider them fortunate for not having to do systems programming while suffering through implementing their own reference counting and garbage collection semantics.
A few years ago it was "concurrency primitives are going to change your life
Those, plus the total package of tradeoffs in Golang did for me, in terms of implementing a game server. The whole package really is game changing for what I'm doing.
I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement.
There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel?
But at a certain point, a lot of the reason for the hype is that it sells these solutions to newer developers that haven't had exposure to these concepts before.
Luminaries of our field have been lamenting for decades that programming forgets its own history and discoveries. Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study?
If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.
Maybe we should make it de rigeur that people relate their "inventions" with past art? A lot of times, when I point out past art, I get met with instant open hostility from younger devs. Is it any wonder that programming has the attributes of a popular medium, not a field of engineering study?
[...]
If young coders want to be the future intelligentsia and harbingers of a better kind of programming, they need to foster a set of subcultural norms that best leverages collective knowledge. Programming has to become a field that remembers its own history and can learn from its mistakes.
Graydon has consistently pointed out Rusts influences, indeed it is one of the reasons behind its name - ie. 'rusty old ideas'. But the influences of the creator are not enough. We need to promote the value of a historical perspective in our discourse, and so I I'm glad for your post. As a young developer I see it in my peers, but even sadder I also see it in my mentors and elders. So often there is two extremes of fervent excitement and lack of imagination that things could be better beyond ones own experience... both borne out of a lack of historical literacy.
That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better. But perhaps they could get better faster with fewer steps backwards with a little schooling on the foundations of our field.
That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better.
Not always. Pry debugging Ruby can be pretty awesome but still often leaves a lot to be desired compared to the VisualWorks Smalltalk debugger+environment. Then there's the One Laptop Per Child project. How many developers were trying to recreate things that already existed in Smalltalk? What if they could've freed up the developer power wasted in that wheel reinvention? Seriously, a lot of the advanced state saving/rollback features would've just come for free in Smalltalk.
>Not always. Pry debugging Ruby can be pretty awesome but still often leaves a lot to be desired compared to the VisualWorks Smalltalk debugger+environment. Then there's the One Laptop Per Child project. How many developers were trying to recreate things that already existed in Smalltalk?
How many Smalltalks were not closed source and with commercial IDEs and toolsets?
Squeak. That would've been enough. Smalltalk doesn't have an IDE in the traditional sense. The browser is a very small, thin app on top of the meta level and libraries.
>"That said, I don't mind reinventing the wheel in new ways - every time our wheels get better and better. But perhaps they could get better faster with fewer steps backwards with a little schooling on the foundations of our field."
You may be interested in Graal/Truffle. One of the main aims is to make it a playground for experimenting with programming language design by reducing the work that goes into the underpinnings of these new languages. It's also meant to offer fairly decent performance.
> There's something wrong with programming as an entire field
Look at all the research and prototyping in aviation. What's weird about programming is the amazing longevity of experimental ideas vs. heavily engineered products.
>There's something wrong with programming as an entire field. Don't other fields figure out ways of not reinventing the wheel?
No. In fact even in the actual field of "wheel manufacturing", we have been re-inventing the wheel since for ever.
Those who don't like "re-inventing the wheel", would they rather use stone or wooden wheels for their cars? Or perhaps some of the crude early metal ones? Or they rather use the re-invented modern mix of alloys and plastic?
I think you'll find a lot of Rust's supporters actually come from a Systems Programmers background who've felt the pain before.
I've been doing C/C++ for close to 15 years now, I find that the borrow-checker not only helps with safety but also with guiding a good architectural foundation. Nothing keeps you from dropping into an unsafe block and cranking out very c-like code if you want as well.
All my green-field code now is Rust. Sure there's some hype but that's because people are genuinely excited about the language.
I have too but I don't see any magic in Rust's borrowing beyond what you would get with using shared_ptr, weak_ptr and move semantics in C++11. Yeah there is a certain class of errors that the Rust compiler will check that will still give you a segfault in C++. But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effective in either Rust or C++, or Golang, or C99, or what have you.
Rust is actually much closer to unique_ptr than shared_ptr or weak_ptr. The use of Rc is pretty small in practice.
The thing is that even with unique_ptr I can easily reach in via get() and I've broken the shared mutable state contract. It's trivial for me to trace what modifies things in Rust, I just follow the 'mut' annotations and since only one thing can hold it at a time it's very straightforward.
Rust also has one the best package managers I've seen. Union types which are the best way to represent states and state machines bar none. An iterator class that's the best I've seen(seriously has anyone actually used <algorithm>? How man begin/end pairs do I need?).
Plus the community is super-welcoming, there's more reasons but those are my top ones right now.
>But it doesn't get around the programmer still needing to have a firm understanding of RAII and the difference between the stack and heap in order to be effective in either Rust or C++, or Golang, or C99, or what have you
Who said it does? And why would it have to?
It'a just about catching those "certain class of errors that the Rust compiler will check that will still give you a segfault in C++".
Plus a nicer looking language, with a more modern design.
The more strict static checking in Rust means that the compiler can actually be a teaching tool for concepts like RAII and the heap/stack difference: it flags and explains places where the programmer is doing that doesn't make sense in those settings. A lot of effort has been put into the compiler diagnostics to make this compiler-is-a-teacher concept a reality.
For one, additional safety. Rust's equivalent are more safe. Secondly, speed. Rust has several advantages: with shared_ptr, for example, you have the Rc/Arc split, the decreased number of refcount bumps, etc. (some of that speed comes from the safety, even...)
Rust is aiming for more than an incremental improvement. Take Servo, for example. The goal is to provide a generational leap in rendering engines, and while it's not done yet, the initial results are promising.
I agree that "salvation" is a bit much, though.
For whatever hype Go had and may have, it's still a resoundingly successful language that's building meaningful stuff that improves people's lives. Sounds like a success to me.
I don't personally divide my life into "before move semantics" and "after move semantics" - but thanks to move semantics, I have to anyway. And I feel like I'm all the better for it.
>I am somewhat disappointed that we still feel the need to create entirely new toolchains and rewrite everything just to support what should be an incremental improvement
Any ideas about how to add this small "incremental improvement" of Rust-like safety to C, for example?
If we were betting money, I'd put mine on Golang over Rust just because of the piles of money and effort Google keeps pouring into it. Rust is a little cooler, but I just don't see Mozilla having enough resources to keep-up the momentum long-term.
I don't see how Google is really putting piles of money into Go. In fact, in terms of maintainership and porting I'd say collectively that many other companies are investing more in Go than Google. What can you point to as piles of money?
Perhaps not that much by valley standards, but I'm sure just the salaries of Rob Pike and Brad Fitzpatrick alone would amount to more love than a lot of languages get.
Go's not been receiving any piles of money from Google. Compare Go's API documentation to Rust's API documentation. Where's the `cargo` and `rustup` equivalent for Go? Compare the number of Go packages to the number of Rust packages. Seems Go's not doing so great despite being stable for much longer.
> I just don't see Mozilla having enough resources to keep-up the momentum long-term.
Did you forget about Samsung? Mozilla and Samsung aren't the only two companies backing Rust.
No argument on superior, it's just that superior doesn't win the day. Look at C++. Look at JavaScript. It would be surprising if the industry made the better choice for a change.
Hmm--with some edge-case exceptions that never got a strong push outside of some niches (Ada comes to mind, where it achieved some traction in DoD circles), I wonder if C++ wasn't the superior choice given its time and place. By no means is it perfect, but in the early to mid 90's there weren't many competitors with a similar feature set that had anybody pushing hard behind it. To my mind it seems not dissimilar.
If I have to write native code, right now it'll be C++ precisely because it's able to express complex problems with a high degree of getting-it-right (because while I would never claim to understand C++, I feel confident in my understanding of the subset of C++ that I use). I really like Rust and look forward to it being a better fit for what I want to do, and every time I look at it it's getting closer.
> Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well.
I don't think that the language creators are behind this in this instance, more over-excited users continuing the hype cycle. I definitely agree that it does a disservice to the language. I posted this on /r/rust[0]:
> Please don't push the hype train to far - our language, tooling and strong community does a lot of work to sell itself, and we will get a backlash if we are not up-front honest about Rust's problems. Ruby and Go are experiencing that now. Some languages are better than others especially in specific domains, but even the better ones are not silver bullets, and Rust is no different. I use Rust for some things because I feel the trade-offs are worth it.
Do you have any suggestion to maintain hype at a reasonable level? Basically, a lot of people are excited about it, a lot of people are writing good libraries, and they blog about them, which feeds into the hype cycle.
I think the main hype danger for rust right now is that the number of killer applications written it will fall short of the hype. But the linked article is from someone writing redox-os, so it's hard to criticize this article specifically for contributing to overhype.
Ruby had the opposite problem, which is that a lot of people were writing amazing applications, but it fell down technically (applications got messier and slower; or at least that is the perception). In theory the same thing could happen to rust, but it seems less likely.
As Alan Kay says, we have moved from a technical community to a pop driven one, so these hype cycles will never end while this mentality carries on.
Having said this, Go got its killer application in the form of the main language driving container implementations.
Rust might eventually get its one beyond the current browser implementation and get adopted by an OS vendor.
Just with Apple doing Swift, Microsoft .NET Native and C++/GSL, maybe it is left for Google and their Fuchsia project or an embedded OS vendor to do it.
Programming isn't hard, it is super easy. Most of the things we ask machines to do are sequences of simple steps. It's so easy in fact that children do it successfully with little training. Programming well can be hard but only because of the limitations of our current tools. Rust is a good step in the direction of safer systems programming and the people who are hyped about Rust are the smartest people in the room, just like with Bitcoin when it started.
That's like saying painting isn't hard it's easy. Children do it all the time with just their fingers. Painting a Mona Lisa is hard but only because we don't have good tooling.
It's a vast oversimplification of the real issues while ignoring the reasons programming or are hard.
I agree. C is fast because it can be unsafe. Skip all the safety checks and run like hell (if you need or want to). We don't care what size that array is, we just want to go really fast. Safety checks come with a performance cost. Rust claims to be faster than C and safer than C at the same time. That's not possible.
>Rust claims to be faster than C and safer than C at the same time. That's not possible.
Of course it's possible. Say you would fork gcc (or clang) and teach it a few extensions for the C type system that allow some more safety checks at compile time (for example something similar to Rusts borrow checker). Since those checks don't change the generated code, you now have a language that's safer than C, but equally fast. Now you add some language primitives that make it easier for the compiler to understand the intend of the programmer, making it easier to optimize the code (there are already plenty of opportunities used by C extensions, like signaling that some if branch is unlikely to be taken. More opportunities exist if you modify the language more heavily). Now you have a language that's both safer and faster than C.
I don't want to make any claims about Rust performance in practice, I haven't run enough benchmarks for that. But it's perfectly possible that the statement could be true.
>Rust claims to be faster than C and safer than C at the same time. That's not possible.
It's actually entirely possible. For example it's how Fortran has been traditionally faster than C, by not allowing for aliasing (which is also an unsafe feature) it can give the compiler more room from optimization.
"Integer between 0 and n-1 inclusive" is the type of valid indices for an n element array. The trouble is most languages don't have type systems that allow expressing that.
Even when you can't prove what arbitrary code does, proving what well-written code does is useful, and not writing unprovable code would be a small price to pay.
That's just not true. C (in the hands of average programmers) is limited because it's not very expressive. There's no way to say "these 40 things can be run in parallel" or "run these 200 things asynchronously" in a standardized way. Very clever compilers can infer some autoparallelization situations, but I'm not away of anything that can auto-async a project that's not explicitly written that way.
That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do.
Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.
Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but they're hardly unique in that respect.) Go has a runtime that makes it cheap to spawn lots of threads, but it's not doing any super high level optimization or abstraction either (quite the opposite). I don't know about Erlang.
Captain Obvious here with a public service announcement:
Rust's safety guarantees dont extend to logic or protocol implementation problems or misconfigured security settings.the part of the article about service providers leaking creds or other info...Rust all the things and that will still happen.
Some of this stuff is just too much. Also, why not work on lifetime and memory safety in a c based language? Rust looks like Klingon to me. functional-ish-ness is really hot right now. (Like Hansel.)
There's this really sophomoric theme that this seems to be a part of that keeps resurfacing here. its almost like a conspiracy of influences made the wrong tech choice in the past and everything would be ok now if we used X. Where X could be haskell, rust, os2, plan 9, lisp, lisp, lisp, go...theres quite a few saviors out there they resurface every now and again.
Some libraries use such features to prevent certain kinds of nonce-reuse during encryption (one of the more common ways of screwing up encryption). These constraints are checked at compile-time.
Such guarantees are not possible with weaker type systems like that of C.
I get what you are saying. "Software's Salvation" might require more than compile time type checking.
I'm a huge strong typing fan! I'm just saying, type systems can get you a long way toward correct construction. (Or correctness by construction...) The issues with the software/computing world are bigger than array bounds checking and type correctness.
> The issues with the software/computing world are bigger than array bounds checking and type correctness.
Annoyingly, these bugs still bring down our systems in an age when we're on the verge of self-driving cars. Can you imagine that? Your car can crash because somewhere a programmer messed up a simple bounds check.
By removing the possibility of these small annoying bugs, you leave the programmer free to focus on the big picture. That is the entire point of abstraction, and a language which strives to provide these abstractions at no cost to performance is inherently better than one that
a) doesn't provide these abstractions
b) doesn't provide mechanisms to handle the unabstracted layer safely.
Rust isn't the only solution. There are mechanisms that can be used in C++ to make a program memory safe by construction. I'm not even saying that Rust isn't a good solution. (I am saying I don't like the syntax...I'm sure I could get used to it at some point.)
I just get very wary when something has this kind of "evangelism" behind it. That's all. I'm really looking forward to seeing what Mozilla does in Firefox with it.
The disconnect you two have is that C++ doesn't force you to always use those safety features. Furthermore due to reasons that are entirely non non-technical in nature will never force you to use them. The reason Rust exists is to solve that problem and the result is that an entire set of bugs, that have plagued developers in the target C++ domain for ages, are literally impossible.
ADT's have been known to be a superior way to express state machines for ages but C++ for both technical and non-technical reasons will never actually get them. Rust solves this problem by starting over.
The best defense is a good offense. What is scaring all of the Rust developers and users so badly that they feel the need to go on such an offensive hype campaign?
It's worse than the phase Java went through when it hit its peak.
I'll be honest. Until we start seeing some more balanced (frankly, I'd settle for nuanced) discussion about the compromises made to get Rust's strengths, I'm staying the hell away from it.
>It's worse than the phase Java went through when it hit its peak.
As a person who lived through the 1990s Java hype and had a bookshelf full of the official Java books (Addison-Wesley white books)[1], the Rust evangelism is nowhere near that level.
To refresh the memory, 1990s Java evangelists predicted:
1) C/C++ would become obsolete because in the age of abundant desktop resources (cpu power and more RAM), the GC would take care of all that
2) Java's "write-once-run-anywhere" JVM would render the Windows operating system obsolete and weaken the evil Microsoft
3) Java applets so you could create rich dynamic websites in the browser
As we now know, none of that actually happened. Java is still a success but it couldn't match the breathless press it initially received.
Yes, this particular Rust blog promising "salvation" seems to defy Fred Brook's more conservative "no silver bullet".[2] But relatively speaking, Rust's enthusiastic community is fairly tame.
Many of those failures were more political than technical.
For example, the internal wars between Windows and DevTools divisions at MSFT, were the biggest reason for Longhorn's failure.
MSR with Midori has proven the viability of using C# for systems programming, when no politics are in play and everyone is focused on technical improvements.
If you follow the OP of the comment there is another view being presented.
There are lots of conspiracy theories about what went wrong, regardless how much truth each one has, the real matter is that politics played a bigger role than technical issues.
What scares Rust developers and users so badly is the incredible amount of wildly unsafe software that already exists, and all the new wildly unsafe software being written.
> Until we start seeing some more balanced (frankly, I'd settle for nuanced) discussion about the compromises made to get Rust's strengths, I'm staying the hell away from it.
If all you see about Rust is what hits Hacker News, you're probably not going to see much of that. The narrative about Rust's safety and the terrible state of software engineering today and dangers of all of the existing C and C++ code is a strong one that resonates with a lot of people, and so posts about that are likely to be voted up on HN. Posts about how Rust isn't a perfect language and has some flaws, well, maybe not so interesting, because every language has flaws, so there's nothing all that noteworthy there.
Also, FWIW, the post you're commenting on is written by someone who believes what they're saying in the post so strongly that they're writing an entire unix-like OS, including kernel and applications, in Rust. So it's no surprise that they're talking about what excites them about Rust and why they're using it to write a whole OS, rather than any flaws it might have.
Not sure why marketing Rust implies that the community is trying to defend it. Honestly, I enjoy sharing with my experience with Rust because I personally enjoy writing in code with Rust and want to share that with others! Nobody is saying Rust is perfect or doesn't have tradeoffs.
Err, the title of this article is "Rust is Software's Salvation". The previous one was "Rust is mostly safety". No discussion of trade offs, no negatives to be found. From the original article: "[Rust is] Technology from the past come to save the future from itself"
> Not sure why marketing Rust implies that the community is trying to defend it
The original article was a call for marketing material, because they don't feel enough people are using it. Those people are, to paraphrase the sentiment from the comments in the first article, wrong for thinking they write safe C or C++ code.
The original article that kicked off the 'Rust is mostly safety' article was a call for a change in the marketing material[1], away from the 'Rust is safe' narrative. It's not an attractive narrative (IMO) and the point that Klabnik was making was that Rust is more than 'just' safety.
'Rust is mostly Safety' was written in a sense disagreeing (depends on your interpretation) with Klabnik's article that Rust is much more than safety. Now, yes, these posts (namely the 'Rust is more than safety' and 'Rust is mostly safety' are not discussing the negatives of rust, absolutely, but it's not the scope of the posts to do so, it's not what that particular discussion is about and they should be exempted from this broad brush.
You've taken a quote from the Klabnik post, which is itself quoted from an initial release announcement, which is basically guaranteed to be a spot of marketing. As always, there is a time and a place for the discussion of trade offs and negatives.
A release announcement is not the place for this.
Nor is a discussion of changing the tone of the marketing of the language.
Now, finally turning my attention to the article in the post...well, that strikes me as a place to discuss some negatives. I am not super comfortable with basically listing all the cons of C and well, not even discussing the pros of Rust but presenting it as a panacea.
I think it doesn't quite hit the point of Klabnik's article which to me was more about stopping marketing based on what Rust stops you from doing and marketing Rust more on what it lets you do.
> The original article was a call for marketing material, because they don't feel enough people are using it.
This is absolutely not true. I would love for Rust to have more users, but that's because I love Rust, and want to share that with people. But really, just like we try to make software better, I'm interested in how to make our pitch better.
You would think Hacker News, of all places, would understand that.
And this is getting nauseating even to these wanting to give it a try. I'm in the step of walking away and forget about it until the dirt settles down (and it becomes at least as fast as C/C++ or... even Go)
I was competing against some C and C++ software developers in Advent of Code with efficient solutions, and my Rust solutions came out faster each time. Might want to check your facts.
Since you chose to be cute, I'm going to take a guess that you think this means the comparison between the tools is unfair. If that's an accurate interpretation, then I will say that your question is irrelevant because ripgrep is faster or as fast as GNU grep on benchmarks using a single thread too. In fact, that's the whole point! It says so right in the project's README.
Ok, interesting analysis. I will look more on Rust and maybe try something myself. But by reading your other posts about optimizing Rust to do search, it seems to require a lot of experience to tune Rust code.
Building ripgrep did require a lot of experience, indeed, but it had almost nothing to do with Rust. The experience is in text search specifically, which you'll need regardless of the language you're using. If you look at the regex crate for example, there's basically no use of unsafe at all. The only use is to elide bounds checks in some very carefully crafted tight loops. But again, most of that work was done irrespective of Rust and just figuring out the right way to unroll the DFA loop(s).
Optimization tricks in Rust are the same as you'll find in C++. It might be worth you comparing the C++ implementation of Snappy with my Rust implementation, for example. You'll see the same kinds of tricks employed in C++ as in Rust (avoiding memcpy in favor of unaligned loads/stores).
>"Until we start seeing some more balanced (frankly, I'd settle for nuanced) discussion about the compromises made to get Rust's strengths, I'm staying the hell away from it."
Look into the issues surrounding the borrow checker, that's one of Rust's main pain points. Long compilation times are another common issue.
To Rust fans, I realise both of those issues will be addressed to some degree as MIR matures, but I'm looking for flaws as things stand now.
Another couple of flaws that could have a big impact on Rust.
- It will be super hard to hire for Rust for a long time. It would be a very bold move to write your app in Rust if you plan to grow your tech team anytime soon.
- I havn't tried learning Rust myself, but I have read that little that it can be a little tricky to start thinking the rust way (borrowing?) Plus the language "looks" hardcore. I wonder if that will put off new devs.
There have comments on HN to the effect that, paradoxically, it's easy to find Haskell developers to hire, because there are so many jobs that require working with more mainstream languages. I would hope the same principle applies to Rust.
I assume they're talking about the fact that basically everyone that learns Rust goes through a period of "fighting the borrow checker". Part of the way that rust ensures memory safety is by preventing you from doing things that it can't prove are safe to do. For people coming from languages like C or C++ they've been able to get away with doing things that are probably unsafe but that work either through luck or very careful planning. But since the borrow checker can't prove that some of these tricks are safe it will just say "no" and fail to compile.
Within a couple weeks you will get the hang of what the borrow checker can actually handle and you'll mostly not have problems except when you are actually making a genuine mistake.
Honestly, I found dealing with generics worse than the borrow checker. Since the compiler wants everything to be sized, code that I think should work (i.e. using generics and traits) will sometimes just not compile. In fact - I'm dead in the water facing an issue like that right now. That is, by far, the most frustrating thing in using Rust.
Can you describe the issue? Perhaps someone can help.
I don't know if it helps you or not, but you can specify that a type parameter need not be sized with the ?Sized bound. e.g., The `Path::new` constructor is defined as `fn new<S: AsRef<OsStr> + ?Sized>(s: &S) -> &Path`. This means `S` can, for example, be `str`, which is an unsized type.
Quote: "Rust's borrow checker is a wonderful thing that forces you into designing code to be more robust. But as it is so unlike anything you're used to, it takes time to develop a certain knack to work with it efficiently."
There's plenty of comments about it in the Rust subreddit, coming from people who have tried it.
Look, it's not an issue for all time, there are plans to improve it, I'm just suggesting it as a point of friction right now. If you seriously don't think it's an issue, what would you say are the issues? You won't do yourself any favours if you try to pretend Rust is perfect.
I've been writing software exclusively in Rust since the 1.0 release. I have no issues with the borrow checker, personally. I haven't seen the borrow checker mentioned as an issue on the Rust subreddit, which I frequent.
The only people who have issues are people who've used Rust for less than a week and still do not understand the basic rules of the borrow checker. I've explained it many times to people already. Once you know the rules, it's easy peasy, and you'll never have another complaint from the borrow checker ever again.
The only improvements that I could see for Rust is landing non-lexical borrows, macros 2.0, and faster compile times, albeit compile times are largely fixed now. A 100K combined LoC project can easily compile a release build using 1 core in 3 minutes or less.
It took me quite a bit longer than a week to completely internalize the borrow checker. Probably closer to a small number of months. I still sometimes run into problems, but I have enough experience now to know what the space of solutions looks like.
Let's be careful not to overstate Rust's benefits and understate Rust's costs. Of course, I do happen to think the benefits are overwhelming compared to the costs. :-)
You do realise you've wasted both my time and your own. If you thought about it from the start, it's obvious that I was referring to the learning curve. All facets of all Turing-complete languages are useful once you've overcome the learning curve. What varies is the length of time needed before you become proficient in using it. For another example...
The learning curve for manual memory management in C is a major issue, but not the principal of manual memory management itself.
nothing is scaring me as a programmer who use Rust, but I wish to see in such debates more people who at least tried to use Rust more than 2 months, before arguing :) And I just hope this "week of Rust" on HN will attract more people to try Rust. We have cookies and community is very friendly - welcome!
Rust is an overly complicated language that made the exact same deadly mistakes that c++ made: takes too long to compile and is too complex.
Yes I get it, you're working on the compile times. You will never bring them down to under 1 second regardless of amount of libraries used, let's just say this once and for all. I add two crates 'hyper' and 'postgres-rs' in a 500 line(!!!) program and it's STILL a 2.8 second compile time. Imagine if I actually use Rust for real software and have 500k lines of code.
I'm putting my hopes on Jonathan Blow's Jai language.
I don't know why you are down voted. Compile time is a Rust issue for me. I'm spoiled by D. However I'm not sure if borrow checking is inherently slow. The release notes are discouraging. 30% faster? Aim for 10 times faster. Maybe it is just the LLVM backend. It still is slow.
> Maybe it is just the LLVM backend. It still is slow.
It's a combination of two things, as far as I know.
1. The LLVM backend is slow.
2. The Rust frontend has historically abused the LLVM backend badly, by feeding it large amounts of barely optimized code. This is being worked on, but it's going to take a while.
> 2. The Rust frontend has historically abused the LLVM backend badly, by feeding it large amounts of barely optimized code. This is being worked on, but it's going to take a while.
Yes, it's taken a _long time_ to pay down the technical debt from writing a compiler in itself for years. A huge step forward for doing so landed fairly recently, MIR, so progress is being made. It's already resulted in significant improvements, and will lead to more in the future.
What you aim for and what you achieve are different things. These things take time. We've been getting faster every release. 10x faster within a single six-week period is not realistic.
(Borrow checking is not generally the slowest part; it's the codegen. Which is LLVM. But also is the IR we feed to LLVM.)
Go is fast. D is fast, but its compile time meta programming features can make it arbitrarily slow.
Java, Python, etc actually compile at run time so the comparison is invalid. You can measure the full iteration speed, but then image based wins (Smalltalk, Common Lisp).
Rust has great potential to be a better tool for C and C++'s niches, and we're all rooting for it, but for those tasks where a type-safe GC'd pure functional language can be used, well, they still should be.
The reality is Rust will never be mainstream because 95% of the dev use php / ruby / python / java / c# and Rust is far too complicated to switch from those. That's where imo Go will prevail, it's a simpler language that is easy to use / learn.
In the 90ies, Pascal had a lot of traction here in Europe. Turbo Pascal was the default language to use for DOS programming. I remember from my physics department that any computer-controlled devices came with Turbo Pascal units for controlling them. And later on, Delphi had its success, I guess it was more killed by bad management then anything else.
Interestingly, Go picks up a lot of Pascal (and of course Modula) tradition, as Robert Griesemer worked with Wirth before. A lot of the Wirth language family's ideas made it into Go clothed into a C syntax.
It had lots of traction in the 80's up to the late 90's, with Turbo Pascal being the most successful compiler in use, up to when Borland decided to go berserk and scare everyone away with their lack of focus on how to do business.
Remember that the benchmark game is a game, and it has rules. https://news.ycombinator.com/item?id=13267312 is a recent thread about Rust and these rules on at least one benchmark.
Many of the others boil down to "explicit SIMD isn't in stable yet."
I don't hate C, like some here, but I am receptive to the many objections to it: it makes a lot of sense.
But I would be a lot more receptive to this particular attack on C (which is pretty reasonable) if it wasn't so melodramatic: claiming that Rust will "save software" and that C is some kind of garbage with no advantages of any sort. Both are false (although the latter has some truth to it: C has many issues).
The truth is strongly in your favour: No need to stretch it.
Sure, but not all languages are equally bad. Will Rust become dominant? Unlikely. Will Rust's popularity continue to grow? For the foreseeable future, I'd say yes, mostly based on its merits.
This may be wishful thinking, but to echo Alan Kay, I have been hoping that with the stalling of Moore's law we'd start being a little more thoughtful about the instruction set architecture (like the B5000) so that we can do safe and performant things in higher-level languages.
I like Rust. I just don't think doing things in a better C than C is going to yield as much of a payoff as these guys think it will.
I remember doing all sorts of "clever" arcane things to get a smooth high frame rate for a program on my old IBM PC. Next generation, they have actual graphics cards with overlays, easy vsync, and double-buffering where the buffers can be swapped with a simple toggle instead of trying to find some way to shuffle the bytes faster.
I was able to replace pages of "cleverness" with a few lines of code in the same language.
These guys are very impressed with their improved hammer. It might not be the best tool for the job.
All of us who get the compiler writing bug make a toy language or two, I know I did, way more than two, usually it was taking some great idea and running with it .... there is a basic problem that there's a lot more aspiring compiler writers than there is public mindshare for learning new languages .... for every new language you see blooming there's 20 that didn't get the attention to get more than 2 adherents, and for every adopted language being commonly used there's another 10 of those new blooming languages that will blaze and die .... only to have its one great idea find its way into C++ 5 years from now.
I don't write new languages any more, I figured this out 20 years ago, it's something that is very very hard to suceed at, and rather a crap shoot.
The same goes for OSs.
Oh, and BTW, functional languages, the very best thing since sliced bread, for, what? the third time around now?
In 2014? Objection, your honor. Assumes facts not in evidence.
About problems with C:
> Maybe a bug in GCC outputted the wrong machine code
And Rust compilers will never have bugs?
> Maybe a race condition in Linux gave an unprivileged process the ability to tamper with your program
And writing your program in Rust is going to save you? Nope.
Now, in the previous two points, the claim may be that GCC/Linux is written in C, rather than that my program is written in C. But a compiler written in Rust can still output the wrong machine code, and the borrow checker won't save you.
You don't have to "solve the halting problem" to have better heuristics/primitives than C that give a compiler more optimization room. Even Fortran does it, and of course there's tons of room for way bigger "intention defining" features in a language than what Fortran offers.
So nothing strange about the statement, except your hyperbole.
Programming is hard. Programming will always be hard. Better/newer tools (and sometimes influences from the old finally making it mainstream, like Standard ML) make programming easier but not fool proof. It's misleading and harmful to hype the crap out of any language.
Unfortunately this stupidity is never going to end as long as language creators measure language success in adoption numbers and TIOBE scores rather than the warm fuzzy feeling of handling certain people's needs really, really well.