Something can have merits and still only be a trend (I the sense that it starts to gain a bit of traction and then dies off). These things are not opposites and the ways programming languages live and die are quite complicated, sometimes the weirdest ones go on to rule the world, while other which look promising never leave their niche.
It seems to be the platform that keeps things sticky. C has Unices, embedded systems, and kernels. Javscript has browsers as a platform. C# and VB have Windows as a platform. etc.
Rust doesn't appear to have a platform to keep it sticky yet, so as you say it may have merit but only be a trend.
Blurry distinction. C has Unices but so has everything else, other than .NET-before-a-half-mature-Mono and decades-out-of-date historic win/dos-only langs/IDEs/compilers.
So things like momentum/inertia, fewer-stumbling-blocks-on-the-platform, network effects, and critical-mass-tipping-points are still also in diffuse play imho..
Although pcwalton doesn't agree with me, I believe system languages, based on history of computing, always require a platform for success.
A small example, not all of them became mainstream.
- Burroughs B5500, ESPOL followed by NEWP, nowadays known as Unisys ClearPath
- Xerox Star, Mesa
- UCSD p-System, Pascal
- Constellation OS, Pascal
- Lilith, Modula-2
- Ceres Workstation, Oberon
- Blue Bottle OS (AOS), Active Oberon
- UNIX, C
- Symbian, C++
- BeOS, C++
- NeXT, C and Objective-C
- Windows, C, C++ and .NET
- Mac OS, Object Pascal, C, C++
- OS X, C, Objective-C, Swift
- Android, Java, C++
This is just a tiny sample, I could come up with many more.
This was quite relevant before the widespread of FOSS culture, because we tended to just use/buy the tools of the OS vendor, and most managers wouldn't sign an order to buy yet another expensive compiler just to make some developers happy.
Also languages that aren't first tier on a platform always suffer from integration issues, regarding FFI, tooling with the underlying platform.
Whereas using the OS official languages is just turn the key and go, so to speak.
Rust probably already got its sweet spot with Firefox's adoption and universities that are adopting it for OS classes.
Most runtimes aren't making syscalls directly. They go through glibc, musl, etc. So the're going through C to get to the Unices. In otherwords, they don't have Unices: they have C.
>So things like ...
Sure. But fundamentally the network effects and critical mass tipping are predicated on the value of the platform, not the value of the language. The platform is the primary component. Otherwise, how could Javascript become so popular? Or Visual Basic? Or Emacs Lisp? Or R? They're all ostensibly warty languages but they carry on through the fantastic and very valuable platform they give access to.
To adapt a cliche from politics: "It's the platform, stupid."
Firefox is not a platform. It can be a great public works project to demonstrate the power of Rust. But there's nothing sticky or network effectful of Firefox using Rust.
> Most runtimes aren't making syscalls directly. They go through glibc, musl, etc. So the're going through C to get to the Unices. In otherwords, they don't have Unices: they have C.
At the time I think Java was a god-send, in terms of impact, if only for a short while. At least from the limited perspective of the code-bro-kiddie that I was back then, it filled a glaringly empty spot perfectly: that of transitioning from understanding Basic and Pascal, to understanding the basic principles behind most other languages that I had failed to grasp earlier, notably C/++. The "serious languages" (C, Perl) were cryptic, the "simple languages" were "toys", no Python/Ruby/etc to speak of (in my universe). Just simple choices such as calling pointers "references", omitting their funny operators, memory management, and presto, Basic/Pascal with braces and more expressive "records", I'm sure made many things click for many developers for life and allowed crossing of a certain chasm there. Also it really propelled MS to come up with a neat, clean, well-designed, robust "answer", which they did.
One thing I think Sun got wrong with Java was being religious against AOT compilation.
Had that option been part of the standard toolchain, instead of only commercial JDKs, I bet there would even be more people adopting it instead of keep using C and C++ for certain classes of user space applications.
IMO, Rust is the most promising technology of the decade.
We had C and C++ for a long time, and never managed to replace them. We created higher level languages (Haskell, Go, Java) as a mitigation but they never really succeeded in that domain.
Instead, they found they own favorite tasks, and are used for it. We now have better tools for other tasks, but C and C++ are still untouched.
Then arrived Rust. Something really low level. Something that is compatible with C, can do what C does, but better, safer, easier to write. Something with a terrific community improving the language at an amazing pace.
But what surprise me the most is the professional attitude of rust designers. They are pragmatic, but promote best practices. They don't get in the heat of the moment, but are passionate. They listen to the community and yet maintain a coherent design. They are working meticulously and are very productive.
Those are usually opposite qualities, you only see them joined in attitude of masters of some sort.
That is amazing to witness.
P.S: I think you need to know at least one very high level language, one very low, and one specialized in some task if you want to have versatility in your tool-belt.
I used to recommend Python, C, and one among Go/Erlang/JS/Java/Swift depending of your tasks.
I think it's time to recommend beginners to learn rust before C (although I recommend Python before rust). I hope that C will become to the new generation, what assembly is to us.
Having not written much Rust yet, I agree from the outside.
I still use C and C++ in my daily job. I tried D, which wanted to be a "better C++", but the problem was it didn't really add anything new -- it tidied up various rough edges, but didn't offer enough benefits to be worth the switch.
I never took other candidates, like Go, seriously. While there are programs written in C and C++ which probably should be written in something like Go, it wasn't a serious replacement for places where C/C++ really excel.
Rust seems to provide real benefits. Also (and importantly for external people like me), is being used to write real software I'm using. Firefox (obviously), and also 'rust-parallel', and 'ripgrep', which have just slotted into my daily life and work cleanly, fast and well.
IMO D is exactly that, "a better C++", and does not try to be anything more. Rust, on the other hand, is more of a "this is a tool that should address all your C++ needs" (which means it won't be better than C++ in all aspects), and it does try to be something more.
D seems to be designed to be a language that has the exact same powers (or better) as C++, but tidied up. C++ has over time grown to be a very powerful language but these powers are all bolt-on and don't interact well together. D is a language designed from the perspective of "Okay, we have all these C++ features being used in these ways, let's build a more holistically-designed language that has the same features, and correct all the mistakes along the way". I think it's good to have language refreshes like this. You get a chance to fix all the warts and make improvements without breaking backcompat. It's very useful alternative to C++ when you need something that behaves very much like C++. Plus, it has `extern (C++)`, which makes it super easy to incrementally drop in to C++ code.
Ultimately, Rust is pretty different. It doesn't have template metaprogramming. It doesn't have inheritance. While most of the problems solved by these tools can be solved in other ways in Rust, it doesn't change the fact that Rust introduces more paradigm shifts. Of course, safety is a benefit that pretty much overshadows this, but there is something to be said for languages like D which are "better C++"s without changing the paradigms involved.
No they wouldn't. But most people learning C didn't get the benefit over Assembly. Java over C. Python over Java.
Unless you learn everything, you can't know.
But we are passed this stage of the computing era where we can master everything.
You have now excellent bankers, geographers, designers, sysadmin that need programming and will just need to learn Python and nothing else.
And what about the coders of custom OS for very low powered embeded board ? They can't learn NodeJS + Webpack. They don't have time for that.
You don't have a lot of concurrency ? Don't learn Go or Erlang.
You need a few automation. SQL is not for you.
It's VERY GOOD to go outside of bubble and learn new things. If you have time, learn some functional languages, read about how to build your own interpreter, have fun with the amazing possibilities of deep learning.
But you don't have infinite time, you must make a choice.
And I believe strongly Rust is a good replacement for C/C++ and will be in the future.
Should we stop learning C ? Well you'll need C dev for the next 30 years so as a market skill, it's worth it.
But in 5 years, you will be able to get away with just Rust skills. And you may be happier.
In my opinion good practices being enforced by the language/compiler is even more beneficial for beginners than it is for experienced programmers, especially because in C it's up to the student to figure these out by himself. Or with the teaching material, but if we can offload that to the compiler, why not?
> Would a beginner see the benefits of rust without first understanding the drawbacks of C?
Better, it would make him aware of C's shortcomings when the time comes to learn C, instead of getting the wrong idea C is the only path to systems programming.
I learned systems programming back in the 80's via Assembly, Turbo Basic, quickly followed by Turbo Pascal.
When the time came to learn C, I was already on Turbo Pascal 6.0, and the frustrating part was being aware that there was already a better way of talking to the machine.
Also another point, was that C pointers were never confusing to me, because I learned the best practices in those languages.
pj I always detect a degree of "disdain" for C in your comments. Back in the 80s everything was system programming if you wanted performant software. C replaced Pascal during the 80s because it was a better language - simple as. Today I code almost entirely in C and rarely need to use Assembly. C started to be used beyond Unix during the 80s (AmigaOS was written in C except for third party IO library written in BCPL) because it is a small and very concise language; Pascal had just too much abstraction - for example how it dealt with bitwise operations. This meant C compilers could do better jobs in terms of optimisation. This is reflected in C replacing Pascal in PC game programming in the late 1980s and early 1990s. Also a lot of Amiga games were also written in C (Cinemaware games) and Megadrive games too (Sonic Spinball, Ecco etc.). In short C is just the best HLL out there when it comes to programming systems with meager resources. As for Rust - like Go - its supporters will eventually throw in the towel. C is king of system programming.
Having had to learn assembly when I was young to get anything interesting done (on a C64) was such a valuable asset for my whole programming life - to know what the processor actually does allows me to see through all those layers of abstraction we have today. Let it be imperative, procedural, functional, oo, declarative, whatever, at the end of the day, on current hardware you branch on equal, or you branch on not equal or carry etc., and little more.
I recommend everybody to write some fun projects in assembly if you really want to understand what's going on. My last one was John Conway's game of life and it was pure fun.
Well, it's not exactly the same. You can install another compiler on Unix, or compile it, and ignore C if you have time and talent.
On the browser we are stuck. It's sandboxed and restricted by the network so you can't install whatever you want. The user will install only what he wants, and he usually knows jack not does he want to wait more then 3 seconds.
So unless webassembly becomes the savior, JS is on terrible, horrible only path to the Web plateform.
> You can install another compiler on Unix, or compile it, and ignore C if you have time and talent.
True nowadays, back when UNIX was being adopted no department would pay for that foreign language compiler when they already payed quite a few bucks for the UNIX SDK.
Still that language won't keep you away from C, if you need to interact with OS APIs.
sametmax, I think C should be taught after a short course in assembly. Then you can review each compiler you use in terms of what it is likely to do to your source code as you write it. But I agree that for most developers C is probably too low level for day-to-say work. Therefore, you could loss a lot of potential developers but I think such an approach would make for better engineers. In fact I can see the notion of any compiled language becoming an anachronism outside system programming and possibly AAA game programming.
I work for one of the one of the companies that uses Rust in production (see https://www.rust-lang.org/friends.html for a partial list). We're pretty happy with it.
I like Rust because it offers in an interesting combination of features:
1. Rust feels a bit like a good modern scripting language: It's doesn't segfault, the command-line tools are standard and mature, and it has excellent management of third-party libraries. You don't need to be constantly paranoid and vigilant to write correct code in Rust the way you need to be when working with C pointers, for example.
2. Rust feels a bit like C++: It's fast (when used correctly), it provides a "bare-metal" level of control, it doesn't require a GC, and it has generic types. Generic types are a mixed blessing: They're good for performance and correctness, but they can sometimes be a bit complex.
3. Rust feels a tiny bit like a functional language: Data is immutable by default, and you have a rich toolbox for building abstractions.
On the downside, Rust does have a learning curve. If you have solid experience with both C++ and a language like JavaScript or Ruby, plan on a week or two with Rust before you're comfortable. If you've never worked in any language with pointers, or if you've never worked in a language with anonymous functions, it might take longer.
Another Rust weakness is IDE support. Visual Studio Code and Emacs are both pretty reasonable, but if you're used to Java or C# IDEs with sophisticated refactoring support, that won't be mature in Rust until later this year.
I also find that with Rust, I spend a lot more time getting my code to compile, but once it does compile, it almost always works correctly on the first try. This can sometimes feel like "fighting with the compiler", but when you think about it, that's a lot better than "fighting with the debugger" or adding tons of printf statements everywhere. This "if it compiles it probably works" property also means that I can refactor aggressively and trust the results. But it still feels weird sometimes.
Sorry! My browser is set to French, so I pasted the wrong URL. Fixed.
There's actually a surprisingly large French-speaking Rust community, which you can find on Mozilla IRC at #rust-fr.
I work for Faraday in Vermont (http://www.faraday.io/). We have, I think, 6 Rust applications. These include cage (http://cage.faraday.io/), which is an open source tool for developing complex, multi-"pod" Docker projects. We also use Rust for moving lots of data into and out of machine learning systems quickly, and we're going to be using for more data loading tasks soon.
I think Rust's merits are real but mostly those of OCaml or Haskell which have been around for decades. I'm glad to see an ML-family language finally having a cultural moment - it's a bit unfortunate that it comes with manual memory management that 99% of programmers don't need, but it's still a great thing.
Rust is also giving the - to put it bluntly - idiots - who insist their application has to be written C or C++ "because it's fast" a better language without having to overcome that idiocy. I'm not sure if that's a good or a bad thing - it's beneficial in the short term, but letting idiotic attitudes towards performance persist seems like storing up trouble for the future.
For the people who genuinely need manual memory management Rust is a major breakthrough. But those people are such a tiny niche as to not be worth worrying about. People who claim to need manual memory management are overwhelmingly likely to be in the previous category.
But those people are such a tiny niche as to not be worth worrying about.
I don't disagree with your assessment, but one reason why there's enthusiasm for Rust is that this niche hasn't had any real alternatives (save maybe D?) for years.
> it's a bit unfortunate that it comes with manual memory management that 99% of programmers don't need
For what I've seen, that's actually the #1 feature of Rust.
A programmer who wants to use a ML-like language that doesn't need that feature should instead be using Haskell or F#; Rust is designed for systems-level programming, where being able to control every cycle of the processor is important. For that, you need manual memory management.
> A programmer who wants to use a ML-like language that doesn't need that feature should instead be using Haskell or F#
Indeed. Since I think that's the majority of programmers (whether they know it or not), I wish it was Haskell and F# that were getting the mainstream attention, and Rust that was the niche language with the, well, small cult following.
Well I'm one of those idiots then. Currently, I'm employed to write very fast scientific and engineering software. We work almost entirely in C because it gives the performance we need (and not just because of memory management). Programming in C makes it very easy to assess what is causing performance bottlenecks as the disassembly maps tightly to the C code (typically 1:3 to 1:6 source to instruction ratio). This makes it easy to assess if the symbolic code needs changing or the compiler just isn't doing a good enough job and you may need to use intrinsics or rewrite in assembly. And I can tell you this is a massive sector employing a lot of engineers.
I mean, what do you want me to say? Yes, judging by what you've said and without knowing the details of your requirements, I think it's most likely you (and your organization) are among the idiots. I've worked in that sector, replacing that kind of code with higher-level code in a "slow" language that somehow managed to run orders of magnitude faster, because when you're in the trees of disassembly and intrinsics it's all too easy to miss the forest of using the wrong algorithm or even making a calculation that just isn't necessary. Even in the cases where you don't make that kind of mistake, you can fix a problem with generated assembly as many times as you like and it will all be worthless compared to fixing the problem in the compiler once and for all.
There is good, valuable work being done in that world, don't get me wrong, and it's entirely possible you're on that side of things - but it's very much the exception rather than the rule IME.
Well if you use a poor implementation or the wrong algorithm then you're going to get poorer performance in any language. However, all things being equal, you're not going to get better performance from a higher level language and you certainly cannot fine tune the implementation for a particular platform as you can with lower level code - that's a fact. Now whether it is worthwhile doing that depends on each case and how long the process takes to execute. I often prototype in higher level languages including R, Python and C#. Once I need a professional implementation or put them into commercial software I use C even if the front end is written in C#. C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.
> all things being equal, you're not going to get better performance from a higher level language
Not remotely true if one of those things being equal is programmer time/effort, IME.
> you certainly cannot fine tune the implementation for a particular platform as you can with lower level code
Compilers can and do. JIT can allow even better tuning than is possible in C, as it can take the input data into account.
> C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.
Not remotely supported by any benchmark I've ever seen. The latest techempower benchmarks show a factor of 1.3x-7x difference between C and C# depending on the benchmark; the shootout is similar as far as I can tell from the unhelpful website. Not even a single order of magnitude, much less orders plural. (And benchmarks are the best possible case for C: tiny pieces of code where you can do a level of manual tuning that would be completely unreasonable to do on realistic-sized programs).
Just for fun try implementing gauss jordan method in C# - it is prohibitively slow once you go beyond a dimension of 10 where you have millions of linear systems to solve. C has no problem even with much, much larger systems. As for data size - rule number one, when implementing a numerical method you always vectorise and unroll where possible. That means padding your data to a multiple that eliminates remainder loops and helps compiler exploitation of SIMD or VXA. If padding cannot be applied for a particular numerical method then use sparse or elimination methods to get the requisite multiple. In short, you control the data size, alignment and packing - the programmer determines what is best for the target platform and doesn't leave it in the hands of the run-time environment gods.
In my experience there are orders of magnitude differences between C and C# when you get down to heavyweight number crunching. I implemented a simple kriging method in C# as a demo for my colleagues it took about 2 minutes for a really modest situation with handful of controls and low resolution grid. I was actually concerned that my implementation was really crap. I migrated the same algorithm over to C and it took about 5 seconds. In fairness that was about 5 years ago but makes the point. For other things like FFTs there is only a gain of about x2 migrating to the C language. But that modest change is probably due to the fact that both the C# implementation and C implementations are using native libraries for cos and sin which is typically where the bottleneck is for any DFT implementation.
We're both entitled to our opinions, but I've mentioned a couple of specific public (published) benchmarks for mine - do you have anything like that for yours?
Could you provide a link to heavy numerical operations - btw, ones that use native libraries don't count cause it ain't the C# implementation doing the work? As I've said there are some routines where C# performs fine but for heavy-weight modelling requiring intense arithmetic matrix/vector operations it is just too slow. What's more the benchmark for a single run does not always scale to many. The overhead becomes compounded when you're doing the same operation over and over again due to GC and cache misses.
C is a pain in the ass to do the things that C# is good at. If it works for you across the board then fine but I would stop assuming everyone else is an idiot.
I talked to a guy at Mozilla once and he said they got a pretty instable build. Some tests take a few runs before you know they are really okay and don't fail because something is wrong.
The build itself is stable. The testsuites, not so much. The problem is that written testcases sometimes unwillingly rely on timing or races. When you have thousands and thousands of tests, as Firefox has, there's a reasonably likelyhood at least one of them will trigger.
The tests are mostly written in JavaScript, the language Firefox needs to run, so not much Rust can do there.
To understand the constrains we have here, a ballpark figure is that we run a million tests per commit across all platforms (this is based on counting test files, so doesn't account for the fact that some files can contain thousands of separate test functions, but also doesn't account for the fact that we don't run every test job on every push). On average we see around 10 test failures per push due to test instability. So "on average" tests fail about one time in one hundred thousand. Of course, in reality there are some tests that fail much more often than this (one time in a hundred, say) and many that ~never fail.
Whilst test raciness is perhaps the most common problem, we also see intermittent failures due to race conditions in the browser code itself as well as through infrastructure instability. However it's unclear that moving to Rust will make much difference anyhow; Servo still sees intermittent tests so merely eliminating data races in safe code is insufficient to fix this problem.
This is a really interesting problem area. Tests that fails sometimes are really annoying because of the "broken windows" analogy. Are you using the most unstable tests as input of what to redesign next? Is it kind of a "deal with it" situation, where you need to retry the test suite a couple of times per commit, until it becomes green?
How do you rule out that the races are a problem in the code vs a problem in the tests? If we have tests that are sometimes red, we strive hard to remedy them. We've found issues before where we thought it was the tests that were wrong when it was actually the code.
You can't easily, you have to debug them. Debugging intermittent test failures is hard, and you have no guarantee you're actually improving much tangible things despite the time invested in them. It just sucks.
Intermittently failing tests are a problem that all large code bases have, regardless of the used language. See for example this post about Google's code base[1], which is largely Java, Python, and to some extent Go and Dart, IIUC: https://testing.googleblog.com/2016/05/flaky-tests-at-google...
[1] They don't say which code base the post is about, so I'm just assuming that it's not Chromium. If it is, it'd largely be C++.
I believe the difference is that you can no longer build without Rust. The original post in that thread talks about requiring it being the default - those are not the same.
Indeed:
If you're maintaining Firefox on a tier-3 platform which doesn't have
good rust support, please be aware that Firefox 53 will be the last
upstream release where rust is optional.
61 comments
[ 3.1 ms ] story [ 65.4 ms ] threadSomething can have merits and still only be a trend (I the sense that it starts to gain a bit of traction and then dies off). These things are not opposites and the ways programming languages live and die are quite complicated, sometimes the weirdest ones go on to rule the world, while other which look promising never leave their niche.
Rust doesn't appear to have a platform to keep it sticky yet, so as you say it may have merit but only be a trend.
So things like momentum/inertia, fewer-stumbling-blocks-on-the-platform, network effects, and critical-mass-tipping-points are still also in diffuse play imho..
It's interesting to observe that Rust is developed to make Firefox more secure, faster and easier to maintain.
Maybe there is indeed something to the platform analogy for the success programming languages?
A small example, not all of them became mainstream.
- Burroughs B5500, ESPOL followed by NEWP, nowadays known as Unisys ClearPath
- Xerox Star, Mesa
- UCSD p-System, Pascal
- Constellation OS, Pascal
- Lilith, Modula-2
- Ceres Workstation, Oberon
- Blue Bottle OS (AOS), Active Oberon
- UNIX, C
- Symbian, C++
- BeOS, C++
- NeXT, C and Objective-C
- Windows, C, C++ and .NET
- Mac OS, Object Pascal, C, C++
- OS X, C, Objective-C, Swift
- Android, Java, C++
This is just a tiny sample, I could come up with many more.
This was quite relevant before the widespread of FOSS culture, because we tended to just use/buy the tools of the OS vendor, and most managers wouldn't sign an order to buy yet another expensive compiler just to make some developers happy.
Also languages that aren't first tier on a platform always suffer from integration issues, regarding FFI, tooling with the underlying platform.
Whereas using the OS official languages is just turn the key and go, so to speak.
Rust probably already got its sweet spot with Firefox's adoption and universities that are adopting it for OS classes.
Lets see.
Most runtimes aren't making syscalls directly. They go through glibc, musl, etc. So the're going through C to get to the Unices. In otherwords, they don't have Unices: they have C.
>So things like ...
Sure. But fundamentally the network effects and critical mass tipping are predicated on the value of the platform, not the value of the language. The platform is the primary component. Otherwise, how could Javascript become so popular? Or Visual Basic? Or Emacs Lisp? Or R? They're all ostensibly warty languages but they carry on through the fantastic and very valuable platform they give access to.
To adapt a cliche from politics: "It's the platform, stupid."
Firefox is not a platform. It can be a great public works project to demonstrate the power of Rust. But there's nothing sticky or network effectful of Firefox using Rust.
Good point, that!
Had that option been part of the standard toolchain, instead of only commercial JDKs, I bet there would even be more people adopting it instead of keep using C and C++ for certain classes of user space applications.
We had C and C++ for a long time, and never managed to replace them. We created higher level languages (Haskell, Go, Java) as a mitigation but they never really succeeded in that domain.
Instead, they found they own favorite tasks, and are used for it. We now have better tools for other tasks, but C and C++ are still untouched.
Then arrived Rust. Something really low level. Something that is compatible with C, can do what C does, but better, safer, easier to write. Something with a terrific community improving the language at an amazing pace.
But what surprise me the most is the professional attitude of rust designers. They are pragmatic, but promote best practices. They don't get in the heat of the moment, but are passionate. They listen to the community and yet maintain a coherent design. They are working meticulously and are very productive.
Those are usually opposite qualities, you only see them joined in attitude of masters of some sort.
That is amazing to witness.
P.S: I think you need to know at least one very high level language, one very low, and one specialized in some task if you want to have versatility in your tool-belt.
I used to recommend Python, C, and one among Go/Erlang/JS/Java/Swift depending of your tasks.
I think it's time to recommend beginners to learn rust before C (although I recommend Python before rust). I hope that C will become to the new generation, what assembly is to us.
I still use C and C++ in my daily job. I tried D, which wanted to be a "better C++", but the problem was it didn't really add anything new -- it tidied up various rough edges, but didn't offer enough benefits to be worth the switch.
I never took other candidates, like Go, seriously. While there are programs written in C and C++ which probably should be written in something like Go, it wasn't a serious replacement for places where C/C++ really excel.
Rust seems to provide real benefits. Also (and importantly for external people like me), is being used to write real software I'm using. Firefox (obviously), and also 'rust-parallel', and 'ripgrep', which have just slotted into my daily life and work cleanly, fast and well.
D seems to be designed to be a language that has the exact same powers (or better) as C++, but tidied up. C++ has over time grown to be a very powerful language but these powers are all bolt-on and don't interact well together. D is a language designed from the perspective of "Okay, we have all these C++ features being used in these ways, let's build a more holistically-designed language that has the same features, and correct all the mistakes along the way". I think it's good to have language refreshes like this. You get a chance to fix all the warts and make improvements without breaking backcompat. It's very useful alternative to C++ when you need something that behaves very much like C++. Plus, it has `extern (C++)`, which makes it super easy to incrementally drop in to C++ code.
Ultimately, Rust is pretty different. It doesn't have template metaprogramming. It doesn't have inheritance. While most of the problems solved by these tools can be solved in other ways in Rust, it doesn't change the fact that Rust introduces more paradigm shifts. Of course, safety is a benefit that pretty much overshadows this, but there is something to be said for languages like D which are "better C++"s without changing the paradigms involved.
This is one thing I've been musing over. Would a beginner see the benefits of rust without first understanding the drawbacks of C?
In my opinion they'd just see it as "this annoying borrow checker thing" and find it frustrating.
I started with QBASIC :-(
Unless you learn everything, you can't know.
But we are passed this stage of the computing era where we can master everything.
You have now excellent bankers, geographers, designers, sysadmin that need programming and will just need to learn Python and nothing else.
And what about the coders of custom OS for very low powered embeded board ? They can't learn NodeJS + Webpack. They don't have time for that.
You don't have a lot of concurrency ? Don't learn Go or Erlang.
You need a few automation. SQL is not for you.
It's VERY GOOD to go outside of bubble and learn new things. If you have time, learn some functional languages, read about how to build your own interpreter, have fun with the amazing possibilities of deep learning.
But you don't have infinite time, you must make a choice.
And I believe strongly Rust is a good replacement for C/C++ and will be in the future.
Should we stop learning C ? Well you'll need C dev for the next 30 years so as a market skill, it's worth it.
But in 5 years, you will be able to get away with just Rust skills. And you may be happier.
Better, it would make him aware of C's shortcomings when the time comes to learn C, instead of getting the wrong idea C is the only path to systems programming.
I learned systems programming back in the 80's via Assembly, Turbo Basic, quickly followed by Turbo Pascal.
When the time came to learn C, I was already on Turbo Pascal 6.0, and the frustrating part was being aware that there was already a better way of talking to the machine.
Also another point, was that C pointers were never confusing to me, because I learned the best practices in those languages.
Having had to learn assembly when I was young to get anything interesting done (on a C64) was such a valuable asset for my whole programming life - to know what the processor actually does allows me to see through all those layers of abstraction we have today. Let it be imperative, procedural, functional, oo, declarative, whatever, at the end of the day, on current hardware you branch on equal, or you branch on not equal or carry etc., and little more.
I recommend everybody to write some fun projects in assembly if you really want to understand what's going on. My last one was John Conway's game of life and it was pure fun.
We already had them, but then the industry adopted UNIX as the infrastructure OS, and C came along.
Just like the browsers brought JavaScript along for the ride.
On the browser we are stuck. It's sandboxed and restricted by the network so you can't install whatever you want. The user will install only what he wants, and he usually knows jack not does he want to wait more then 3 seconds.
So unless webassembly becomes the savior, JS is on terrible, horrible only path to the Web plateform.
True nowadays, back when UNIX was being adopted no department would pay for that foreign language compiler when they already payed quite a few bucks for the UNIX SDK.
Still that language won't keep you away from C, if you need to interact with OS APIs.
I like Rust because it offers in an interesting combination of features:
1. Rust feels a bit like a good modern scripting language: It's doesn't segfault, the command-line tools are standard and mature, and it has excellent management of third-party libraries. You don't need to be constantly paranoid and vigilant to write correct code in Rust the way you need to be when working with C pointers, for example.
2. Rust feels a bit like C++: It's fast (when used correctly), it provides a "bare-metal" level of control, it doesn't require a GC, and it has generic types. Generic types are a mixed blessing: They're good for performance and correctness, but they can sometimes be a bit complex.
3. Rust feels a tiny bit like a functional language: Data is immutable by default, and you have a rich toolbox for building abstractions.
On the downside, Rust does have a learning curve. If you have solid experience with both C++ and a language like JavaScript or Ruby, plan on a week or two with Rust before you're comfortable. If you've never worked in any language with pointers, or if you've never worked in a language with anonymous functions, it might take longer.
Another Rust weakness is IDE support. Visual Studio Code and Emacs are both pretty reasonable, but if you're used to Java or C# IDEs with sophisticated refactoring support, that won't be mature in Rust until later this year.
I also find that with Rust, I spend a lot more time getting my code to compile, but once it does compile, it almost always works correctly on the first try. This can sometimes feel like "fighting with the compiler", but when you think about it, that's a lot better than "fighting with the debugger" or adding tons of printf statements everywhere. This "if it compiles it probably works" property also means that I can refactor aggressively and trust the results. But it still feels weird sometimes.
There's actually a surprisingly large French-speaking Rust community, which you can find on Mozilla IRC at #rust-fr.
I work for Faraday in Vermont (http://www.faraday.io/). We have, I think, 6 Rust applications. These include cage (http://cage.faraday.io/), which is an open source tool for developing complex, multi-"pod" Docker projects. We also use Rust for moving lots of data into and out of machine learning systems quickly, and we're going to be using for more data loading tasks soon.
Rust is also giving the - to put it bluntly - idiots - who insist their application has to be written C or C++ "because it's fast" a better language without having to overcome that idiocy. I'm not sure if that's a good or a bad thing - it's beneficial in the short term, but letting idiotic attitudes towards performance persist seems like storing up trouble for the future.
For the people who genuinely need manual memory management Rust is a major breakthrough. But those people are such a tiny niche as to not be worth worrying about. People who claim to need manual memory management are overwhelmingly likely to be in the previous category.
I don't disagree with your assessment, but one reason why there's enthusiasm for Rust is that this niche hasn't had any real alternatives (save maybe D?) for years.
For what I've seen, that's actually the #1 feature of Rust.
A programmer who wants to use a ML-like language that doesn't need that feature should instead be using Haskell or F#; Rust is designed for systems-level programming, where being able to control every cycle of the processor is important. For that, you need manual memory management.
Or ocaml...
Indeed. Since I think that's the majority of programmers (whether they know it or not), I wish it was Haskell and F# that were getting the mainstream attention, and Rust that was the niche language with the, well, small cult following.
There is good, valuable work being done in that world, don't get me wrong, and it's entirely possible you're on that side of things - but it's very much the exception rather than the rule IME.
Not remotely true if one of those things being equal is programmer time/effort, IME.
> you certainly cannot fine tune the implementation for a particular platform as you can with lower level code
Compilers can and do. JIT can allow even better tuning than is possible in C, as it can take the input data into account.
> C is just orders of magnitude faster than C#, even when the C# multithreaded, is coded in unsafe mode and optimised and C is single threaded and compiled with no optimisation.
Not remotely supported by any benchmark I've ever seen. The latest techempower benchmarks show a factor of 1.3x-7x difference between C and C# depending on the benchmark; the shootout is similar as far as I can tell from the unhelpful website. Not even a single order of magnitude, much less orders plural. (And benchmarks are the best possible case for C: tiny pieces of code where you can do a level of manual tuning that would be completely unreasonable to do on realistic-sized programs).
Just for fun try implementing gauss jordan method in C# - it is prohibitively slow once you go beyond a dimension of 10 where you have millions of linear systems to solve. C has no problem even with much, much larger systems. As for data size - rule number one, when implementing a numerical method you always vectorise and unroll where possible. That means padding your data to a multiple that eliminates remainder loops and helps compiler exploitation of SIMD or VXA. If padding cannot be applied for a particular numerical method then use sparse or elimination methods to get the requisite multiple. In short, you control the data size, alignment and packing - the programmer determines what is best for the target platform and doesn't leave it in the hands of the run-time environment gods.
In my experience there are orders of magnitude differences between C and C# when you get down to heavyweight number crunching. I implemented a simple kriging method in C# as a demo for my colleagues it took about 2 minutes for a really modest situation with handful of controls and low resolution grid. I was actually concerned that my implementation was really crap. I migrated the same algorithm over to C and it took about 5 seconds. In fairness that was about 5 years ago but makes the point. For other things like FFTs there is only a gain of about x2 migrating to the C language. But that modest change is probably due to the fact that both the C# implementation and C implementations are using native libraries for cos and sin which is typically where the bottleneck is for any DFT implementation.
Could you provide a link to heavy numerical operations - btw, ones that use native libraries don't count cause it ain't the C# implementation doing the work? As I've said there are some routines where C# performs fine but for heavy-weight modelling requiring intense arithmetic matrix/vector operations it is just too slow. What's more the benchmark for a single run does not always scale to many. The overhead becomes compounded when you're doing the same operation over and over again due to GC and cache misses.
http://www.sebastiansylvan.com/post/why-most-high-level-lang...
I love C#, I think it is a great language but it just doesn't belong at the level where I NEED to code at.
https://msdn.microsoft.com/en-us/library/ms973852.aspx
C is a pain in the ass to do the things that C# is good at. If it works for you across the board then fine but I would stop assuming everyone else is an idiot.
Hope Rust will get this problem solved :)
The tests are mostly written in JavaScript, the language Firefox needs to run, so not much Rust can do there.
Whilst test raciness is perhaps the most common problem, we also see intermittent failures due to race conditions in the browser code itself as well as through infrastructure instability. However it's unclear that moving to Rust will make much difference anyhow; Servo still sees intermittent tests so merely eliminating data races in safe code is insufficient to fix this problem.
Another problem is that running the tests takes ages.
[1] They don't say which code base the post is about, so I'm just assuming that it's not Chromium. If it is, it'd largely be C++.