Facebook picked Rust to implement Libra
reddit.com
reddit.com
Shameless plug - I made a proposal[2] to create Business Applications Working Group to help promote Rust in enterprise software, quant and "normal" finances, taxes, and governance, the areas now completely dominated by COBOL and Java. Rust is a perfect fit for such applications, offering more safety and security, speed and higher levels of abstraction. Hopefully, formal verification will arrive soon as well.
[1] https://github.com/rust-lang/rust/pull/61946
[2] https://internals.rust-lang.org/t/proposal-business-applicat...
The fraction of runtime involving allocation and deallocation, at the level where they happen, is typically negligible. In servers, after program startup, it is often (and deliberately) exactly zero.
I think using term "are abstracted away" is better choice here. You still allocate memory, dosen't matter if it's malloc/free, mmap/unmap or compiler is doing it for you. It cost time and space. Sometimes the cost is negligible but not always, depends on application.
I don’t think that was their point.
> The fraction of runtime involving allocation and deallocation, at the level where they happen, is typically negligible. In servers, after program startup, it is often (and deliberately) exactly zero.
This is at least slightly misleading, though.
Obviously, memory comes from somewhere. You can amortize costs by not needing to allocate new pages often.
Minimizing the amount of memory consumed by an application dynamically is the only way to absolutely reduce the cost. There’s lots of ways to do this, and plenty of C++ and Go software aim for “zero allocations.” However, there is still actually allocations in many softwares with “zero allocations” because they still use the stack.
For deeply concurrent applications, the stack ends up being a lot of memory. If you reduce the amount of stack memory per fiber, it reduces memory usage initially, but then fibers are more likely to hit the guard page and allocate more stack.
There’s strategies to reduce dynamic allocations pretty much all over (even in GC’d languages like Go.) The fact is, though, avoiding it is much akin to avoiding the GC. In Go, its actually identical to avoiding the GC.
(As a note in post, I acknowledge that not every concurrent application uses fiber style concurrency, but I believe with minor adaptations this point still stands for many classes of applications. Fully avoiding OS allocations is possible, but it definitely isn’t the “default” for C++ apps.)
——
This isn’t to say your point is not correct at least for some viewpoint, but it’s not actually that simple, which is absolutely worth noting.
In that case you don't use std::string, std::vector... or any containers at all? Or anything else that allocates, directly or indirectly.
Save money over what? It's usually a lot easier to optimize memory use than to rewrite code. Going by the 80/20 rule, 80% of the memory pressure on the GC will be created by 20% of the code. So amortize the price of the rewrite over the expected lifespan of the app. Then compare this to, let's say, the cost of optimizing 10% of the app to eliminate 40% of the memory pressure. Then, also factor in the likely rate of bugs introduced in a rewrite compared to the optimizing GC and the cost of incurring, finding, and fixing those bugs.
Going by this analysis, I would suspect that in some environments where rapid iteration is key, progress is fast, and apps have short lifespans, it might be better to optimize GC instead of rewrite to eliminate it. I'd also expect that in other cases, it is better to rewrite to eliminate GC.
So, the analysis of GC overhead is always going to pit cost X against cost zero, no matter how low you manage to get X.
This might be true in new development. The specific context in this discussion was rewrites.
So, the analysis of GC overhead is always going to pit cost X against cost zero, no matter how low you manage to get X.
Again, you're talking about new development. That's not going to fit everyone's situation.
The problem is that whatever level of GC overhead you start with, or achieve, it will be non-zero, and its actual magnitude, including typically big cache-footprint knock-on effects that show up attributed, in perf results, to mainline processing, will be practically impossible to estimate reliably without comparing against a rewrite.
So, instead, you generally have to say: we compared some similar(-ish) program Y that was rewritten and cut the number of server instances required to meet demand by 30%, 60%, or what-have-you. But, exactly for the reasons you cite, comparisons published are against performance under GC after that optimization has already been done, as much as was practical.
It sounds like you're most familiar with, and you're arguing from a situation where the cost/benefit tradeoff overwhelmingly makes efficiency the king. So sure, in that situation, don't use GC. Write code with those cost/benefit tradeoffs in mind. That's valid, probably awesome and wonderful in certain situations. However, that doesn't mean that those particular cost/benefit tradeoffs rule over everything, everywhere, and everyone else should follow suit.
that optimization has already been done, as much as was practical
Which could mean a lot of things. I think, for the sake of your argument, you're arguing that we can assume it means, "very close to maximum optimization." Sorry, but you can't make this assumption everywhere and always. It depends. As Matt Easton says: Context!
Indeed, a very great deal of code running on servers is in Python or Ruby. That's the low-hanging fruit before you start talking about GC overhead in a compiled language. But of course most of that is somebody else's code. People tend to be interested in what it costs to run their own code, not the next office over's.
If you believe your own argument, it would be foolish to start a rewrite while easy GC optimizations still await. Not everyone chooses wisely every time, but it's the charitable assumption.
Aside from that, rewriting something in C++ based on code in a higher-level language with better abstractions might cost additional developer time, maintainability, and quality.
But they're already advocating for a rewrite, just within the same language.
And, the answer is that real programs in obligate-GC languages spend overwhelmingly more time in GC than C++ or Rust. Much of this time is spent waiting on cache misses, which are hard to track to the responsible bit of code.
You're right that the GC isn't necessarily the issue. It's more the forced heap allocation which most GC languages come with.
That's actually true, as long as all things are equal. GC can amortize memory management cost. Of course at cost of more jitter.
Unfortunately many GC language users tend to do way more allocations as well, diminishing the advantage and even turning it into negative.
That's not really true anymore after the introduction of smart pointers. Basically C++ implements reference counting to manage memory as a result.
But we know that GC always imposes huge costs that point benchmarks uniformly fail to reveal. Often the costs are tolerable, or even negligible. At issue is the set of recourses available when they turn out not to be.
In fact, it can be worse in Java because you have no control over whether an object lives on the stack instead of the heap.
Make no mistake, rewriting is a huge expense, rarely embarked upon without readily demonstrated benefit. (Exceptions tend to be rewrites in Java for organizational / political reasons. But I digress.) Not spending the time, instead, adding features, and delaying new features until there is a place to put them, can dwarf the base cost of the rewrite. That rewrites are done frequently enough to be discussed tells you there are huge operational benefits available.
Because you want better battery life? Reduce power and cooling costs? Reduce cloud service bill?
So Java really is the new COBOL?
Android will keep Java relevant for a long time, even after the introduction of Kotlin.
I think it's great that you wanted to push Rust to the area where Java flourished (by Java I'm guessing Enterprise?). I respect your passion.
Personally, I never like a language that has esoteric syntax utilizing various non-alphabetical characters. Perhaps this particular aspect is what drew me to languages like Java/JavaScript. I don't mind writing "public static void" because writing code is like 10-20% (the rest is code-review, meeting stakeholders/Product Owner/PM, come up with plans, write documentations, etc) of my activity throughout a decade of my career as a Dev.
There are some caveats (or rather ... personal dislike) with Java and JavaScript for example: I don't like the Closure syntax in Java and I don't like the fact that JavaScript lacks cohesiveness => People who write ES5 code do have to implement patterns specific to JS in order to re-create some of the OOP constructs. ES6 with Class/constructor/static syntax help but then they added generator via '*' (asterisk, but why? why don't use the keyword 'gen' or 'generator' just like async/await keywords?).
The other thing I realized lately is that I prefer GC platform/ecosystem so that I can focus less on the platform itself.
1. Long ago, Rust had some interesting built in syntax for different kinds of pointers, and so people checked out Rust then, and didn't realize we got rid of it. This objection has happened less and less since that was ~5 years ago (wow time flies), but sometimes it still comes up.
2. The lifetime syntax uses a single apostrophe, like 'a. We took this syntax from OCaml (though slightly re-purposed), but if you haven't used OCaml, and many have not, it can feel very weird.
3. Not everyone prefers the "curly braces and semicolons" style of systems languages, and so they feel the <>s and ::s and {}s and ;s are noisy. We kept this style to be familiar to systems programmers.
In general, Rust doesn't have a lot of unique syntax, but it does draw from two generally disparate areas: functional languages and systems languages. If you haven't used both before, some of it can feel strange. It happens.
I started my journey from QBasic (high-school) to C/C++ (college) to Java to JavaScript and I have to admit that I use Java/JS the most throughout my career so my experience is biased toward my own personal experience.
Had I stuck with C/C++ for 10 years and dabble with Haskell/OCaml at night, I might feel different.
Once I got stuck in Java, I felt very comfortable there.
http://blog.plover.com/prog/Java.html
Money quote: "I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product."
I never believe in connecting programming language with quality product because I see no evidence.
People gravitate to work using languages with characteristics that suit them. Most people coding Java would be less happy with something else, and most people using something else would be less happy obliged to use Java.
Though, I can accept JS and Go (the last one takes a while).
Oh boy do I agree about the noise. I absolutely love Rust, and I definitely don't think it's noisy (in normal examples) but before I first learned Rust generic code feat like syntax soup. It seemed bizarrely messy and convoluted.
Mind you, I love Rust now. This is not a criticism towards Rust. It's simply a reflection on how a non-Rust programmer, largely non-Systems programmer saw Rust's flavor of syntaxes for Generics and Lifetimes.
How time flies. Now I push Rust at work where it makes sense and use it for everything in my personal (code) life.
My favorite part? Likely how it feels imperative while still offering functional features. Iterators, for example, are my favorite thing in the world. This is partially due to system shock I'm sure; the idea of iterators to this old Go programmer feels like magic haha, it was quite the change coming from Go.
What's the alternative? Text-based syntax ala Pascal/Ada is actually noisier than symbol- and short-keyword-based, because you don't ever get to file the "syntax" parts away as you become familiar with them; you have to process them visually every time you read that code. There may be a case for that sort of overly-verbose syntax as a form of literate programming - an introduction meant for users who are as of yet unfamiliar with any given system; but as an everyday practice it's quite painful!
When I first started learning Python I hated the idea of significant whitespace, now I think it is the best thing ever.
pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
vec![]
}<> for generics. Point 3.
'a for a lifetime. Point 2.
() , and {} for function syntax. Point 3.
pattern: type for arguments. This is in a few different languages, and doesn't fit into my below points, but the paragraph I made after the point.
& for references, point 3.
-> for the return type of functions. In the paragraph after.
! to indicate that vec! is a macro. This is pretty unique, actually. Ruby does let you use ! in function names, but that's not really the same thing.
[] is used to invoke vec! similarly to how you index anything else, that is, this creates an empty vec, like [] would create an empty array. This is sorta point 3 and the final paragraph.
None of this is to say that you're wrong about this; I think it just really demonstrates how hard it is to please people with syntax. None of this is unique to Rust, but the combination of influences is.
There's no silver bullet just like anything else. It's a matter of preference.
Generics is fine (exist in C++ and Java). Although I dislike crazy generics <T<S>> but that could be design problem.
<'a> (yeah technically it's just the 'a.
"->" non-alphabet, I came from C family (C/C++/Java) so return type stated earlier as part as the whole long-train of ceremonial stuff alongside the modifier (public static int myMethod)
Pointers and Reference: not my cup of tea but I understand it's important for system language. Others can argue its importance for "business apps" (or web-apps) but I never need pointers and references so _shrug_.
semi colon after input parameter:
query: &str
vs
string query
contents: &'a str Vec<&'searching str>
<--- the fact that now you can combine these non-alphabet stuff together => "&'a".
vec![] => exclamation mark squeezed between what appears to be a keyword "vec" and an array syntax
Again, don't get to riled up. I just personally don't enjoy reading syntax like this.
The syntax choices Rust made don't seem any stranger than e.g. Go. Rust just has more concepts because of what it's trying to accomplish.
I'm more in app-development.
Over the years I have just grown repeatedly to love static and typed. The larger my code bases the more it (dynamic features) always seemed to be something that caused me trouble. Typed languages felt bad for prototyping, but as time went on that argument of mine just didn't seem to hold water. I definitely don't feel that way now.
And, while I do like Rust's syntax, and have grown strangely fond to the syntax coined "The Turbofish" ::<>, I just haven't seen a typed language that can do what Rust can with a vastly more simplified syntax (ie, Python). I imagine it's not possible, but I'm not making claims here - just thinking out loud. Of course, Haskell and friends might be near that camp, but arguably even if the language is as powerful I'd they're too different to qualify for my statement.
Anyway, not trying to convince you of anything. Just thinking out loud. Carry on friend :)
This is how I feel when I saw any languages that utilize special characters. It is shorter, I give you that, but that shortness is taxing my brain.
No, I'm not asking for convincing as I mentioned I'm not the target audience of Rust (system programming, OS, etc).
Ironically at college my specialization was System Programming, OS, and Database. Pretty much infra stuff that Rust serves well :). Not sure what happened along the way that changed my mind.
auto multiply (int x, int y) -> int;
One of the many reasons why I stick with Java.
vec![1,2,3] declares a vector of [1,2,3]. But it isn't `keyword` ! `array`, it's more like vec(1,2,3) where vec is a variadic function. But instead of being a function, its a macro so its done at compile time using AST transformations.
Basically, `vec` isn't special, `!` is. `anything!()` or `anything![]` are ways to call macros.
I don't recall the exact transformation, but vec![1,2,3] is basically equal to
let v = Vec::new();
v.push(1);
v.push(2);
v.push(3);
Those who build data-pipeline, ML, processing big-data, they love constructs that can help them achieve their goal faster.
Those constructs are essentially processing collection type of constructs: predicates(), forEach(), map(), reduce(), transform(), filter(), etc.
Those who writes business-apps tend to favor OOP because they need to map business domains.
pub fn search<'searching>(query: &str, contents: &'searching str) -> Vec<&'searching str> {
vec![]
}
PUBLIC FUNCTION Search \
GIVEN REGION Searching \
TAKING Query: SHARED Str, \
Contents: SHARED Str REGION Searching \
GIVING Vector OF SHARED Str REGION Searching IS
TAKE Vector!Empty
END FUNCTION.
Check out COBOL. You'll love it. :-)
You are not going to find people that knows about avx or red-black trees in a Javashop in my experience.
That said, I’d hire them just don’t want to be them.
> avx or red-black trees in a Javashop in my experience.
You meant AVL right?
As much as I dislike Leetcode and whiteboarding interview culture, there's an army of people who know these stuff (data structure) working for
Google (largely Java shop), Amazon (boy, this one is a HUGE Java shop) LinkedIN (o yea, o yeaa...) Square, Twitter, etc.
I can go on but let's just stop there.
Try LeetCode and see how many submissions are in Java :). I'd say it's probably the most-used programming languages doing whiteboard data-structure styled interview.
It's weird to bring up big companies as they use every language under the sun and of course, they want beginner friendly languages for a big chunk of their work.
But I do think you underestimate the number of times they reach out for systems languages like C++, heck Fortran beats Java in numerical computing.
I haven't heard about LeetCode so I cannot comment on that. A site for unemployeed coders to find work?
> It's weird to bring up big companies as they use every language under the sun and of course
Why is it weird? it's the reality and they have massive amount of engineers that use Java/JavaScript.
For those who want massive salary, good-looking resume, and potential to work on solving interesting problem (potential, not guaranteed), they will have to prepare (grind) for the technical interview at Leetcode. Some take months.
> But I do think you underestimate the number of times they reach out for systems languages like C++
I don't. Amazon+LinkedIN+Twitter are super massive Java shops.
Let me turn the table around...
If you haven't heard Leetcode by now then well...¯\_(ツ)_/¯ (pardon me, I don't mean to attack you but this uhm... crazy whiteboarding/leetcode movement started in 2016 and have been taking our industry by storm).
Maybe you should try the site and solve 30 problems ranging from EASY, MEDIUM, and HARD to get some idea.
Hi-tech companies these days expect fresh-grad to be able to solve MEDIUM (trie, some combo-algo, dynamic programming, backtracking, string algo) level questions within 15-30 minutes.
NOTE: maybe the parent edited his comment between my reply and yours?
Rust can guarantee the elimination of race conditions in low-level multi-threaded code, but aside from that there's nothing really safer about its type system compared to say Java. And one would anyways use a higher-level concurrency library in Java, or perhaps the concurrency annotations, making the formerly mentioned advantage barely relevant.
Memory safety is certainly not the only kind of safety, but it is alas the only kind of safety supported by Rust (and every other language except C and C++).
I think the parent poster's entire point was that Rust does provide safety beyond memory safety. Perhaps not as a forced concept, ie: you do not have to express all structures as finite state machines, but you can very elegantly express your structures as finite state machines. And you can do so in a way that most other languages can't, because of affine types.
Anyway, I'm only clarifying that the parent poster was explicitly talking about safety outside of memory safety.
Using optionals, result types and match would give me a nice feeling too, but I won't claim that my code's safer because of that. Those are super low-level tools.
Whether you care about that or think it's valuable does not change that it is a way of encoding a model into your type system to make a class of errors impossible.
And the lack of evidence in this area suggests to me that the safety benefit is indeed negligible.
It should only suggest to you that it is prohibitively expensive to control for all of the different variables in order to provide a remotely reliable quantification.
> I see this statement is oft repeated on HN, but no proof is offered in its support.
Where "this statement" refers to
> It’s more safe than those languages because of its type system. Memory safety isn’t the only kind of safety, after all. :)
To paraphrase, you did not have proof that Rust had features that enabled safety beyond memory safety. I gave you an example of such a feature, and explained how it provides a type of safety beyond memory safety.
> And the lack of evidence in this area
There's plenty of evidence. Abstractly, the "program is in invalid state but continues" is a huge error in general.
More concretely, in terms of research,
https://www.microsoft.com/en-us/research/blog/p-programming-...
I could likely find thousands of other applications of FSMs (or papers on the subject) for safety critical work.
Here's one of the first results when I looked,
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/201600...
> To this end, state machine analysis offers a method to support engineering and operational efforts, identify and avert undesirable or potentially hazardous system states, and evaluate system requirements.
I don't really feel the need to argue that state machines are a powerful tool for improving correctness of code. I think I've already addressed that Rust provides safety features that are:
a) Not easy to express in other mainstream langauges
b) Do not fall into the category of memory safety
* Rust provides guaranteed memory safety. Memory leaks aside.
* Rust provides freedom from race conditions. Deadlocks aside.
What other kinds of safety does it provide? I often see optional/result/match or generally "the type system" brought up and this is what I'm explicitly challenging.
I'm confused because the entire thread is about answering this question and I even detailed it explicitly in the previous post.
It provides the safety from invalid state transitions in the form of opt-in state machine type encoding.
What else is there to discuss? I just gave you a concrete example, which you challenged on the basis that it was not impactful, so I provided you research showing otherwise.
Apparently rarer than the occasional typo (the above sentence contains two).
I've never had that experience in any other language. Usually unless you're careful and put effort into testing and making sure that you handle every possible exceptional case, you'll have several bugs and crashes. Of course these are possible in Rust, but in practice I'vr found they're mucb rarer. Most of these issues are caught by the compiler.
To be clear, I'm only stating that Rust is safer, not that safety is the end-all-be-all for every single application and you should never use COBOL or Java or even that you should prefer Rust over them in the general case or anything of the sort.
It is nice to be able to encode something in the type system, but one could just as well use design by contract or unit testing, and these actually do have supporting evidence in their favor. Is there even any supporting evidence that static typing results in better quality?
I think most would agree that it improves performance, makes refactoring and managing the code base easier.
Note: I'm also a fan of static type systems and of encoding relationships and requirements in them, but I have no proof that this actually improves quality. It makes things easier to reason about for me and maybe it eliminates some classes of errors, however it's not obvious that these classes of errors represent a noticeable amount of the total.
The thing I love the most in Rust is the duality between "&mut" and "&": when you have a "&mut" reference to something, you know nobody else has any "&mut" or a "&" reference to it, so you can modify the data structure without worry; and when you have a "&" reference to something, you know nobody else has any "&mut" reference to it, so you can read the data structure without worry. I wish I had something like that in Java, instead of having to sprinkle "synchronized" everywhere just in case (which not only doesn't protect against a recursive call within the same thread, but also can lead to AB/BA deadlocks... which is made so much more fun by code called from executors which have a ThreadPoolExecutor.CallerRunsPolicy, meaning not only will it happen only in production, it will only happen in production when the system is overloaded. Took us weeks of debugging to reproduce one instance of that...).
It's very hard to integrate Java and C. People don't normally do unless they have to. Random third-party libraries from internets usually don't.
I really don't understand why people constantly bring this up. What's supposed to be the problem in the first place?
Want a safe program? Just don't use "unsafe". Perfectly doable for the vast majority of programs.
Java has its "sun.misc.Unsafe". In addition for being unsafe by default when it comes to modifying same data between threads. It doesn't enforce synchronization, so Java programs incorrect in this aspect compile just fine.
> It's very hard to integrate Java and C. People don't normally do unless they have to. Random third-party libraries from internets usually don't.
I don't see how this is related to the discussion.
Bugs like this one: https://medium.com/@shnatsel/how-rusts-standard-library-was-...
> Want a safe program? Just don't use "unsafe"
There’s a lot of unsafe code already in standard library, even more in third-party libraries.
For this reason, I think VM-based runtimes are safer in general. It’s not free like in Rust, costs runtime performance especially startup time. But for Rust, we have to trust authors of standard library, and all other libraries we consume. That’s too many people to trust, and too much code to verify.
> I don't see how this is related to the discussion.
Java standard library doesn’t use unsafe code, it’s all pure Java, e.g. https://zgrepcode.com/java/openjdk/10.0.2/java.base/java/uti... Same with vast majority of third-party libraries.
Security boundary is lower on the stack, attack surface is much smaller at that level. We only have to trust/verify JVM code. Everything that runs on top of that, including the standard library, runs in a strong sandbox.
That said, in C++, unsafe is just form example a harmless looking pointer cast or array [] indexing away.
At least with Rust you know where the dragons lie. Just grep for "unsafe".
Aside from the language, understanding the Rust way of things certainly improved my code in Python and C too. And with "the Rust way" I mean the way you need to structure things if you don't want to end up fighting the borrow checker all the time. The concepts they use there make a lot of sense even in languages that don't enforce them and have been known before Rust was ever invented.
Edit: so in essence subjectively it makes me find more mistakes easier, it provides a beautiful environment for test driven development and working with it is a pleasure if you understood how things are meant to be done. This is all no real proof, but I certainly would feel more secure implementing critical code in Rust than I would doing the same thing in Python or C.
Python and C are similar in that regard. You can compile almost anything in them. Will then crash in runtime if not OK, gracefully for Python, the whole process for C.
Languages like Java or C# are different. Both are strongly typed, a lot of things are checked by compilers.
I believe C# is safer than Rust because native code surface is much smaller. Safe Rust is fundamentally limited by that borrow checker. Read the source of Rust standard library, you'll see tons of unsafe code everywhere. Rust developers probably did a good job verifying their implementations of stuff like Vec and HashMap, but there're less used parts of the standard library. Non-standard third-party libraries also using unsafe.
.NET doesn't need any unsafe code for such things. Even fundamental parts of the standard library, like List and Dictionary, are 100% managed code, to be specific it's C#: https://github.com/dotnet/coreclr/blob/master/src/System.Pri... Same is true for majority of third-party libraries: unsafe is supported by the languages, but using it may complicate deployment.
Custom data structures often need a lot of unsafe code. Graphs, trees and linked lists are everywhere in system programming.
You can’t add everything to standard library, too many variations.
For trees, in C++ and/or C# I’ve used red-black, B-tree, unordered, and multi-dimensional ones like BSP, k-d, and PK. Graphs are all different, depending on what you need to store (just the topology, per-node data, per-edge data), and which operations need to work fast on them. Even linked lists are different, sometimes you want single link, other times you want them to be circular instead of linear.
And there’re other pointer-based structures useful for some applications, like skip lists and tries.
Even then, that’s still a very small amount of the overall code in a given project.
On modern hardware, RAM latency is often the main reason why CPU-bound code is slow. The fix is often changing RAM layout, i.e. modifying data structures. And when the code uses SIMD to process the payload portion of these structures, alignment requirements cause them to become really custom pretty soon.
> that’s still a very small amount of the overall code in a given project
That’s not universal across all software. Lately, I’m working in the area of CAD/CAM/CAE. Before that I worked on videogames, HPC, multimedia. In many of these projects, data structures were not a small amount, even relatively speaking.
I wrote multiple projects in Rust and I never had to use unsafe even once. Arguably all these projects weren’t all that lowlevel, but why would I write something that somebody else has already implemented and tested? The beauty of Rust, after all is that you can go to the lowest level if you like to, but you can stay high level if you like and you still end up with code that is surprisingly performant.
Java and C# solved this problem without unsafe, with JIT compilers.
> The beauty of Rust, after all is that you can go to the lowest level if you like to, but you can stay high level if you like
All sufficiently complex systems are written in more than one language. Operating systems are written in C and C++, have shell scripting running on top. Videogames are written in C++, they have integrated script engines or VMs for higher-level stuff. Productivity software like MS office or AutoCAD have script engines.
No single language does the job. It’s not just performance versus safety tradeoff. These higher-level languages are much easier to learn, meaning developers are cheaper, and in many cases like VBA even non-developers can do stuff done with them. They often aren’t compiled or compile very fast, this makes iterations faster and allows interactive prototyping. They often run in sandboxes, solving security issues.
I don’t program in Rust, but I’ve read quite a lot about it. And I program C++ and C# for decades, often in the same software at the same time. IMO C++ is better at lower-level things: tooling, SIMD, manual control over RAM layout, better at creating fast data structures, OpenMP, has way better libraries (e.g. in the current project I use Eigen a lot, it’s based on C++ metaprogramming i.e. not portable to anything else). C# is better for everything else: it’s safer, has way better libraries included (e.g. async IO is awesome), is higher level, for the last couple of years it’s cross-platform and open source, and is much easier to use.
An example in the standard library is MutexGuard - you get one when you lock a mutex, and when you drop it, that releases the mutex. You can't forget to release the mutex, and you also can't release it too early, because then you lose access to the data protected by the mutex. There are ways to defeat this, of course, but you have to go out of your way to do it.
I've used a library which uses a similar pattern for writing to a ring-buffered message queue: when you grab a slot in the queue to write to, you get a SlotGuard, and when you drop it, you lose access to the slot, but that commits the slot and lets other threads read it.
The type system knowing about ownership and borrowing also allows the elimination of race conditions (outside of `unsafe`, of course...). I don't know of a GC language that also does that, though obviously that doesn't mean there isn't one... ;)
Rust doesn't get rid of race conditions. It lets you write memory safe concurrent code. These are two separate things. You still have to be cognizant that code may not run in the order you expect.
This is still a great language feature.
1 - https://nim-lang.org/docs/manual_experimental.html#guards-an...
Java is a great glue language. But if the problem you are solving can't be fixed by glue, say performance, computationally heavy algorithms or something of that kind, then look elsewhere.
Today we are using static or dynamic code checker (which are not cheap) but it would be so much better if we could simply not create some kind of issues in the first place.
I know that Rust is not a silver bullet either but having some Rust support in Vxworks makes so much sense. This is basically my secret wish of the last few years coming true. If anyone at Windriver is reading this, thank you!
It does not mean we are going to rewrite everything tomorrow, but at least we can seriously consider that for new features we could introduce some Rust services in a few years likely.
C++ makes things look simpler than they are and eventually you end up in one nightmare scenario after another, because of all the hidden complexity.
Rust just shoves all that complexity to the forefront, right in your face, so that you are forced to deal with it and don't end up in nightmare land later.
Rust is a more modern language, so there are a number of modern approaches that Rust uses that C++ can't due to backwards compatibility. And Rust isn't fundamentally an OOP language. I'd say Rust is a bit closer to C than C++, but that's a gross simplification.
But I think what Rust does is forces the developer to address application complexity at compile time, instead of finding out about these problems during run time. Things like segfaults, race conditions, etc. are ferreted by the compiler.
So, Rust might feel more complex, but in reality it's just forcing you to deal with those issues sooner rather than later.
So C++ programmers are able to subvert the upfront complexity by ignoring C++ 11 features then, going straight to raw pointers.
But being realistic, i dont think any non-GC´ed language has a chance to become the next corporate darling as Java is now.
In that sense, Go, Swift, C#, etc are much more fit to become the next kings in this area, and even them will do it very, very slowly.
The script family of languages also dont make a good fit, giving they tend to be bad at creating big, performant and constantly evolving kind of programs (Javascript, Python, etc).
I guess the languages which are AOT compiled, GC´ed and mostly objected oriented with some mix of FP will probably be more of a fit the take the crown jewels of the king Java.
The problem Rust will face in this scenario, is that it requires people with a level of brain power that contrary to 'high tech' is not that much available in the corporate level, (and the ones that have dont want to spend all of their lives behind a computer screen).
And also is a "productivity hog", when we compare to sophisticated languages like C# or Swift, as productivity in Rust is on par with C++, which is not good enough when compared even with the verbose and over-enginered Java codebase.
It´s basically the same reasons why, C++ is not the prefered language there. And i dont think just using the magic word 'safe' will have any charm for this kind of crowd. Giving while Rust can use this trick against C and C++, it doesnt work for productivity minded languages like Go, Kotlin, Swift and C#.
Mind you that modern GC´ed languages are pretty safe, and also pretty fast. So it will be very hard to convince the corporate layer to use a language where there will be scarcity of labor, and that means they will have to pay more and be able to have less employees.
The smartphone revolution gave performant and resource aware languages a renaissance and Rust is surfing in this wave. Rust has a lot of chance in smartphone, embedded, libraries and utilities and even in specific scenarios on the server.
But even for the "rewrite all in Rust" mantra for C++ (a language Rust is competitive with) it will stop going forward, giving the Unix, C and C++ codebases are pretty much very influential and with a lot of sophisticated and complex stuff already out there.
Anyway, i dont understand this urge to use just one language for everything. I think this is unrealistic and illusory, and i think its a better approach to elect two or three languages with fitness in some fields and just use them.
The "one language to rule them all" was already the Java approach since the nineties, and while it make it a very popular language, it was in a time where the competition were not that great and even then, it proved to not work really well in all scenarios (and i think thats a good thing because it means we are free from a computer language monopoly, which would slow down the evolution in the field).
What are the chances it's a placeholder for malicious/trojan code intended to steal Libra coins? (c.f. the event-stream backdoor[2])
Should really be:
https://crates.io/crates/someorg/libra
https://crates.io/crates/facebook/libra
A) Packages can change owners without changing names (and breaking downstreamers)
B) It encourages creative names, rather can calling something myusername/http, you have to give the package a real name like hyper, express, curl, etc.
Who wants this?
Seems like this is survivorship bias. All of the common names get squatted by people who never push code, and then anyone who's actually going to build something will need to pick something unique.
Reqwest is more popular than request, for example. It's not exactly what most would expect, and if you search "request" you get the much less popular crate.
I don't know. I'm unconvinced that this is a meaningful metric, and I worry more about typosquatting/ malicious dependencies, which, to my knowledge, crates.io does almost nothing to proactively deal with.
Usually, orgs won't be comfortable with this..
(B) is brilliant... We all know what EC2 and S3 is... If Amazon had just called these services for: compute and storage, there wouldn't be any brand.
Branding makes things easier to search for and to talk about.
All this said, these downsides might be worth it
npm install burrito doesn't.
Crates.io has all sorts of other problems where it assumes good faith.
I am not personally interested in cryptocurrency, but it's always great to see more big companies using Rust!
This is the second time this has happened to me today, you'd think I would have learned. Sigh.
If you wonder what is meant by that, I think I know of an example. They have done this (quite unusual) choice to not include a Cargo.lock into their project because it gives a bad developer experience on merge conflicts [1]. They'd love to have a merge tool for the purpose, see more in [2].
My ideal would be "cargo test --coverage=report/".
The most popular Ethereum implementation (Geth) is written in Go. The second most popular Ethereum implementation (Parity) is written in Rust.
Now, Libra is written in Rust.
So I guess the moral of the story is, if you want to write a greenfield high performance application, Go or Rust should be your choice compared to C++.
I don't see how this generalization follows from the three examples you've cited?
Rust in production use tends to be found in circumstances where there is no need for mature tooling, and no expectation of a need to hire experienced coders. Of course there are exceptions.
The tooling does need to be more mature but for many projects the pioneer tax paid to improve the tooling may be worth it. Besides, it's not as if C++ dependency management is very mature either — most people build custom tooling for that anyway.
Go is not in the same performance category as Rust and C++. It has more limited use cases where it works well, due to mandatory runtime. Rust and C++ are more general purpose.
Some types of software require memory safety models that Rust was not designed to express e.g. safety models when mutability of references and ownership of objects are not observable at compile-time. High-performance database engines tend to have this challenge due to pervasive DMA-ed I/O and opaque page-structured memory. The OS hides this from most applications that aren't high-performance systems code. In C++ (which also looks askance at these memory models) this is addressed by designing an execution scheduler to dynamically guarantee safety; the scheduler understands the memory model and never schedules or executes a sequence of concurrent operations across a set of mutable references that would violate the safety model -- the operations are oblivious. In modern designs this requires no locks and negligible state.
Rust can deal with these types of memory models too while minimizing the amount of unsafe code with enough layers of indirection, it just has a high performance cost.
Backend and infrastructure sees more Rust though. Eg the Mercurial server implementation.
Most languages that offer optional GC, including Rust (with its RC and ARC boxing) and C++ (with std::shared_ptr), implement it mainly via reference-counting.
Many of the unsafe operations don't exist in OCaml. Often because the GC makes them unnecessary.
There will of course be explanations why the holes are really not Rust's fault, and that bugs and security failings are possible in any language, but it will force a more realistic assessment of Rust's strengths.
For example, the real fix for their vulnerable code example is using automatic bounds checking, just as Rust does. Replacing [] with at, eliminates the vulnerability. Most C++ programmers are allergic to at, so Mozilla could have created some container wrappers that do this by default. GCC and I think also clang have a macro which adds automatic bounds-checking to the STL containers.
And for decades of C and C++ programmers, [] is still the most obvious way to index an array. And the most obvious way creates potential security vulnerabilities.
See Rusty Russell's classic "easy to use versus hard to misuse" posts: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html and https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html .
Bounds checking is slower, so that's the main reason why it's shunned. Rust made it mandatory, but from what I've seen there are people disabling that to squeeze some drops of performance nevertheless. Luckily, I think Rust also has an option of replacing indexing with iteration, thereby avoiding the performance hit. I think it currently does this a bit better than C++, but I might be wrong.
Anyway, my critique still stands, that blog post is really low effort and doesn't prove much. I've looked at some of the fixes for Firefox security bugs and the code reminds one of the typical older C++ projects with raw pointers everywhere. Perhaps implementing a browser requires all sorts of unsafe access patterns.
I'm not arguing that bounds-checking should be mandatory. I'm arguing that bounds-checking should be the default, and you should have to knowingly bypass it, rather than the other way around.
It's really just not accurate to say "they weren't writing good C++" or "it's a legacy codebase". Those could both be true things, but it's totally glossing over the hundreds of millions of dollars invested in fixing that codebase.
If browsers had remained sane, allowing one to download HTML, CSS and pictures instead of running so-called applications, they would have been secured a long time ago and we would have had a decent internet instead of this spyware and ads infested mess.
With the rate of change that they're subjected to, they will never be secure. In 10 years Firefox will perhaps be 50% Rust and still full of vulnerabilities.
This has no bearing on the issue. Yes, browsers are fast moving codebases. No one is arguing otherwise.
> In 10 years Firefox will perhaps be 50% Rust and still full of vulnerabilities.
Someone has already cited a case study from Mozilla showing a significant improvement in memory safety for components moved over to Rust, so all evidence at this point is to the contrary.
AppStores can also perform various checks which will never happen on web sites. The web is really the wild west, why do you think browsers are the main attack vector nowadays?
C++ is coded quite differently today than when Gecko was written -- at least, in places where the official Coding Standard does not forbid it. Mozilla and Google's do.
After the more-realistic assessment, claims about Rust's inherent safety will need to be walked back some. It will still be an enormous improvement on C.
Is there an easy way to map all links of form www.reddit.com/* to old.reddit.com/* on all my devices? (I assume /etc/hosts would work for linux?)
https://chrome.google.com/webstore/detail/old-reddit-redirec...
In order to redirect it on all your devices, install Firefox. It can install extensions on Android, too. Should solve it for everything except smart TVs (Firefox for Amazon TV can't install extensions) and iOS.
I think that's how an ad-blocker worked on iOS before they enabled the functionality.
No, because both www.reddit.com and old.reddit.com (in fact, *.reddit.com) already map to the same IP address. They are distinguished through the Host HTTP header. The only way to do that mapping would be within the browser (or with a MITM proxy, which I wouldn't recommend).