Rust required to build Gecko
groups.google.com
groups.google.com
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++.
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.
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.
I started with QBASIC :-(
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.
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.
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..
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!
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.
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.
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.
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.
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.
Or ocaml...
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.
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.