Im not trying to be a jerk. Just voicing my concerns. Learning a new language and producing code in it is a huge commitment. It better be around in 10 years. Will it still be as clean and simple, or will it have grown complex. What if Mozilla stops sponsoring it?
C++ is 35 years old. It has stood the test of time. I would not be surprised if it was still popular in 35 years time, when I retire. There is so much C++ infrastructure code in this world, that its not going anywhere.
In the meantime C++ has evolved. I cant remember the last time I had an uninitialized memory, null pointers, or buffer overflow -bug. Those are low level C problems. If you avoid C-style programming and stick with modern C++ (RAII, value semantics, STL, boost, etc) you wont get them.
C++ is changing fast. In the next few years we are getting high level concurrency and parallel language support and libraries (no more low level thread problems), we are getting modules (no more preprocessor hacks), compile time reflection (no more manual serialisation), concepts (no more ugly error messages), ranges (no more cumbersome iterators), and a whole lot more.
And finally there is "C++ Core Guidelines" which aims to be checkable by tools. So you get a warning when you are relying on undefined behaviour.
I think C++ is still the future.
And those other languages have slowly eroded C++'s dominance. You have to remember that in the early '90s, C and C++ had nearly 100% market share for all applications. That dwindled with the rise of Java, then dwindled more with the rise of dynamic languages, and the mobile/modern era made it dwindle even more with Objective-C, Swift, and Go. Now C++ is a popular language for a certain class of applications, but by and large new programmers aren't even learning it anymore. That's a huge shift.
> In the meantime C++ has evolved. I cant remember the last time I had an uninitialized memory, null pointers, or buffer overflow -bug.
I do. https://bugzilla.mozilla.org/buglist.cgi?query_format=specif...
> And finally there is "C++ Core Guidelines" which aims to be checkable by tools. So you get a warning when you are relying on undefined behaviour.
As I've said before, I have questions about this tool: how much like C++ it will really be after ruling out so much code, and how they plan to statically guarantee noalias on function boundaries in the presence of shared_ptr.
But C++ also has some domains of its own where it is the king. Systems programming and any application where performance is a priority.
If C++ started slipping against a new languages in those areas, then it might be a sign of the end for C++. I don't think its going to happen for a very long time. Its hard to beat C++ when it comes to performance (while still having high level abstractions). And any general purpose language needs to know how to do "a bit about everything", so it would probably be just as complex as C++.
(Even though C++ has slipped in percentages, I bet there are no fewer C++ programmers today than there ever was, there's are just more programmers in general.)
If something is going to kill C++, its probably a language that scales very well to multicore. Maybe a functional language. I be happy if that happened as that would be a revolutionary breakthrough.
On you final points. I think C++ programmers are slowly but surely moving away from C-style coding towards modern C++ (and we will see less of those types of bugs). It takes time though. Id be happy if C++ at some point was sub-setted and the worst parts of C where deprecated (Thats the other aim of "C++ Core Guidelines" as I understand it).
About the aliasing problem. I'm not sure how it could detect that either. We will probably have to live with it. In general though smart_pointers are still just pointers, and its better to avoid them when one can (and use value semantics instead).
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Re: performance, Rust's doing pretty well (on a bunch of arbitrary microbenchmarks):
https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
Re: high level abstractions, Rust doesn't have many of the template shenanigans C++ does (but that's a good thing, IMHO). However Rust does have a phenomenal type system for a language with such predictable and solid performance. And it has many wonderful high-level abstractions (exhaustive pattern matching on algebraic data types, iterator syntax for collections, many functional idioms, an AST-based macro system, etc.).
> If something is going to kill C++, its probably a language that scales very well to multicore.
Rust has fantastic concurrency, and the libraries for it are still in relative infancy. The type system keeps un-synchronized shared mutable state from happening (unless you intentionally turn off certain checks using unsafe code, IIRC). There are freely available libraries for lock-free data structures and stack-scoped threads. As an aside, it's also really easy to use those libraries without having to vendor some random header files that may or may not conform to your coding style.
> Maybe a functional language. I be happy if that happened as that would be a revolutionary breakthrough.
Rust also has some pretty cool functional syntax, although I'm not an expert on functional programming, I've been enjoying it quite a bit.
> About the aliasing problem. I'm not sure how it could detect that either.
Not sure how C++ intends to do it, but Rust does it with a strict ownership system that is fully enforced at compile time.
On the benchmark though, its doesn't seem quite fair. At least that first one is comparing a single threaded c++ program, to a multi threaded rust program. And for the regex example the author doesn't use C++ std::regex and std::futures (std::async) like he does for Rust. It makes me think a proper C++ implementation would do much better. (Personally I use the Parallel Patterns Library. I like it a lot. We will get something similar in C++ in a few years)
I don't know much about rust. It worries me though the examples are still using threads and mutexes. I think we need much higher level abstraction (like ppl::task, coroutines, etc) to get better scaling. Also lock free data structures dont scale that well either. As they still require synchronization and that hurts scaling). I think we need some kind of revolution in how we code to scale our programs to hundreds of cores.
> And for the regex example the author doesn't use C++
> std::regex and std::futures (std::async) like he does
> for Rust.
> It worries me though the examples are still using
> threads and mutexes.
> Also lock free data structures dont scale that well
> either. As they still require synchronization and that
> hurts scaling
That was the dream of the mid-2000s. But now hundreds of cores are never going to happen. The CPU vendors have decided that the industry has run out of time to parallelize their programs and are now refusing to scale up. Our hope for speedups now lies in using SIMD and GPUs effectively ("heterogeneous computing").
I'm not sure about the details for the "fasta" benchmark, but I know it's at least partly I/O bound, and many implementations for the benchmark are single-threaded:
https://benchmarksgame.alioth.debian.org/u64q/performance.ph...
Notably, Rust also edges out a multi-threaded C implementation for that one. I'm sure they've done some very hairy optimizations to get to the top on that board, but it's cool to see that it's possible.
On the subject of regexes, I am not familiar with the C++ std::regex implementation, but it does look like (some rather slow) C++ implementations are using a boost regex library. Those are generally fairly "standard" in C++, right?
The most important optimization I did was to avoid regex machinery as much as possible. In particular, Rust's regex library has very good support for prefix literal optimizations. In particular, regexes like `abc[x-z]foo|bar` will compile down to an aho-corasick[1] automaton over the strings `abcxfoo`, `abcyfoo`, `abczfoo` and `bar` with the failure transitions completely evaluated. (The end result is an automaton represented by a matrix. This is memory intensive, so only prefix literals of a certain size can be accommodated. But you don't need a lot to realize huge gains!)
I wrote more about it here: https://www.reddit.com/r/rust/comments/39unje/ahocorasick_fa...
Hint: most of the benchmark game regexes are relatively simple and compile down to either simple `memchr` calls (most regex engines will do that, nothing special) or a aho-corasick DFA that completely avoids the traditional regex evaluation machinery.
In general, regex implementations differ dramatically in the optimizations they perform. It's hard to draw conclusions about them without some explicit knowledge of how it is implemented.
About the regex example.
https://benchmarksgame.alioth.debian.org/u64q/program.php?te...
The boost regex library is fast and widely used. It doesnt look like the example is using it though, but a library called "re2". Never heard of it before. Googling turned up this https://github.com/google/re2
https://benchmarksgame.alioth.debian.org/u64q/program.php?te...
https://benchmarksgame.alioth.debian.org/u64q/program.php?te...
I have no idea whether it's the regex implementations that are causing the comparative slowness, to be honest. Just seemed interesting that some C++ implementations using what I would think are common techniques fall behind many other languages' implementations.
Of course, benchmarks are always arbitrary, and some of them will just disadvantage approaches that would be perfectly realistic ways to solve "real-world" problems, so it's always a grain-of-salt situation. However I'm not sure it's necessarily fair to say that "C++ should be at least as fast as C for any fair benchmark." Doesn't that expose you to the danger of redefining fair benchmarks as "those benchmarks which reinforce my preconceived notions of which tools have what performance characteristics"?
> any general purpose language needs to know how to do "a
> bit about everything", so it would probably be just as
> complex as C++.
> If something is going to kill C++, its probably a
> language that scales very well to multicore.
> I think C++ programmers are slowly but surely moving
> away from C-style coding towards modern C++
> [TIOBE link]
So no, C++ isn't going to "die" (what language ever truly dies? COBOL still powers all the world's banks, and I've personally been paid to write RPG-LE), but I wouldn't bet on its ascendancy.
While your small walled garden within C++14 is nice, clean, safe, and well maintained. Massive parts of it are built ON THE VERY FOUNDATIONS YOU ARE ATTEMPTING To AVOID.
This is the irony of C++. While there is a very nice subset of the language, that does nearly all the same things Rust does. You still have 30 years of legacy laying around. You likely won't find a job that EXCLUSIVELY follows the C++14 guidelines. You WILL have to learn the legacy patterns, and work with legacy code, and make legacy mistakes.
>C++ is 35 years old. It has stood the test of time. I would not be surprised if it was still popular in 35 years time, when I retire. There is so much C++ infrastructure code in this world, that its not going anywhere.
I don't debate this fact. But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game.
Large existing codebases are a strength of C++ though. Any new replacement language won't magically make those codebases go away.
> [...] But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game.
The killer feature of C++ was the seamless interoperability with C which allowed trivial use of C libraries, and, most importantly, easy piecemeal evolution of large C codebases.
For example GCC is begin ported to C++ with relative ease, while a rewrite in rust would be a significantly more complex endeavor.
Then again, beyond lifetime checking, rust and C++ are very similar languages and seamless interoperability is not inconceivable. I believe that's the missing feature for rust to achieve world domination.
Which I already said...
>>I don't debate this fact. But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game.
>For example GCC is begin ported to C++ with relative ease, while a rewrite in rust would be a significantly more complex endeavor.
Source or opinion?
>Then again, beyond lifetime checking, rust and C++ are very similar languages and seamless interoperability is not inconceivable. I believe that's the missing feature for rust to achieve world domination.
No I agree. Seemless importing with C++ would be amazing. Name mangling in C++ is just a bit of an issue. Rust works great with C. The FFI is very stable. I use Rust libraries at work as generating 32bit DLL's is possible with nightly.
It doesn't matter that there's much legacy C++ code. Two things will happen:
a) it will stay C++03, regardless of what changes in C++ or what other languages pop up. This kind of code is probably part of a working product which fulfills its mission and maybe gets small updates or fixes.
b) it will continue to be maintained, and it will be able to benefit from some or most of the changes coming in new C++ versions. It doesn't mean that it will be converted to super duper C++14, but that's not how software maintenance works anyway! And guess what, they probably won't be converted to Rust either, but they will be better due to the new standards. You are building a strawman when claiming that it's either Rust or failing to use pure C++14. Successful software tools offer backwards compatibility when making improvements and iterate instead of replacing everything. Just ask the Python and Perl teams.
And this is how C++ was able to build marketshare, by offering a transition path from C. What exactly is that path for C++ to Rust, rewriting everything?
Finally, new projects will use the new standards. My current project is C++11. The next one will be C++14 and we will absolutely make use of the new features where it makes sense.
What we need is memory safety, and new standards don't provide that. Maybe in the future they will, but I have significant questions about how suitable the ISO Core C++ lifetime checker will be.
> Just ask the Python and Perl teams.
Python and Perl were not backwards compatible with anything when they were released.
Rust is not a new version of C++. It is a new language.
> And this is how C++ was able to build marketshare, by offering a transition path from C. What exactly is that path for C++ to Rust, rewriting everything?
No. It's a very comprehensive FFI, IMO among the best in any language. We even have (preliminary, quite hacky) C++ support.
We had to spend time developing this, because we actually use Rust for Servo and we had to develop incrementally, retaining large C++ components. It works great.
> Python and Perl were not backwards compatible with anything when they were released.
I think the implication is that the teams will tell you that the upgrades to Python 3 and Perl 6 were problematic because they didn't offer backwards compatibility. If so, it's a bit silly, because the point of those upgrades was to advance the languages beyond would could be done with backwards compatible iteration. Asking the teams would probably yield a bunch of people that were adamant that the decision was sound, and it needed to be done, but there were missteps in execution. Asking the communities would likely yield a more polarized set of opinions.
That said, IMO using either of these items as examples to bolster an argument is almost always a mistake, since their own discussions are so large and polarizing, they rarely ever make make a point more clear.
Perl 5 (and older) was highly backwards compatible from a programmer standpoint. Much of Perl is an agglomeration of preexisting Unix command line tools and little languages into one language.
[1]: http://www.arl.wustl.edu/projects/fpx/references/perl/learn/...
If Rust is highly semantically compatible with C++, then automated porting of C++ to Rust isn't such a far-out idea.
:.:.:
I don't have an issue with C++ itself, its just the meme that "C++14 will solve all of C++'s problems". It won't. C++'s problems are now locked in, and fixed. They've been known for 25-30 years, and we'll deal with them for another 50+.
Yes the tooling is great, there are amazing libraries, there is still virtual templated necromancy, there are still null pointers, and use after frees. There still will be tomorrow, and there still will be in 50 years.
Anyway, I think your strategy is sound. Rust is a young language and I would be pleasantly surprised to see code written today still compile in five years. I got bit by this with Swift v1 in a little app. When 1.x came, it failed to correctly transform the source and the whole thing was a major PITA to update. Completely soured me from using Swift.
I can understand why Mozilla wants to use Rust. It solves a problem for them, they largely control how the project evolves and can plan for it. To me, the big questions are what will happen to Rust if Mozilla changes strategies (Persona, Thunderbird, FirefoxOS) and whether Mozilla will continue to be a successful organisation. Personally, I root for them, in spite of their recent missteps.
I think Rust might be a good choice now for language aficionados and early adopters which can afford to waste time in exchange for other potential benefits. I would absolutely not use it to bring a project to market or for an OSS project which has a long term vision. In 5+ years I expect such a decision could be worth revisiting.
We have had a code stability promise for months now in 1.0. So what you are saying here is that you do not believe that Rust will adhere to what it very publicly planned to do. Do you have specific reasons for this?
> To me, the big questions are what will happen to Rust if Mozilla changes strategies (Persona, Thunderbird, FirefoxOS) and whether Mozilla will continue to be a successful organisation.
Rust has a core team and community that overlaps a lot with, but is very much not identical to, Mozilla. Probably most Rust users aren't even Firefox users.
Rust is not "Mozilla's language". It's the Rust community's language.
Since 1.0, Rust has in fact had multiple significant stable-breaking compiler changes, not to mention that, among other things, adding any new method to a trait or type in the standard library has the potential to cause breakage. The official code stability promise has not been violated by these changes only because it's riddled with exceptions.
This is essentially the same as any other language. Adding a new method to traits or types can also break JavaScript, the other example you gave.
In fact, I know of one such example where code was broken in the wild because of new methods being added, and we did not revert the change. Marijn Haverbeke's winning js1k entry relied on the 4th and 7th letters (or something along those lines) of every CanvasRenderingContext2D method being unique, because it compressed code by renaming the canvas methods with what was then a perfect hash function. A new Firefox version was released months later that added new methods and broke the code. That was deemed an acceptable piece of breakage, and Rust's policies are very similar.
Anyway, the vast majority of breakage that we've seen so far was due to the libcpocalypse. This was an issue with people not specifying specific versions of libraries they depended on, not the language.
https://www.fxsitecompat.com/en-US/docs/2015/string-prototyp...
Unless you mean to refute the idea that JS doesn't break anything ever - which it clearly does, occasionally, but proof-of-concept golf code that intentionally takes fragile shortcuts isn't the best example.
...But JS has moved away from monkey patching builtin objects for good reason, whereas Rust tends to be relatively promiscuous in adding methods to other people's types via trait impls. This isn't bad per se, but I do think it creates bigger compatibility risks.
> Approximately 96% of published crate revisions that build with the 1.0 compiler
> build with the 1.5 compiler.
But even at a rate of significantly less than 4%, there's still trouble. That figure is based on the number of root regressions, right? (If I'm wrong, disregard the rest of this paragraph, but I don't think so...) That is, the number of crates that break on their own accord, rather than those that won't compile because one of their dependencies is broken. If one application depends on dozens of crates (or is just really large), the chances of it breaking somewhere are much higher.
This can be partially mitigated by the crates themselves releasing upgrades, but look at Python 3 - there will eventually be a lot of code out there that's completely unmaintained, especially within the "dark matter" of internal or closed source applications. Also, a fix in the latest version of a crate will probably not be backported to long deprecated major versions of it - which means that if I dust off a crate that hasn't been touched in years and uses such a version, I'd have to either upgrade the dependency or do the backport manually.
And the ancestor post did say five years: last I checked on the lists, there was no real consensus as to when Rust 2.0 should be released, on a scale from "in a year" to "never". Maybe there is more consensus internally, but I'd be surprised if it didn't happen in that long...
edit: It's not an entirely fair comparison, but for what my ideal stability promise for a programming language would look like, one need not look very far - only as far as Mozilla's other programming language.
> edit: It's not an entirely fair comparison, but for what my ideal stability promise for a programming language would look like, one need not look very far - only as far as Mozilla's other programming language.
As a matter of fact, JS's stability promise is very similar. See my other post for an example in which JS was broken due to, essentially, one of the reasons you cited, and we lived with it. The JS stability promise is not "we will never break any JavaScript in theory with new browser versions", because that would prevent anyone from, as an extreme example, changing the sorting algorithm for Array.sort. It's "we will not break you in practice, except in a carefully delineated set of circumstances." (Actually, JS's stability promise is much weaker than that: its stability in practice is decided by browser consensus and market forces rather than a clear set of rules.)
The core team feelings on a 2.0 is much closer to the "never" end of the spectrum than the "in a year" side.
edit: Once you google for dropbox rust, you find some really interesting stuff; here's an overview
Putting Rust into production at Dropbox: https://www.reddit.com/r/rust/comments/3wrgl0/what_are_you_f...
Some preliminary feedback on using Rust at Dropbox: https://www.reddit.com/r/programming/comments/3w8dgn/announc...
I'm myself willing to accept the promise of code stability, so I think you're looking at slightly the wrong problem. While I'd expect current code to continue to compile, I also expect what is regarded as good Rust now won't be in five years. That's not a bad thing, but it also means that hopping on the Rust bandwagon might be premature.
The worst case? How about Haskell, where new language features make old code look worse even as it still works? Or C++, with it's accelerating rate of style changes?
Can't speak about Haskell, however I believe that C++ changes can be incrementally adopted: we had C++98, then boost established itself, some parts of boost were included in TR1 and then were part of C++11. A similar process is taking place with other libraries such as asio and filesystem. I don't have the feeling that modern C++ style is in flux, its pillars continue to be RAII, generic programming and the STL.
I think Bjarne & co have explicitly stated that they want to grow the language while maintaining backwards compatibility as much as possible and from my experience, the code I write today builds on patterns and idioms that started to crystalize a long time ago.
Good catch.
Even if it remains a small niche, I think we've seen that Rust is popular enough that using it long-term is fairly safe. Maybe you'll be one of only a few thousand shops who use it -- that's enough. The benefits of writing secure code vastly outweigh to drawbacks of using something unpopular.
When choosing a language to learn, I consider:
* what a particular industry or project of significance is using
* job availability
* compatibility with my existing toolbox
* the power/fun factor
But that's far from the whole story, because programming languages are relatively fungible and investing in domain knowledge, people skills, architecture and many other things will bring bigger benefits than learning that brand new programming language!
And yet here we are, discussing how Rust will deliver us.
> * job availability
That just boils down to popularity once again. I prefer to pick languages based on suitability for the problem domain. For me, Rust is suitable in a way that C++ is not, due to memory safety among many other reasons.
Job availability is not just about number of jobs, but also about project quality, companies and personal preference. E.g: I don't have an interest in containers, and most Go jobs involve containers, so this is a minus for Go.
This works in the other direction too. Let's say I want to work for Mozilla, I notice they use mostly C++ & Js, so I decide to invest time brushing up my skills in those areas.
I agree with that regarding learning them, but I disagree strongly when it comes to the end result.
I make a lot of my money fixing/replacing PHP projects. As has been pointed out many times before, there are issues with PHP that are guaranteed to cause bugs. The same is true of many languages.
But there is a spectrum! Some compilers/interpreters scream at you and terminate if you contradict yourself. Some of them even recognize security vulnerabilities.
I agree that people skills, domain knowledge, and architecture are hugely important, but great teams are still less effective when they use slow or confusing tools.
You might be the greatest contractor in the world, but if someone asks you to build a skyscraper with plywood and super glue, you're going to end up with something dangerous, fragile, and guaranteed to fall apart as soon as someone tries to use it.
The other narrative is also true. Using newer technologies is the best way to be a part of new projects and avoid working legacy maintenance kind of projects.
So why are you here, debating about Rust, if you already know your time would be better spent investing in domain knowledge, people skills, or architecture?
I am not really discussing Rust per se, as I am not familiar enough with it, however, when I see biased or misleading statements I do sometimes feel obliged to offer a counterpoint.
You'd have a similar problem with Rust, Ruby, Python, Java, Ada, Julia, and probably tons of other languages. It must also be really difficult to differentiate between C, C#, and C++, considering most search algorithms will ignore the # and + characters.
1. https://groups.google.com/d/msg/golang-nuts/TtPzOvhG6bM/-XCr...
> I would be pleasantly surprised to see code written today still compile
> in five years.
> what will happen to Rust if Mozilla changes strategies
Without changes to the code? Has there even been a language where that has been true?
For instance, here's the compatibility guide to Java 8: http://www.oracle.com/technetwork/java/javase/8-compatibilit...
There a few other little breaking changes as well.
Java stole it's crown for "enterprise" programming and Microsoft even pretty much abandoned it in favor of .NET. I'm not sure their massive push for "C++ is back!" that happened 'round C++11 has really met with that much success - the world moved on, honestly.
There's fewer and fewer niches for it - the web could care less for it, heavy-duty "enterprise" programmers aren't giving up their safe and GC-based Java/.NET languages and giant 3rd-party eco-systems, and even video games now can be written in a higher-level language where only a small core 99% of people never interact with is in C/C++.
The problem is, IMO, that it's too late for C++ to be a decent language. If the first iteration of it was C++11, then sure. But there are vast code bases out there written in the horrible mid-90's or late 80's dialect of C++ that aren't going anywhere. Even something like Qt isn't true "modern" C++, and don't get me started on MFC. Look at Google's official C++ guidelines - they barely allow any modern C++ into their code-base.
> Languages come and go but C++ remains. I wonder if this one will be different.
You're not _wrong_, exactly, but with this logic, no new programming languages should ever be made. There are certainly valuable things about using a truly mature ecosystem, but we also need to build better mature ecosystems.
Well I mean after LISP it was all down hill. /s
I'm not trying to be a jerk. Just voicing my concerns. Learning a new language and producing code in it is a huge commitment. It better be around in 50 years. Will it still be as clean and simple, or will it have grown complex.
Note: That the C++ and COBOL counterpoints look identical and laughable never gets old for me.
Taking the comparison seriously though for a moment. In my opinion the difference is that C++ isn't just a better Cobol. Its not just the same thing re-imagined or cleaned up. There is a revolution between them. You can do things in C++ that you cant in Cobol.
Im waiting for that revolutionary new general purpose language that goes mainstream. I think it will be a language that scales much better and easier to hundreds of cores. Maybe it will be a functional language.
It's a new meme of mine. Glad you had fun with it. :)
"Im waiting for that revolutionary new general purpose language that goes mainstream. I think it will be a language that scales much better and easier to hundreds of cores. Maybe it will be a functional language."
I am too. I think Rust is a nice alternative to C++ for doing that sort of thing. Far as next step, I'm waiting too. I encourage you to check out Julia because it seems to have some of those traits. It's a LISP on the inside with a productive, imperative skin on the outside. Lots of potential for such a hybrid.
Also, check out ParaSail if you're interested in languages designed for easy parallelism. It's an Ada superset with some interesting design decisions. Might be worth factoring into the next, ideal language. ;)
C++ isn't going to go away any time soon, but it might gradually fade into the background.
Are we? I've been hoping but this wasn't on the last C++17 meeting in Kona, Hawaii
https://www.reddit.com/r/cpp/comments/3q4agc/c17_progress_up...
Around 1994 C++ seemed the path forward from Turbo Pascal, given that I favoured type safety, C was a meh when compared with Turbo Pascal, but Turbo Pascal was a PC only thing.
Back in those days C++ was regarded like Rust and other C++ wannabe replacements are nowadays.
We were the hipster of the 90's, with C devs targeting home systems slowly accepting that not all functions needed to be inline Assembly wrappers.
So it is interesting for a grey beard like me to see C++ being described just like C and Pascal vs C++ compilers were back in the mid-90's.
Nowadays my area of work is dominated by JVM, .NET and the native languages of mobile OSes.
I wish Bjarne et al succeed pushing "C++ Core Guidelines" forward, but they will not change the mentality of those that program C with C++ compiler, which is what I usually see at the typical corporations.
10 years is a long time; a few weeks to learn a language is not.
> no autoconf
Are there no optional libraries? No outdated libraries whose version you have to detect? No obscure platforms whose architecture you have to detect for unsafe inline code etc.?
Because if you can have any of those or any number of other cases where you need compile-time detection of configuration options you're going to need something like autoconf.
Yes. Rust ships with cargo, which is probably the best build configuration tool ever written, and I've tried a lot of them, for a lot of different languages.
It has clean, non-hacky solutions to all of the cases you listed, and a lot more besides those.
> happily downloaded a random pre-built ELF binary to build itself.
The main problem is you can't download dependencies separately from compiling your code. It should never be the same step. Even pip had it mostly correct, by providing an option to disable network communication.
It is somewhat mitigated by documentation mentioning where the downloaded dependencies are put, so you can do all that manually. This sucks balls heavily.
> Yes, Cargo builds itself with Cargo, so you need to get a previous Cargo. The binary is very much not 'random'.
It's fetched outside of regular downloading you do on tarball. You have no control over where is it downloaded from. It means it's pretty much random for your purposes. Heck, it would be even unexpected, if I wasn't used to developers not understanding the difference between building and downloading software.
But this is not the main point. Cargo should not need already compiled Cargo to build itself. This is ridiculous. I understand that every good compiler is built with the very same compiler you're building, but look at how they do that: by bootstrapping. Not so much with Cargo. Who ever thought it as a valid idea?
> It should never be the same step.
"cargo fetch" means you don't have to do the download step manually. IE, you _can_ do it in two commands if you'd like.
> It means it's pretty much random for your purposes.
- corporate source code control systems
- corporate central repositories
- caching/proxying immutable repositories
These ensure all projects are built from known sources. We _know_ we can get consistent builds.
When using Cargo:
- Project owners update projects and don't bump the version. New bugs / security problems could be injected even though we haven't changed a thing internally.
- crates.io isn't always up.
- Trust: we legally can not trust (PCI compliance violations - 2015 rules (viral) ) the public crates.io repository. Besides PCI compliance, it's not possible for crates.io to guarantee perfect security (so many reasons, obviously).
* I'm hoping folks who have addressed this issue (or are addressing it, or are planning on addressing it) would comment.
You can't update a crate on crates.io without bumping the version. Once a version is published, it cannot be removed. (It can be "yanked," but even yanking it does not make it completely inaccessible.)
> These ensure all projects are built from known sources. We _know_ we can get consistent builds.
Cargo isn't coupled to crates.io. You can run your own registry index. (Note the `[registry]` config section: http://doc.crates.io/config.html) --- All of the code that powers crates.io is open source. On top of that, crate dependencies can be specified via git URLs or locations on disk. Repeatable builds are well supported IMO.
I think Burntsushi gave a good answer here. We want these features! It's a matter of getting the requirements correct, and then helping build them. We have some of this stuff already, and are working on what Firefox needs, which is very similar, but would love for anyone who has a stake in this to help tell us about what they need, specifically. If that's you and or your org, starting a thread on http://internals.rust-lang.org/ would be quite helpful.
> Project owners update projects and don't bump the version.
You cannot update code in a crates.io dep without bumping the version. And new versions only get pulled in when you do a `cargo update` or you update a package which bumps the version number of its dependency.
No, it is not.
* It's not always that you have internet connection when building your code.
* It's not always that you have access to the website code is downloaded from (websites break, and companies have different policies about internet), and even if you do, you don't always have it direct (e.g. proxy).
* And at the last, people will build code for various purposes, including building packages. Building a package should be a repeatable operation and should always use only clean source (no artifacts from previous builds), and downloading random things on every build from clean source is very easy way to break the process.
>> It means it's pretty much random for your purposes.
> We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself.
No. I downloaded Rust compiler myself (or had it installed from a package). I controlled that, it didn't hit me in my face unexpectedly.
> Which is also bootstrapped.
s/also//. Cargo is not bootstrapped, because it needs pre-built Cargo to build itself. Compare this to Rust compiler: you start with nothing but C(++? I don't remember) compiler, and end with Rust compiler. No intermediate download involved.
> Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system.
It's not invalid, quite the contrary. It's just Cargo doesn't boostrap itself out of clean code. It's that simple. I wouldn't have as big problem with it if its build process produced an intermediate, crippled Cargo binary.
I would then complain about requiring external dependencies to be downloaded (in contrast to included), but that would be difference on strategy preferences.
Cargo does not require this.
> * It's not always that you have access to the website code is downloaded from (websites break, and companies have different policies about internet), and even if you do, you don't always have it direct (e.g. proxy).
Supporting local proxies is on the Cargo roadmap.
> Compare this to Rust compiler: you start with nothing but C(++? I don't remember) compiler, and end with Rust compiler. No intermediate download involved.
This is incorrect. Rust has been self-hosting for years. Before it was bootstrapping, it was written in OCaml.
> It's not invalid, quite the contrary. It's just Cargo doesn't boostrap itself out of clean code. It's that simple. I wouldn't have as big problem with it if its build process produced an intermediate, crippled Cargo binary.
Cargo is basically just part of the Rust compiler. Rust needs Rust to bootstrap itself, like tons of other languages. So Cargo needs Cargo to bootstrap itself. This really isn't a problem.
The fact that you didn't even know that Rust is self-hosted is proof that it really doesn't matter to the user—it was so invisible you didn't notice it!
That's been my exact recommendation for getting compilers started in robust way. You people keep surprising me in pleasant ways. :)
Curious, did Ocaml's clean syntax and ease of decomposing functions make the transition to Rust easier vs a language like C++ or Java? I predicted ML languages should have that benefit but I couldn't test it on small projects.
The reasoning for the rule, was that they made our compiler assignments too easy.
On my case, we ended up using the recently introduced Java with JavaCC and NASM macros for the generated bytecode.
Nowadays I would only use something like C++ for the runtime library, or reuse of existing tools, e.g. LLVM.
> This is incorrect. Rust has been self-hosting for years.
Incorrect in that Rust actually downloads something, as steveklabnik pointed. I admit that I expected more from Rust, and I feel disappointed the same with the compiler as with Cargo.
But your premise that self-hosted language automatically means that bootstrapping can't be done using C or C++ is false. Compare that with OCaml and GHC.
> The fact that you didn't even know that Rust is self-hosted is proof that it really doesn't matter to the user—it was so invisible you didn't notice it!
It could be tried to read as that, if it was a fact. I did expect Rust to be self-hosted, just it is a custom that bootstrapping compiler is written in something else.
Look at how OCaml or GHC (Haskell) are built. Both allow to use C compiler to compile them (even though they generally advise to use pre-compiled compilers).
How many people actually do this, though?
We had this conversation early on in Rust's life and the consensus was that we could make a non-bootstrapping compiler in theory, but that'd be asking us to do a huge amount of work (writing a separate compiler!) for something that very few people are going to use in practice. There are so many more important things that we could be (and are) working on than something that's basically just for purism, because most people just "apt-get install rust" or "brew install rust" and don't care how it's built.
Enough to warrant this being kept after eight years after I've seen it for the first time.
> We had this conversation early on in Rust's life and the consensus was that we could make a non-bootstrapping compiler in theory, but that'd be asking us to do a huge amount of work (writing a separate compiler!) for something that very few people are going to use in practice.
Note that it's not necessary to have fully blown compiler. Just a subset of language would be just enough, if it allowed for compiling the compiler. And how many of the Rust features are embedded in rustc, anyway?
> There are so many more important things that we could be (and are) working on than something that's basically just for purism, because most people just "apt-get install rust" or "brew install rust" and don't care how it's built.
So you basicaly say "fuck you" to distribution developers and all the sysadmins that care about their systems, am I right?
Your aggression, insulting tone and condescension (throughout your comments in this thread) is not appreciated. Please stop.
All of them. This is not an exaggeration.
1. If an offline build does not work, that's a bug. This use case is one that we explicitly want and need, and do already support.
2. You are incorrect about Rust. Rust is written in Rust, not C++, and so building Rust involves downloading a binary of a previous Rust. That's what 'boostrapping' means.
From what I last saw of cargo there's not a clean path that lets you build from source that doesn't involve pulling binaries(and is really painful if you want to use cargo on a non-binary platform like RPi.
In the past the snapshots were taken almost weekly as massive language churn dictated. Now they're quite rare.
What's with all the baseless assumptions of the initial Rust compiler being written in either C or C++ in this thread?
Contrary to apparently popular belief, C and C++ aren't some primordial lifeform compiler language which all language implementations have to be initially written in. Believe it or not, you can write a compiler in any (general purpose) programming language! Amazing, I know.
> 2. You are incorrect about Rust. Rust is written in Rust, not C++,
And how that renders me incorrect? GHC is written in Haskell, but you can build it with C compiler (and then recompile again, now with Haskell compiler).
But indeed I was wrong. I remembered incorrectly that I built Rust cleanly and without network activity. I actually downloaded sources and issued compilation command, without any regard for packaging, so it could do any stupid stuff like downloading things when compiling.
> and so building Rust involves downloading a binary of a previous Rust. That's what 'boostrapping' means.
No. "Bootstrapping" means building a compiler using a compiler when you don't have that compiler. As I said elsewhere, compare that to OCaml and GHC, which can be built without downloading OCaml or GHC, respectively.
There's a ton of things I like about Rust but the points he outlined above are things that I've seen very much impede the adoption of Rust into some environments that have similar restrictions(no download on build, build from source without binaries) for security and reproducibility reasons.
They're all on the roadmap for the very near future, because Servo (and Rust-in-Gecko) needs them. There's nothing in the design of Cargo that prevents these from being solved.
Personally, I love Cargo. Autoconf is miserable and I would hate to go back to it.
[Security just scares the piss out of me in general; downloading binaries is probably the smallest problem.]
Pinning versions is simple. e.g., "=1.2.3".
You can read more about it here: http://doc.crates.io/crates-io.html
We will see what happens when a vendor write their own Rust compiler that has its own idiosyncrasies.
Compiling pure rust relies on the single compiler toolchain which is assumed to be present by cargo, and universal on all platforms. That's pretty solid.
...but rust = no autoconf is somewhat misleading; rust that uses c libraries has to solve all the same problems that anything else using c libraries has to; but unlike python or node, there is no help (ie. gyp or distutils) for you if you need to do this.
Perhaps eventually something clever will come along to fill the gap, but it's something of a pain point at the moment, especially on windows.
For example:
cfg_if! {
if #[cfg(windows)] {
mod windows;
pub use windows::*;
} else {
mod unix;
pub use unix::*;
}
}
Cargo supports versioning libraries (and seemingly does so sanely!). Obscure platform support is obscure.
However I enjoy even more memory safe system programming languages.
What I love in Rust, besides its ML influence, is making younger generations aware that systems programming languages don't have necessarily to mean unsafe by default or the primitive toolchains from C and C++.
You cannot take C out of C++, so how much help is C++17 if some cowboys in the team keep doing C style coding?
Yes, I know all about static analyzers and code reviews, but the sad truth is that in many companies there are lots of developers and management, that don't care a second about them.
This is specially true across companies whose main product isn't software development.
Const-correctness, use of references ("those things with ampersands by them...." said colleague A), exceptions are all unknown to them.
Object-slicing is a risk ("what's object slicing??").
Pointers are thrown around, added to multiple lists, no RAII, no initialisation of variables, use of memcpy everywhere, no copy constructors, C-style casts EVERYWHERE (including casting to siblings and their descendants...). Arrays are used everywhere, occasionally vectors are used but used like arrays (which isn't so bad), but they're used alongside arrays instead of replacing them; naked new/delete, use of malloc and realloc periodically; for loops are using instead of STL algorithms.
And this is a NEW codebase.
I am desperate to leave.
Does anyone need a C++ developer? Please, someone help!
Just in case it's taken the wrong way - I don't know what the author meant, but gdb works very well with Rust. Actually it "just works" for the debug builds.
There's an old adage: there is no portable software, only software that has been ported. What is the status of Rust on Windows? I understand there are ARM versions; are there any other supported architectures?
I like Rust a lot. It's my go-to systems language at the moment. But let's do keep the hype train somewhere near the tracks.
So, it's definitely achievable. Was done by Wirth at least twice (Pascal/P & Lilith) plus System/38 (later AS/400) at microcode level. Just takes modularity and a good intermediate language. Your adage is still true in that most screw up portability by using ineffective practices or not using effective ones. I rarely believe it when I see the word in a feature list.
No...gdb.
It means no need to explicitly define the type of a variable, the compiler infer it based on context.
An algebraic data type is generally made up of two things: 1) structs or tuples, which are useful but in most (but not all languages); C/C++ has them for example; and 2) tagged or disjoint unions, which are different from C unions in that you can tell which one of the union choices is being used (A variant is a particular tagged union).
Tagged unions are super-useful for pattern matching, so you get code like:
match rv {
Ok(_) => {
None
}
Err(CacheError::KeyNotFound) => {
Some(Resp::NotFound)
}
Err(ref err) => Some(from_cache_err(err))
}
The algebraic part means that these two features can be used in any combination with each other, and also refers to the link that, roughly 0 is the empty type, 1 is the unit type, structs correspond to multiplies (and gets called the product type), and unions to plus (so is called a sum type).
Why? Because if I have a tuple of a union of A or B or C, and another union of X or Y, I have 6 possible values in total, and (1+1+1) x (1+1) = 6.
Also, in any ADT system 0 should be exactly the empty sum and 1 exactly the empty product. This is what makes things hang together properly.
E.g., this is true in Haskell and it causes there to be some "extra structure" which often has to be smoothed over. Lots of library functions exist just to do this smoothing.
Abstract Data Type were introduced by languages like CLU, Mesa and Modula-2 among others.
It means having modules that only export the type names, but not their definition, while exposing functions/procedures to operate in such types.
It is not the same as the ADTs in functional languages, although they are quite similar.
They being similar how having a limited data structure (non extensible) with a set of functions that operate on it. Depending on the FP language ADTs can also partially hide their implementation like the Abstract Data Types in modular languages.
But I can also happily discuss the math theory and the denotational semantics about them across languages, but I don't think it will help for many readers.
Anyway, my original comment was wrong: in ML, every time you project a type component from a module, you always get the same type. So it's more like a strong existential. My bad.
(0) Rust doesn't really have much support for abstract data types. What Rust has is something not too unlike Haskell: you can hide `struct` fields [though not `enum` constructors], but the `struct` remains concrete. With a bona fide abstract data type mechanism, as in ML, you can give a module a signature that reveals the existence, but not the representation, of its type components. I'm guessing this much representation hiding isn't fully compatible with Rust's goals, which require knowing the sizes of types statically, unless they're behind a layer of indirection.
(1) Abstract data types have no relation whatsoever to type inference. [Nor do algebraic data types for that matter.] An abstract data type is an existential type: a dependent pair consisting of a type `T`, and a value whose type is `F T`, for some type function `F`. The closest thing Rust has to existentials is trait objects, but these can't do everything that existentials can do.
It certainly is.
The advantages over C++ seemingly never end. I'd add to the list: rigorous portability, non-broken macros, ADTs and pattern matching, a careful language stability protocol, standard test and doc tooling, flexible namespacing via visibility and modules, the absense of vast lacunas of undefined behaviour, simple numeric promotion rules, meaningful compile-time errors for generic code. Plus things already mentioned in the post like Cargo.
People tend to focus on the safety side of Rust, but as impressive to me is just the... solidity on all these other axes. If you stripped out lifetimes and the borrow checker you would still have an incredibly compelling alternative to C++.