6 ms·

Unlikely to happen, except couple of small niches. Rust is too hard to learn, compiles too slow, hard to interop with C, and less safe than VM-based languages.

Unlikely to happen, except couple of small niches. Rust is too hard to learn, compiles too slow, hard to interop with C, and less safe than VM-based languages. P.S. According to hackernews filter bubble, Lisp should have killed Java decades ago.

StavrosK 6y ago
C is only easy to learn if by "learn" you mean "getting something to compile". Learning it enough to write programs without malloc vulnerabilities is basically impossible.
- Const-me 6y ago
  That's not a huge deal for 2 reasons. 1. Not all software is exposed to internets, or requires many 9-s in reliability like avionics. A videogame that crashes their hardware-virtualized compartment on 1 out of 100k consoles is not OK, but might be good enough in practice if the unlucky users are refunded. 2. We have higher-level languages which solve these vulnerabilities for acceptable performance cost, and even easier to learn than C.
  - Nullabillity 6y ago
    Most video games do connect to the internet these days.
    - pjmlp 6y ago
      You are speaking of an industry whose game engines would be a giant unsafe block, given some of the current practices.
    - Const-me 6y ago
      They run supervised (if you exploited a game, can't infect the OS), and they don't quite need the reliability.
- pjmlp 6y ago
  True, yet Frama-C and MISRA-C do exist, and certified compilers, which Rust is yet to have. To prove how hard it is to replace C, even Microsoft with its security speech and "we don't need C on Windows" has given up to market pressure. The Azure Sphere device whose marketing message is all about secure IoT, uses C as its only language, despite endless requests for C++, Rust, C# support. The new MSVC version will support C11 and C17, minus the C99 features that became optional in C11. Language evangelism without market understanding doesn't go far.
- WJW 6y ago
  The C based programs I use most are probably various databases (mysql, postgres, redis, sqlite etc) and the linux kernel. Certainly for the databases they have been rock solid. It's possible to crash them by running the server out of resources of course, but I have never had them outright crash with a malloc problem. The kernel has more bugs perhaps, but that too has been rather stable for me. C might not be perfect but it's clearly perfectly possible to write stable and secure programs in them.
creata 6y ago
I agree that it's unlikely to happen, but not for any of those reasons. * Rust is no harder to learn well than C, as someone else has already commented. * Rust compiling too slowly is just an attribute of its current implementation — there's nothing about the language itself that makes it any slower at compilation than, say, C++. * C interop isn't hard at all in my experience. Do you have any particular complaints? * it's no less safe than VM-based languages. In fact, given the guarantees it gives you wrt parallelism, I'd say it's more safe than most VM-based languages.
- Const-me 6y ago
  > there's nothing about the language itself that makes it slow to compile https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/generics-and-compile-time-in-rust https://pingcap.com/blog/generics-and-compile-time-in-rust > Do you have any particular complaints? It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost. > it's no less safe than VM-based languages In VM-based languages which don't use unsafe code, vulnerabilities like this are impossible by design: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-...
  - Nullabillity 6y ago
    > It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost. If C was on the table anyway then you can use bindgen to generate the bindings. But yeah, safe/native-feeling bindings require someone to go through and annotate everything. > In VM-based languages which don't use unsafe code, vulnerabilities like this are impossible by design: The VM itself is still going to have unsafe code at some point.
    - Const-me 6y ago
      > The VM itself is still going to have unsafe code at some point. Smaller amount of the unsafe code which is audited, battle-tested, and not extensible by either user nor third-party library developers.
tlamponi 6y ago
> Rust is too hard to learn Complaints about Rust's learning curve is something I really do not get. Yes, it forces you do actually think of what you're doing, which most devs seem to consider a Bad Thing™, but in the mid to long run it helps one enormously and it's one of the first languages of the last 30 years which actually makes lots of things better as a whole, while not being in a walled closed ecosystem. > compiles too slow There's definitively room for improvement here, but honestly, it's way faster than most C++ projects, and the fact that I have native support for nicely separating stuff in sub crates or workspaces, which dramatically improve iterative compiling, makes this a non-issue as long as one does not dump everything together as a pig pile. > hard to interop with C This is just plain wrong, it's very easy to interop with C - we're doing so with some projects, among other a library interoperating with QEMU, where the rust stuff is async (using tokio) and we can nicely integrate this into the C code of QEMU. Automatic binding generation allows you to do this quickly, albeit not very idiomatic most of the time. But manual binding generation is seldom hard, either already done on more popular stuff or one time cost, which, if one knows the code they want to bind too (they should) is rather small. > less safe than VM-based languages Hardly so. One is much more exposed to dynamic runtime errors in those, GC is a PITA and the VM is normally not safer than the rust std lib, as most of it is written in safe rust already and is around, battle tested for up to 5 or even 10 years.
- Const-me 6y ago
  > Complaints about Rust's learning curve is something I really do not get. I've been programming C++ for living since 2000, recently it's C++/17. I think I have good understanding how software works in general, including heap and ownership. Tried to use Rust a couple times for hobby project, failed for various reasons. I don't have issues picking other languages: VBScript, C#, Objective C, Python, Go had little to no learning curve. Another evidence in this thread: https://news.ycombinator.com/item?id=24878434 https://news.ycombinator.com/item?id=24878434 > while not being in a walled closed ecosystem. Wasn't always the case, but .NET is open, thanks to competition. Python always was. > it's very easy to interop with C It's equally easy and almost as efficient in C#. The issue with both, someone has to write and then support the bindings. This ain't hard but has costs, while languages like C++ or Objective-C can directly consume C libraries.
mlindner 6y ago
AFAIK Rust interops with C better than basically other other language other than C++.

StavrosK 6y ago

C is only easy to learn if by "learn" you mean "getting something to compile". Learning it enough to write programs without malloc vulnerabilities is basically impossible.

Const-me 6y ago
That's not a huge deal for 2 reasons. 1. Not all software is exposed to internets, or requires many 9-s in reliability like avionics. A videogame that crashes their hardware-virtualized compartment on 1 out of 100k consoles is not OK, but might be good enough in practice if the unlucky users are refunded. 2. We have higher-level languages which solve these vulnerabilities for acceptable performance cost, and even easier to learn than C.
- Nullabillity 6y ago
  Most video games do connect to the internet these days.
  - pjmlp 6y ago
    You are speaking of an industry whose game engines would be a giant unsafe block, given some of the current practices.
  - Const-me 6y ago
    They run supervised (if you exploited a game, can't infect the OS), and they don't quite need the reliability.
pjmlp 6y ago
True, yet Frama-C and MISRA-C do exist, and certified compilers, which Rust is yet to have. To prove how hard it is to replace C, even Microsoft with its security speech and "we don't need C on Windows" has given up to market pressure. The Azure Sphere device whose marketing message is all about secure IoT, uses C as its only language, despite endless requests for C++, Rust, C# support. The new MSVC version will support C11 and C17, minus the C99 features that became optional in C11. Language evangelism without market understanding doesn't go far.
WJW 6y ago
The C based programs I use most are probably various databases (mysql, postgres, redis, sqlite etc) and the linux kernel. Certainly for the databases they have been rock solid. It's possible to crash them by running the server out of resources of course, but I have never had them outright crash with a malloc problem. The kernel has more bugs perhaps, but that too has been rather stable for me. C might not be perfect but it's clearly perfectly possible to write stable and secure programs in them.

creata 6y ago

I agree that it's unlikely to happen, but not for any of those reasons. * Rust is no harder to learn well than C, as someone else has already commented. * Rust compiling too slowly is just an attribute of its current implementation — there's nothing about the language itself that makes it any slower at compilation than, say, C++. * C interop isn't hard at all in my experience. Do you have any particular complaints? * it's no less safe than VM-based languages. In fact, given the guarantees it gives you wrt parallelism, I'd say it's more safe than most VM-based languages.

Const-me 6y ago
> there's nothing about the language itself that makes it slow to compile https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/generics-and-compile-time-in-rust https://pingcap.com/blog/generics-and-compile-time-in-rust > Do you have any particular complaints? It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost. > it's no less safe than VM-based languages In VM-based languages which don't use unsafe code, vulnerabilities like this are impossible by design: https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://medium.com/@shnatsel/how-rusts-standard-library-was-...
- Nullabillity 6y ago
  > It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost. If C was on the table anyway then you can use bindgen to generate the bindings. But yeah, safe/native-feeling bindings require someone to go through and annotate everything. > In VM-based languages which don't use unsafe code, vulnerabilities like this are impossible by design: The VM itself is still going to have unsafe code at some point.
  - Const-me 6y ago
    > The VM itself is still going to have unsafe code at some point. Smaller amount of the unsafe code which is audited, battle-tested, and not extensible by either user nor third-party library developers.

tlamponi 6y ago

> Rust is too hard to learn Complaints about Rust's learning curve is something I really do not get. Yes, it forces you do actually think of what you're doing, which most devs seem to consider a Bad Thing™, but in the mid to long run it helps one enormously and it's one of the first languages of the last 30 years which actually makes lots of things better as a whole, while not being in a walled closed ecosystem. > compiles too slow There's definitively room for improvement here, but honestly, it's way faster than most C++ projects, and the fact that I have native support for nicely separating stuff in sub crates or workspaces, which dramatically improve iterative compiling, makes this a non-issue as long as one does not dump everything together as a pig pile. > hard to interop with C This is just plain wrong, it's very easy to interop with C - we're doing so with some projects, among other a library interoperating with QEMU, where the rust stuff is async (using tokio) and we can nicely integrate this into the C code of QEMU. Automatic binding generation allows you to do this quickly, albeit not very idiomatic most of the time. But manual binding generation is seldom hard, either already done on more popular stuff or one time cost, which, if one knows the code they want to bind too (they should) is rather small. > less safe than VM-based languages Hardly so. One is much more exposed to dynamic runtime errors in those, GC is a PITA and the VM is normally not safer than the rust std lib, as most of it is written in safe rust already and is around, battle tested for up to 5 or even 10 years.

Const-me 6y ago
> Complaints about Rust's learning curve is something I really do not get. I've been programming C++ for living since 2000, recently it's C++/17. I think I have good understanding how software works in general, including heap and ownership. Tried to use Rust a couple times for hobby project, failed for various reasons. I don't have issues picking other languages: VBScript, C#, Objective C, Python, Go had little to no learning curve. Another evidence in this thread: https://news.ycombinator.com/item?id=24878434 https://news.ycombinator.com/item?id=24878434 > while not being in a walled closed ecosystem. Wasn't always the case, but .NET is open, thanks to competition. Python always was. > it's very easy to interop with C It's equally easy and almost as efficient in C#. The issue with both, someone has to write and then support the bindings. This ain't hard but has costs, while languages like C++ or Objective-C can directly consume C libraries.

mlindner 6y ago

AFAIK Rust interops with C better than basically other other language other than C++.