-
Ad-Blocker Performance increased by 69x with New Engine Implementation in Rust
https://brave.com/improved-ad-blocker-performance/QuoteWe therefore rebuilt our ad-blocker taking inspiration from uBlock Origin and Ghostery’s ad-blocker approach. This focuses on a tokenization approach specific to ad-block rule matching against URLs and rule evaluation optimised to the different kinds of rules. We implemented the new engine in Rust as a memory-safe, performant language compilable down to native code and suitable to run within the native browser core as well as being packaged in a standalone Node.js module. Overall, we found that:
- The new algorithm with optimised set of rules is 69x faster on average than the current engine.
So, what does this have to do with Rust?
If they had it written in C it would be probably 300 times faster...
-
Ad-Blocker Performance increased by 69x with New Engine Implementation in Rust
https://brave.com/improved-ad-blocker-performance/QuoteWe therefore rebuilt our ad-blocker taking inspiration from uBlock Origin and Ghostery’s ad-blocker approach. This focuses on a tokenization approach specific to ad-block rule matching against URLs and rule evaluation optimised to the different kinds of rules. We implemented the new engine in Rust as a memory-safe, performant language compilable down to native code and suitable to run within the native browser core as well as being packaged in a standalone Node.js module. Overall, we found that:
- The new algorithm with optimised set of rules is 69x faster on average than the current engine.
So, what does this have to do with Rust?
If they had it written in C it would be probably 300 times faster...
It's just a demonstration of how Rust is being accepted by industry, and able to compile into very performant executables while having many advantages over C.
-
While I personally am a rank amateur programmer, we had a job at work about 2 years ago to write a kind of server. It had some data structures, a bunch of algorithms etc. not a huge project, but not trivial either. The young programmer who usually writes c++ wanted to do it in Rust. I said go for it. He wrote it in a few weeks. The server program has run now for two years under heavy load every day and has crashed zero times. That was a fairly impressive demo for me.
-
So, what does this have to do with Rust?
Some tools originally written in C, (grep) are actually faster in Rust (ripgrep). Nevermind the fact that Rust's worst case is nowhere near 300x slower, what do you think this is, an interpreted language?
If they had it written in C it would be probably 300 times faster... -
So, what does this have to do with Rust?
Some tools originally written in C, (grep) are actually faster in Rust (ripgrep).
If they had it written in C it would be probably 300 times faster...
Thanks to better algorithms and despite the language.Nevermind the fact that Rust's worst case is nowhere near 300x slower, what do you think this is, an interpreted language?
300x compared to 69x, relatively speaking 4.347826087 times faster
-
Microsoft starting to look at RUST as a more secure alternative to C, C++
https://www.theregister.co.uk/2019/07/18/microsoft_rust_security/
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/
-
Microsoft starting to look at RUST as a more secure alternative to C, C++
https://www.theregister.co.uk/2019/07/18/microsoft_rust_security/
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/
More accurately, "one small part of Microsoft starting to look at Rust".
It is a start, but the accumulated code (etc etc) is a big impediment. -
To me, using a language that is not standardized is a big impediment in itself. Some others may not care. I do.
Of course you can say that it's a chicken-and-egg question and that to get a chance to be standardized, a language first has to come into existence and get used widely enough. But when a language is at this "early" stage, you often have to stick to just ONE compiler, giving it your full trust even when there's nothing that can really tell you how robust it is, except a bunch of fanatic users.
And that said, there have been SO MANY attempts releasing alternatives to C and C++ in the past 30 years or so, all meant to be that much safer, cure all diseases and solve world hunger... which one has really taken off? (And don't get me started with Java!
)
Not saying that it's not interesting though - I've taken a look at Rust on several occasions and there are interesting concepts, although I find it a little too "bloated" already (I tend to lean towards Wirth's philosophy of "lean" languages, although I think he may have taken this a bit too far.)
I'm just really wondering what would need to be done in order to come up with a new language that really has a chance to take off and replace older languages that are still widely used. Yeah accumulated code is of course a big problem, but I think this is far from being the only one.
-
To me, using a language that is not standardized is a big impediment in itself. Some others may not care. I do.
Of course you can say that it's a chicken-and-egg question and that to get a chance to be standardized, a language first has to come into existence and get used widely enough. But when a language is at this "early" stage, you often have to stick to just ONE compiler, giving it your full trust even when there's nothing that can really tell you how robust it is, except a bunch of fanatic users.
And that said, there have been SO MANY attempts releasing alternatives to C and C++ in the past 30 years or so, all meant to be that much safer, cure all diseases and solve world hunger... which one has really taken off? (And don't get me started with Java! )
Not saying that it's not interesting though - I've taken a look at Rust on several occasions and there are interesting concepts, although I find it a little too "bloated" already (I tend to lean towards Wirth's philosophy of "lean" languages, although I think he may have taken this a bit too far.)
I'm just really wondering what would need to be done in order to come up with a new language that really has a chance to take off and replace older languages that are still widely used. Yeah accumulated code is of course a big problem, but I think this is far from being the only one.
You are being a bit blinkered by your prejudices.
Smalltalk was highly influential, and is embedded in several complex HP and Tektronix instruments.
Objective-C has also been rather successful, and is only recently being overtaken by Swift.
Java has taken off and succeeded extremely well in areas where C++ tried and failed dismally. OTOH, Java failed in the embedded arena.
As for languages with a standard, C/C++ is extremely good: there are so many different C/C++ standards to choose from.
As for whether Rust will succeed, only time will tell. It does have some beguiling core principles that avoid the frequent problems with C/C++, but it doesn't (yet) have the ctitical mass. -
You are being a bit blinkered by your prejudices.
If you say so. We are all expressing our own opinions here. I'm not claiming that I hold the Truth.
My only prejudice though here, I think, is my initial reaction of considering Rust as "yet another me too wannabe". Sure it's a prejudice, not denying, but based on experience. We'll talk about it in 10 years from now if we are still around, I won't have a problem with being proven wrong.Smalltalk was highly influential, and is embedded in several complex HP and Tektronix instruments.
Smalltalk's initial design actually predated C, and had pretty different objectives IMO, so it doesn't fall into the categories I was mentioning whatsoever (I was absolutely not saying that NO other language than C and C++ was worth considering!) But yes it has been highly influential, as many other languages of that era.
As to being used, that's a very small niche you're talking about.Objective-C has also been rather successful, and is only recently being overtaken by Swift.
AFAIK, only Apple made it successful, and it's already declining now. Still the epitome of a niche. I actually found Objective-C better designed than C++, so this could have been one I had been happy to see taking over at least C++.
As to being used, that's still a niche we're talking about, and it's probably going to disappear completely once everything has migrated to Swift. Or something else.Java has taken off and succeeded extremely well in areas where C++ tried and failed dismally. OTOH, Java failed in the embedded arena.
To me, JAVA is a disgrace for many reasons that would be too long to expose here. It has succeeded in some areas, I agree. That's the only serious example of a replacement here. I just don't think it has been a sane one, but that's another story. It worked. So whatever we think of the language, there are probably key ideas in it and in the way it was promoted that need to be considered to partially answer my last question.As for languages with a standard, C/C++ is extremely good: there are so many different C/C++ standards to choose from.
It's the only guarantee to me that the tools will be correctly designed and do what they are supposed to. Yes standards are evolving, so? Does that make them irrelevant? I don't think so. Incidentally, the major languages that are still in common use today in safety-critical applications, such as C and ADA, are standardized. Call me when Java, Smalltalk or Objective-C (or now Rust) is used in such applications. (And I hope Boeing is not taking this as a hint
)
Again, as I said above, that's my own view and criterion. If you don't care or even think standards are counter-productive, good for you. To each his own.As for whether Rust will succeed, only time will tell. It does have some beguiling core principles that avoid the frequent problems with C/C++, but it doesn't (yet) have the ctitical mass.
Of course only time will tell. Again, I'm just pointing out the absurd number of previous attempts all wishing the same thing, all having core features supposed to avoid the frequent problems with C and C++.
And I'm not bashing the idea of attempting to do so per se, I'm just convinced they all have been missing some critical points that I'm not completely sure about at this point (if I were, I may make such an attempt myself ), and, again, I do think this goes beyond the mere force of habit or huge code bases, even though those obviously count.
Not willing to rain on Rust's parade. I just haven't detected anything in Rust that would really separate it from the previous attempts, but I'd be interested in hearing which features exactly could make it different, and in which areas specifically.
-
As for whether Rust will succeed, only time will tell. It does have some beguiling core principles that avoid the frequent problems with C/C++, but it doesn't (yet) have the ctitical mass.
Not willing to rain on Rust's parade. I just haven't detected anything in Rust that would really separate it from the previous attempts, but I'd be interested in hearing which features exactly could make it different, and in which areas specifically.
All you have to do is look at the tutorials and documentation at, for example, https://doc.rust-lang.org/book/ Having said that, the concepts are scattered and introduced gradually; the Java whitepaper was much better in that respect.
Essentially there appear to be a number of relatively small concepts which cumulatively remove many of the gotchas, particularly in the areas relating to concurrency and memory. In addition there are design styles based on those concepts that encourage people to "think concurrent" in ways that have been shown to be workable. -
I prefer Neil Young's Rust Never Sleeps.
Hey hey, my my
Bugs in code will never die -
All you have to do is look at the tutorials and documentation at, for example, https://doc.rust-lang.org/book/ Having said that, the concepts are scattered and introduced gradually; the Java whitepaper was much better in that respect.
Well, I have! Granted not extensively... and yes it's not really summing things up.Essentially there appear to be a number of relatively small concepts which cumulatively remove many of the gotchas, particularly in the areas relating to concurrency and memory. In addition there are design styles based on those concepts that encourage people to "think concurrent" in ways that have been shown to be workable.
Well, yes. But again, I haven't really seen anything that was not already tried in other languages for the same reasons. Maybe it's all in the small details and the exact set of all the language features that they chose for Rust that makes it different, but it's not very obvious to me.
-
All you have to do is look at the tutorials and documentation at, for example, https://doc.rust-lang.org/book/ Having said that, the concepts are scattered and introduced gradually; the Java whitepaper was much better in that respect.
Well, I have! Granted not extensively... and yes it's not really summing things up.Essentially there appear to be a number of relatively small concepts which cumulatively remove many of the gotchas, particularly in the areas relating to concurrency and memory. In addition there are design styles based on those concepts that encourage people to "think concurrent" in ways that have been shown to be workable.
Well, yes. But again, I haven't really seen anything that was not already tried in other languages for the same reasons. Maybe it's all in the small details and the exact set of all the language features that they chose for Rust that makes it different, but it's not very obvious to me.
There was a revealing major difference between the academic papers from the C/C++ community and the Java community:- Java community: referenced the concepts and experience found in a wide range of languages and environments
- C/C++ community: referenced other C/C++ literature, and appeared not to know much about other languages and enviroments. That doomed them to reinventing wheels, poorly
A notable feature of the Java whitepaper was that it clearly stated the key principles, where they came from, why they had been proven good, and how they all worked well together. Summary: wide knowledge plus good taste.
The Rust document lacks the clarity, but I'm beguiled about their sense of taste in a way I've only found with C (in 1981!), Smalltalk, Java and - for hard realtime applications - xC. -
For the most part I've dismissed Rust as something like Go or Node.js; lots of hype from fans, but nothing you couldn't do in a library in any major language. Plus the language fans try to build it up by tearing down other languages. There are lots of good languages and technologies. It is really hard to say that everyone should program in x or everyone shouldn't program in y.
Reading through this thread, I saw in Rust documentation that it doesn't support NULL but uses algebraic data types like Haskell. That, in and of itself, is a major plus in my book. When Java tried to fix C++ or MS did C# and .Net, they all made the mistake of keeping NULL ... and making it the default! If anything, C++ handles NULL better by pushing value semantics and references that don't have NULL.
So yeah, I guess I am intrigued by Rust now. -
For the most part I've dismissed Rust as something like Go or Node.js; lots of hype from fans, but nothing you couldn't do in a library in any major language. Plus the language fans try to build it up by tearing down other languages. There are lots of good languages and technologies. It is really hard to say that everyone should program in x or everyone shouldn't program in y.
Reading through this thread, I saw in Rust documentation that it doesn't support NULL but uses algebraic data types like Haskell. That, in and of itself, is a major plus in my book. When Java tried to fix C++ or MS did C# and .Net, they all made the mistake of keeping NULL ... and making it the default! If anything, C++ handles NULL better by pushing value semantics and references that don't have NULL.
So yeah, I guess I am intrigued by Rust now.
That's pretty much my view.
One of my heroes created that "billion dollar mistake"; https://en.m.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions -
One of my heroes created that "billion dollar mistake"; https://en.m.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
Certainly one of mine as well.
Now of course there can be a fine line between what's reasonable and what's not.
We could also say that we should get rid of the zero value in all numerical representations so that no computation would ever result in a "divide by zero" error (which can potentially ruin a program's execution just as badly as a bad reference). Would that be going a little too far?
-
Just found this new subforum with nothing in it. Took the opportunity to start a thread about my favourite programming language, https://rust-lang.org It's a systems language, similar to C, but with more safety guarantees and modern features like iterators. It's slowly being adopted in the embedded landscape as well. Ask Me Anything.
I don't see why someone should throw everything he invested in the continuously improving and dominantly used C++ away.
As i see it the things Rust claims to improve can also be achieved with C++ by appropriate methodology and (possibly future) static checking/diagnostic tools, but at a overall lower and also incremental effort.
As i see it stagnation before C++ 11 might have triggered the Rust people to try their own way, but this is becoming more and more obsolete. -
Just found this new subforum with nothing in it. Took the opportunity to start a thread about my favourite programming language, https://rust-lang.org It's a systems language, similar to C, but with more safety guarantees and modern features like iterators. It's slowly being adopted in the embedded landscape as well. Ask Me Anything.
I don't see why someone should throw everything he invested in the continuously improving and dominantly used C++ away.
Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!QuoteAs i see it the things Rust claims to improve can also be achieved with C++ by appropriate methodology and (possibly future) static checking/diagnostic tools, but at a overall lower and also incremental effort.
You miss a critical point: presuming it is even possible that can only be achieved in a subset of C++. And every person/group/company chooses a slightly different subset.
Now try to guarantee your program's properties when using libraries from 10 different sources - you simply cannot. -
Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!
That might not be the best example to chose. Semiconductor memory started displacing core memory at the beginning of the 70s, but it took until the mod 80s to displace it from high reliability applications.
-
Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!
That might not be the best example to chose. Semiconductor memory started displacing core memory at the beginning of the 70s, but it took until the mod 80s to displace it from high reliability applications.
It was clear, in 1978, that core memory was the past, and semiconductor memory the future. It didn't take a genius to see that! -
If anyone wants to get their feet wet with embedded Rust, The Discovery Book is a introductory tutorial using the STM32F3DISCOVERY board. Fair warning, it is not a tutorial on the Rust language itself. There's also The embedded Rust book, and The embedonomicon for more in-depth coverage.
-
It was clear in 1972 that core memory was the past. However. core was still being designed into fresh high reliability applications in 1980.Agreed, but neither should they stay with something when something better is available. For example, I was once offered a job in a company that made core memory when semiconductor memory was available!
That might not be the best example to chose. Semiconductor memory started displacing core memory at the beginning of the 70s, but it took until the mod 80s to displace it from high reliability applications.
It was clear, in 1978, that core memory was the past, and semiconductor memory the future. It didn't take a genius to see that!
-
OTOH, it's not clear in 2019 that Rust is the future.
-
OTOH, it's not clear in 2019 that Rust is the future.
Just so!
As I wrote earlierQuoteRust and Go are beguiling, but I've seen too many languages with claimed advantages that turned out to be minor and unimportant. Ignoring them and concentrating on the real advances has been key to my career.
Neither Rust nor Go directly tackles a key emerging problem: many core processors with NUMA memory hierarchy. The only languages I've seen that do tackle it head on are CSP, Occam and the modern incarnation, xC. Note that the concept of "channels" is taken directly from CSP and Occam.