Why Not Rust?(matklad.github.io)
matklad.github.io
Why Not Rust?
https://matklad.github.io/2020/09/20/why-not-rust.html
319 comments
> Not All Programming is Systems Programming
Personally I often use Rust for "non systems-programming" tasks, even though I really wish a more suitable language existed.
Rust has plenty of downsides, but hits a particular sweet spot for me that is hard to find elsewhere:
* Expressive, pretty powerful, ML and Haskell inspired type system
* Memory safe. In higher level code you have almost zero justification for `unsafe`, unless you really need a C library.
* Immutable by default. Can feel almost functional, depending on code style.
* Error handling (it's not perfect by any means, but much better than exceptions in my book)
* Very coherent language design. The language has few warts, in part thanks to the young age.
* Great package manager and build system.
* Good tooling in general (compiler errors, formatter, linter, docs generation, ... )
* Library availability is great for certain domains, decent for many.
* Statically compiled. Mostly statically linked. Though I often wish there was an additional interpreter/JIT with a REPL.
* Good performance without much effort.
* Good concurrency/parallelism primitives, especially since async
* Increasingly better IDE support, thanks to the author of this blog post! (rust-analyzer)
So I often accept the downsides of Rust, even for higher level code, because I don't know another language that fits.
My closest alternatives would probably be Go, Haskell or F#. But each don't fit the above list one way or another.
Personally I often use Rust for "non systems-programming" tasks, even though I really wish a more suitable language existed.
Rust has plenty of downsides, but hits a particular sweet spot for me that is hard to find elsewhere:
* Expressive, pretty powerful, ML and Haskell inspired type system
* Memory safe. In higher level code you have almost zero justification for `unsafe`, unless you really need a C library.
* Immutable by default. Can feel almost functional, depending on code style.
* Error handling (it's not perfect by any means, but much better than exceptions in my book)
* Very coherent language design. The language has few warts, in part thanks to the young age.
* Great package manager and build system.
* Good tooling in general (compiler errors, formatter, linter, docs generation, ... )
* Library availability is great for certain domains, decent for many.
* Statically compiled. Mostly statically linked. Though I often wish there was an additional interpreter/JIT with a REPL.
* Good performance without much effort.
* Good concurrency/parallelism primitives, especially since async
* Increasingly better IDE support, thanks to the author of this blog post! (rust-analyzer)
So I often accept the downsides of Rust, even for higher level code, because I don't know another language that fits.
My closest alternatives would probably be Go, Haskell or F#. But each don't fit the above list one way or another.
> Programmer’s time is valuable, and, if you pick Rust, expect to spend some of it on learning the ropes.
Of all the arguments, time-to-productivity may be the most compelling. Rust will keep most new programmers from being productive far longer than any other language. I'd say 3x minimum.
What's a little surprising, though, is how many of the difficulties beginners have stem from just one concept: ownership.
Counterintuitively, ownership is quite simple. But what's mind-bending about it is that it doesn't exist in any other language a beginner is likely to have used. Yet ownership pervades Rust, sometimes in very hard to detect ways. And perversely, it's possible to write a lot of Rust without ever "seeing" ownership thanks to the complier.
Eventually, though, the beginner comes face-to-face with ownership without recognizing the trap s/he's fallen into. Ownership isn't something you can "discover" by messing around in the same way that most language features can be teased apart. The term "fighting with the borrow checker" is actually a symptom not of a struggle with a feature but a struggle with a basic, non-negotiable concept that hasn't been learned.
I can recommend this video for getting over the hump:
https://www.youtube.com/watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgV...
In my experience, Rust productivity shoots up by a lot given a basic understanding of ownership.
Of all the arguments, time-to-productivity may be the most compelling. Rust will keep most new programmers from being productive far longer than any other language. I'd say 3x minimum.
What's a little surprising, though, is how many of the difficulties beginners have stem from just one concept: ownership.
Counterintuitively, ownership is quite simple. But what's mind-bending about it is that it doesn't exist in any other language a beginner is likely to have used. Yet ownership pervades Rust, sometimes in very hard to detect ways. And perversely, it's possible to write a lot of Rust without ever "seeing" ownership thanks to the complier.
Eventually, though, the beginner comes face-to-face with ownership without recognizing the trap s/he's fallen into. Ownership isn't something you can "discover" by messing around in the same way that most language features can be teased apart. The term "fighting with the borrow checker" is actually a symptom not of a struggle with a feature but a struggle with a basic, non-negotiable concept that hasn't been learned.
I can recommend this video for getting over the hump:
https://www.youtube.com/watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgV...
In my experience, Rust productivity shoots up by a lot given a basic understanding of ownership.
Rust in prod has been bittersweet for us. Our main goal was to 1) do our job and 2) leverage some of the great promises of Rust.
Deterministic memory management and bare metal performance are great and have been realized benefits. The great promises were realized.
On the “do your job” front though, the lack of a good STABLE library ecosystem has been a real issue and big source of frustration. It seems that most library developers in the Rust community are hackers writing Rust for fun, and I do not say that in a negative way. But the consequence is that things are usually not super well maintained, but more critically are targeting Rust Nightly (which makes sense as Nightly has all the new cool compiler stuff).
Add the scarce professional talent pool, the unavoidable steep learning curve, low bus factor risk... It’s just hard to justify pushing (professionally) more Rust beyond its niche.
With Mozilla pulling out (to some extent), the big focus on Web-assembly... it just feels off if all you want to do is build boring backends.
The contrast with Golang’s “boring as a feature” is quite interesting in that regard.
Time will tell if Rust will make it to the major leagues, or will be another Haskell.
Deterministic memory management and bare metal performance are great and have been realized benefits. The great promises were realized.
On the “do your job” front though, the lack of a good STABLE library ecosystem has been a real issue and big source of frustration. It seems that most library developers in the Rust community are hackers writing Rust for fun, and I do not say that in a negative way. But the consequence is that things are usually not super well maintained, but more critically are targeting Rust Nightly (which makes sense as Nightly has all the new cool compiler stuff).
Add the scarce professional talent pool, the unavoidable steep learning curve, low bus factor risk... It’s just hard to justify pushing (professionally) more Rust beyond its niche.
With Mozilla pulling out (to some extent), the big focus on Web-assembly... it just feels off if all you want to do is build boring backends.
The contrast with Golang’s “boring as a feature” is quite interesting in that regard.
Time will tell if Rust will make it to the major leagues, or will be another Haskell.
I (hobby gamedev) moved from Rust to C a few weeks ago, here's something that made me switch:
1. Compilation time (no more words needed)
2. Forced to use Cargo for managing dependencies. The downside of a good dependency toolchain is that people will use it and there will be tons of indirect dependencies. For cross-platform development it's very common to see one of your indirect dependencies doesn't support the platform you wanted, and there's no way around it (even you know how to fix it you'll have to submit a pr and wait till the merge and crates.io release (takes years), or download the whole dependency chain and use everything locally which is a total mess)
3. Too strict. As a hobby gamedev the thing I value the most is the joy of programming, I don't want to spend all my time trying to figure out how to solve a borrow checker issue (you'll always face them no matter how good you're at Rust, and I don't want to use Rc<RefCell<T>> everywhere), and I just want to be able to use global variables without ugly unsafe wrappers in my naive single threaded application.
As a language I love every aspect of Rust, just ergonomically I don't want to deal with it now.
1. Compilation time (no more words needed)
2. Forced to use Cargo for managing dependencies. The downside of a good dependency toolchain is that people will use it and there will be tons of indirect dependencies. For cross-platform development it's very common to see one of your indirect dependencies doesn't support the platform you wanted, and there's no way around it (even you know how to fix it you'll have to submit a pr and wait till the merge and crates.io release (takes years), or download the whole dependency chain and use everything locally which is a total mess)
3. Too strict. As a hobby gamedev the thing I value the most is the joy of programming, I don't want to spend all my time trying to figure out how to solve a borrow checker issue (you'll always face them no matter how good you're at Rust, and I don't want to use Rc<RefCell<T>> everywhere), and I just want to be able to use global variables without ugly unsafe wrappers in my naive single threaded application.
As a language I love every aspect of Rust, just ergonomically I don't want to deal with it now.
I hope this isn't too much of a tangent given the article's subject is details and specifics. I adore Rust for it's unique combination of features:
- Can write fast, and systems-level code; something typically dominated by C/++
- Makes standalone executables
- Modern, high-level language features
- Best-in-class tooling and docs (As the article points out)
I'm not familiar with another language that can do these together. It's easy to pidgeonhole Rust as a "safe" language, but I adore it on a holistic level. I've found Rust's consolidated, official tooling makes the experience approachable for new people.
- Can write fast, and systems-level code; something typically dominated by C/++
- Makes standalone executables
- Modern, high-level language features
- Best-in-class tooling and docs (As the article points out)
I'm not familiar with another language that can do these together. It's easy to pidgeonhole Rust as a "safe" language, but I adore it on a holistic level. I've found Rust's consolidated, official tooling makes the experience approachable for new people.
In the section on "Rust is big and you have to learn it" the author was too nice to people like me: I'm just not smart enough to manage the demands Rust puts on me while also solving my own problem.
I feel like this is a really serious problem for Rust: the number of people capable of making the right choices among the 10 ways to structure a class is too small. This is also why there's too much dangerously bad C and C++ in the world.
I feel like this is a really serious problem for Rust: the number of people capable of making the right choices among the 10 ways to structure a class is too small. This is also why there's too much dangerously bad C and C++ in the world.
Not many people just come out and say it, but I think Rust is an ugly programming language. That's a good enough reason for me.
A big thing missed here is compatibility. The systems programming market is huge but most of it is covered by C/C++ programs, many of which being giant codebases with millions of engineer hours inside them. You can't just rewrite them in Rust. And Rust will always be second in place when it comes to interacting with C/C++ codebases, C++ will always be better at it, and if it's only the explicit safety barrier.
So languages like Rust are relegated to picking up the new greenfield codebases and some few codebases where engineers felt courageous enough to introduce it.
Overall, the signs are good though. I think it's much easier to onboard new engineers to Rust rather than to the company specific dialect of C++.
So languages like Rust are relegated to picking up the new greenfield codebases and some few codebases where engineers felt courageous enough to introduce it.
Overall, the signs are good though. I think it's much easier to onboard new engineers to Rust rather than to the company specific dialect of C++.
> Rust is a systems programming language.
While Rust is a systems programming language, it has a very advanced Traits system. This makes it, in my opinion, more powerful than your average scripting language (Python, JavaScript, etc...) I have recently used Rust for something that I should have, normally, used JavaScript or Python for. Based on my experience, I probably gained in development time because I didn't do much debugging. Rust code just works, it's simply amazing.
> Complexity
One way to approach this, is to actually enjoy this complexity because there is real theoretical computer science behind it. It's not complexity for its own sake.
> Compile Times
This one is really annoying even with a powerful processor.
> Maturity
I'd argue that since many high profile companies like Facebook, Google and Microsoft used Rust to start new projects (like Libra, Fuchsia); Rust is stable enough to be used in a production capacity. You'll probably benefit more if the project is new and thus have less time dealing with C compatibility.
While Rust is a systems programming language, it has a very advanced Traits system. This makes it, in my opinion, more powerful than your average scripting language (Python, JavaScript, etc...) I have recently used Rust for something that I should have, normally, used JavaScript or Python for. Based on my experience, I probably gained in development time because I didn't do much debugging. Rust code just works, it's simply amazing.
> Complexity
One way to approach this, is to actually enjoy this complexity because there is real theoretical computer science behind it. It's not complexity for its own sake.
> Compile Times
This one is really annoying even with a powerful processor.
> Maturity
I'd argue that since many high profile companies like Facebook, Google and Microsoft used Rust to start new projects (like Libra, Fuchsia); Rust is stable enough to be used in a production capacity. You'll probably benefit more if the project is new and thus have less time dealing with C compatibility.
Sure, not everything is system programming, but Rust has some higher level features that are even missing in languages like JavaScript and Python. Pattern matching is very powerful.
I'm not entirely sure, but have the feeling that Rust's "cons" are mostly short term draw backs and the "pros" could be really valuable in the long run.
I'm not entirely sure, but have the feeling that Rust's "cons" are mostly short term draw backs and the "pros" could be really valuable in the long run.
Another thing not mentioned is there's still no mature cross-platform production ready GUI libraries written in Rust yet. None of them come even close to Qt or countering Electron. Just mere unmaintained bindings to them. [0]
I guess it is either Electron (HTML/CSS/JS) + 200MB Chromium engine or Qt5 (C++) for now.
[0] https://www.areweguiyet.com/
I guess it is either Electron (HTML/CSS/JS) + 200MB Chromium engine or Qt5 (C++) for now.
[0] https://www.areweguiyet.com/
> we don’t know how to create a simpler memory safe low-level language.
This may well be true, but using a memory-safe language is never, ever the goal. The goal is creating correct and secure programs -- that have as few bugs and security flaws as possible/required -- as cheaply as possible. While a memory safe language in the style of Rust is one means toward that end, that eliminates an important class of bugs at the cost of language complexity, it is not the best way toward that goal, at least not that we know, and it is certainly not the only one [1]. I.e. the hypothesis that if I want to write a program that's as correct as possible/needed as cheaply as possible then I should necessarily use the language that gives me the most sound guarantees regardless of the cost this entails is just some people's guess. It's hard to say if it's a good guess or a bad one because it's clear that we're talking about specific sweet-spots on a wide spectrum of options that could be very context-dependent, but it's still a guess, with good arguments both in its favour as well as against.
> In Rust, there are choices to be made, some important enough to have dedicated syntax.
Not only that, but those choices are exposed in the type signature and are, therefore, viral. Changing some internal technical implementation detail can require changes in all consumers. This is not a problem with the type system -- on the contrary, Rust's type system ensures that all the changes that need to be made are made -- but it is a fundamental problem with all low level language. They all suffer from low abstraction, i.e. a certain interface can represent a smaller number of implementations than in high-level languages (even if the choice is not explicit in the type, like, say, in C, the usage pattern is part of the interface). But Rust's choice to expose such details in the types has its downsides as well.
> If you use C, you can use formal methods to prove the absence of undefined behaviors
C now also has sound static analysis tools [2] that guarantee no undefined behaviour with a nearly fully automatic proof that scales to virtually any code size and requires relatively little effort, certainly compared to a rewrite.
[1]: Another low-level language with an emphasis on the same goal of correctness, Zig, takes an approach that is radically different from Rust's and is so simple it can be fully learned in a day or two. Which of the two approaches, if any, is better for correctness can only be answered empirically.
[2]: Like https://trust-in-soft.com/, from the makers of Frama-C
This may well be true, but using a memory-safe language is never, ever the goal. The goal is creating correct and secure programs -- that have as few bugs and security flaws as possible/required -- as cheaply as possible. While a memory safe language in the style of Rust is one means toward that end, that eliminates an important class of bugs at the cost of language complexity, it is not the best way toward that goal, at least not that we know, and it is certainly not the only one [1]. I.e. the hypothesis that if I want to write a program that's as correct as possible/needed as cheaply as possible then I should necessarily use the language that gives me the most sound guarantees regardless of the cost this entails is just some people's guess. It's hard to say if it's a good guess or a bad one because it's clear that we're talking about specific sweet-spots on a wide spectrum of options that could be very context-dependent, but it's still a guess, with good arguments both in its favour as well as against.
> In Rust, there are choices to be made, some important enough to have dedicated syntax.
Not only that, but those choices are exposed in the type signature and are, therefore, viral. Changing some internal technical implementation detail can require changes in all consumers. This is not a problem with the type system -- on the contrary, Rust's type system ensures that all the changes that need to be made are made -- but it is a fundamental problem with all low level language. They all suffer from low abstraction, i.e. a certain interface can represent a smaller number of implementations than in high-level languages (even if the choice is not explicit in the type, like, say, in C, the usage pattern is part of the interface). But Rust's choice to expose such details in the types has its downsides as well.
> If you use C, you can use formal methods to prove the absence of undefined behaviors
C now also has sound static analysis tools [2] that guarantee no undefined behaviour with a nearly fully automatic proof that scales to virtually any code size and requires relatively little effort, certainly compared to a rewrite.
[1]: Another low-level language with an emphasis on the same goal of correctness, Zig, takes an approach that is radically different from Rust's and is so simple it can be fully learned in a day or two. Which of the two approaches, if any, is better for correctness can only be answered empirically.
[2]: Like https://trust-in-soft.com/, from the makers of Frama-C
> “Rust should have stable ABI” — I don’t think this is a strong argument. Monomorphization is pretty fundamentally incompatible with dynamic linking and there’s C ABI if you really need to.
This is an interesting topic unto itself, described in one of my favourite pieces of technical writing of all time:
How Swift Achieved Dynamic Linking Where Rust Couldn't - Alexis Beingessner - https://gankra.github.io/blah/swift-abi/
This is an interesting topic unto itself, described in one of my favourite pieces of technical writing of all time:
How Swift Achieved Dynamic Linking Where Rust Couldn't - Alexis Beingessner - https://gankra.github.io/blah/swift-abi/
Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume. Andrei Alexandrescu has this quote about how Rust skipped leg day. You should all look it up. Here's what actually matters, in the real world, for the type of programs I'd choose Rust or a Rust-adjacent language:
- Fast compile times
- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).
- Optimized, fuzzed, highly-tested, standards compliant web stack built-in
- Ability to compile CUDA kernels, built-in
- Automatic memory management with an escape hatch for where manual is necessary
- Rich metaprogramming and compile-time reflection
- Created by or funded by a large U.S. corporation so that PMs are likely to choose it.
- IDE/LSP language server/editor plugins maintained by the language designers
Failing this, you are an academic language, not a real world industry programming language in 2020.
- Fast compile times
- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).
- Optimized, fuzzed, highly-tested, standards compliant web stack built-in
- Ability to compile CUDA kernels, built-in
- Automatic memory management with an escape hatch for where manual is necessary
- Rich metaprogramming and compile-time reflection
- Created by or funded by a large U.S. corporation so that PMs are likely to choose it.
- IDE/LSP language server/editor plugins maintained by the language designers
Failing this, you are an academic language, not a real world industry programming language in 2020.
Yeah, compiling in Rust was the bane of my existence. I tried to stay on old versions for as long as possible to avoid compiling.
At some points, I'd basically have to wait 10-15min.. so I'd go for a walk or grab coffee. Then I'd switch to javascript and it felt like going at the speed of light. To each their own.
At some points, I'd basically have to wait 10-15min.. so I'd go for a walk or grab coffee. Then I'd switch to javascript and it felt like going at the speed of light. To each their own.
This is a pretty good summary.
Not to pile on, because Rust is still in a fragile condition, but the point that Rust cannot, and never will be able to call, typical C++ libraries deserves a boost (no pun intended).
This matters because C++ has more facilities to encapsulate powerful semantics into libraries than any other language. People write libraries in C++ that cannot be written in other languages, routinely.
This makes it usually impractical to integrate Rust code into an existing modern C++ codebase, unless it implements a wholly independent subsystem. That matters because effectively all of the most demanding systems-level work, today, is conducted in C++, not C (old OS kernels and databases excepted).
The longevity problem also deserves attention. The normal, expected fate of any new language is to die. It practically takes a miracle to survive, and we have no way to predict miracles. So, we don't know if there will be anyone to maintain Rust code written today.
What will it take to survive? It comes down to numbers. Rust has an excellent adoption rate for a language at this stage. To survive, it might be enough were the rate to increase by two orders of magnitude.
You don't get that just by more and better publicity. It needs change. But the changes needed are, by experience, very, very unpopular among existing Rust users.
Rust will never displace C++ or C. C++ does things Rust can't. C will dwindle only as its user base retires, because C users actually like it for its failings: it makes them feel tough (or something). Rust is an overwhelmingly better language than Java or Go, and the world would be a better place if Rust were to displace them.
But neither of those has the specific problems that the borrow checker demands be solved. They have other, graver weaknesses. So, for Rust to displace them, its advocates will need to change their approach to appeal to users of those languages.
That will require at least a different build model that admits an order of magnitude faster builds, and a looser use of the borrow checker that generates less frustration. It might need accommodations to integrate in Go and Java projects, maybe including support for a JVM target, virtual call mechanism, and import of foreign Go and Java modules.
To get any of that, the project will need to excite people now in those environments with the prospect of easing their pain. Rust's advantage there is that their pain is great, and Rust could ease it.
Not to pile on, because Rust is still in a fragile condition, but the point that Rust cannot, and never will be able to call, typical C++ libraries deserves a boost (no pun intended).
This matters because C++ has more facilities to encapsulate powerful semantics into libraries than any other language. People write libraries in C++ that cannot be written in other languages, routinely.
This makes it usually impractical to integrate Rust code into an existing modern C++ codebase, unless it implements a wholly independent subsystem. That matters because effectively all of the most demanding systems-level work, today, is conducted in C++, not C (old OS kernels and databases excepted).
The longevity problem also deserves attention. The normal, expected fate of any new language is to die. It practically takes a miracle to survive, and we have no way to predict miracles. So, we don't know if there will be anyone to maintain Rust code written today.
What will it take to survive? It comes down to numbers. Rust has an excellent adoption rate for a language at this stage. To survive, it might be enough were the rate to increase by two orders of magnitude.
You don't get that just by more and better publicity. It needs change. But the changes needed are, by experience, very, very unpopular among existing Rust users.
Rust will never displace C++ or C. C++ does things Rust can't. C will dwindle only as its user base retires, because C users actually like it for its failings: it makes them feel tough (or something). Rust is an overwhelmingly better language than Java or Go, and the world would be a better place if Rust were to displace them.
But neither of those has the specific problems that the borrow checker demands be solved. They have other, graver weaknesses. So, for Rust to displace them, its advocates will need to change their approach to appeal to users of those languages.
That will require at least a different build model that admits an order of magnitude faster builds, and a looser use of the borrow checker that generates less frustration. It might need accommodations to integrate in Go and Java projects, maybe including support for a JVM target, virtual call mechanism, and import of foreign Go and Java modules.
To get any of that, the project will need to excite people now in those environments with the prospect of easing their pain. Rust's advantage there is that their pain is great, and Rust could ease it.
> Complexity - Programmer’s time is valuable, and, if you pick Rust, expect to spend some of it on learning the ropes
This has been my experience as well. I've been trying out Rust for a week now and as an experienced programmer, the complexity of the language is overwhelming. That said, you don't need to know all language constructs to get started. In the last week, I've been able to build a simple but useful cross-platform GUI app after reading only the ownership/lifetime section of the Rust book.
But yes, it is not for everyone and it certainly isn't a simple language to pick up.
This has been my experience as well. I've been trying out Rust for a week now and as an experienced programmer, the complexity of the language is overwhelming. That said, you don't need to know all language constructs to get started. In the last week, I've been able to build a simple but useful cross-platform GUI app after reading only the ownership/lifetime section of the Rust book.
But yes, it is not for everyone and it certainly isn't a simple language to pick up.
From a security point of view, the major issue with Rust is still the shallow standard library, a shame the article doesn't emphasizes this and instead lists this as a negligible point. How many will end up using rust wrongly due to the lack of a rand library, or anything cryptography, etc. And that's nothing compared to the lack of a hex encoder/decoder, of a tcp library, of a json library, etc. Compare that to Golang and Rust has a lot to improve on.
I think Andrei Alexandrescu's comment that Rust "skipped leg day" is still mostly true (Rust does what it set out to do better than anyone else but the metaprogramming in particular isn't very attractive)
TIL Rust is working on its own version of ASAN and UBSAN: https://github.com/rust-lang/miri How shocking.
Will the compiler performance eventually match C++, or are there fundamental limits to it?
Too complicated which means when your lead rust dev leaves good luck finding another one.
The article fails to mention Ada's capabilities in the area of formal verification. The 'SPARK' subset of the language is designed explicitly for this purpose.
Modern Ada/SPARK also support Rust style 'safe-pointers': https://blog.adacore.com/using-pointers-in-spark
Modern Ada/SPARK also support Rust style 'safe-pointers': https://blog.adacore.com/using-pointers-in-spark
Thanks! This convinced me. I'll stick to C for low-level, C++ for CUDA stuff, and C# for everything else.
I've been pondering similar issues re Rust a lot lately too. Mainly that it's very safe and fast, but that is offset by how difficult it is to use.
I recently had an idea: What if i made a subset of Swift and a transpiler that outputs simple C? The C output would make it a great contender for integrations with existing code in the 'systems programming' genre.
Swift is such a lovely language, far simpler than Rust, but being tied to apple's ecosystem and LLVM makes it difficult to use for many of these areas.
This would also be great for embedded, which is something i'm also passionate about.
End result would be: productive + simple + safe language, great for systems/embedded IoT stuff.
Anyway i've submitted the idea for an R&D grant, we'll see if it goes anywhere. Would love to hear people's thoughts.
I recently had an idea: What if i made a subset of Swift and a transpiler that outputs simple C? The C output would make it a great contender for integrations with existing code in the 'systems programming' genre.
Swift is such a lovely language, far simpler than Rust, but being tied to apple's ecosystem and LLVM makes it difficult to use for many of these areas.
This would also be great for embedded, which is something i'm also passionate about.
End result would be: productive + simple + safe language, great for systems/embedded IoT stuff.
Anyway i've submitted the idea for an R&D grant, we'll see if it goes anywhere. Would love to hear people's thoughts.
> Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies.
Interesting. I did not know this. I would have thought Box<dyn Foo> would have achieved PIMPL. Is that not the case?
Interesting. I did not know this. I would have thought Box<dyn Foo> would have achieved PIMPL. Is that not the case?
Great blog post
> Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies.
I really hope `extern type` could help with this. edit wrote https://github.com/rust-lang/rfcs/pull/2984#issuecomment-695... on how I think it could.
> Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies.
I really hope `extern type` could help with this. edit wrote https://github.com/rust-lang/rfcs/pull/2984#issuecomment-695... on how I think it could.
In the videogames world we
- need very good performance
- don't care about memory safety (not an issue)
- also need fast compile time
This is one of better critiques I've read. I still think as a matter of market and solutions for same rust will continue to be a player. But I'm not game for rust to learn at the same time while I make, say, a distributed system. Frama-C with c++ I still think is the better combo
There's a lot to be said for that. You can put junior programmers on something and they'll probably get it more or less right.
Rust is very clever. The borrow checker was a huge step forward. It changed programming. Now, everybody gets ownership semantics. Any new language that isn't garbage collected will probably have ownership semantics. Before Rust, only theorists discussed ownership semantics much. Ownership was implicit in programs, and not talked about much.
Tying locking to ownership seems to have worked in Rust. A big problem with locking has been that languages didn't address which lock covers what data. Java approached that with "synchronized", but that seems to have been a flop. (Why?) Ada had the "rendezvous", a similar idea. Rust seems to have made forward progress in that area.
I used to say that the big problems in C are "How big is it?", "Who owns it for deletion purposes?", and "Who locks it?" At last, with Rust we see strong solutions to those problems in wide use.
Much work has gone into Rust, and it will have much influence on the design of later languages. We're finding out what happens with that model, what's useful, what's missing, and what's cruft.
In the next round of languages, we'll probably have to deal directly with non-shared memory. Totally shared memory in multiprocessors is an illusion maintained by elaborate cache interlocking and huge inter-cache bandwidth. That has scaling limits. Future languages will probably have to track which CPUs can access which data. "Thread local" and "immutable" are a start.