5 ms·

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. * Rus

by 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.
    - creata 6y ago
      The same could be said of the standard libary vulnerability you linked. But for other code, (a) that's why people use cargo-geiger. (b) you're arguing about the very small number of virtual machines that don't give their users such escape hatches.
- deleted 6y ago
  [deleted]
- creata 6y ago
  > https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity Most of those issues are either about the compiler (it generates a lot of LLVM IR, it's single-threaded), or apply equally well to C++ (monomorphization, macros, build scripts). Nothing significantly impacting compilation times is fundamental to the language afaict. > It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost. True. > In VM-based languages which don't use unsafe code Since you've added that qualifier, sure, Rust would be less safe. But how many VMs don't have such escape hatches? JavaScript in the browser is the only one that comes to mind. > vulnerabilities like this are impossible by design I find this very hard to believe. Even if your VM has no unsafe code, its standard library is probably implemented in unsafe code, where vulnerabilities like this can definitely happen.
  - Const-me 6y ago
    > Most of those issues Some of these issues > monomorphization C++ language is equally bad, but there're well-known workarounds. If you don't abuse Alexandrescu-style, using compilation units, have sane architecture without God objects, it's often not too bad. > macros Not just any macros, macros who require multiple passes. C macros are single-pass and pretty efficient. > build scripts How that applies to C++? > how many VMs don't have such escape hatches? Java doesn't. In C# the hatch exists but can be reliably shut. > its standard library is probably implemented in unsafe code No, they don't. http://www.docjar.com/html/api/java/util/ArrayList.java.html http://www.docjar.com/html/api/java/util/ArrayList.java.html https://source.dot.net/#System.Private.CoreLib/List.cs https://source.dot.net/#System.Private.CoreLib/List.cs
    - Nullabillity 6y ago
      > Java doesn't. JNI, com.sun.misc.Unsafe, etc > In C# the hatch exists but can be reliably shut. P/Invoke?
      - azakai 6y ago
        Technically the unsafe escape hatches exist in those languages, but I think the point is that they are needed less. In Rust you need unsafe to implement some types of graphs, for example, which in GC languages are easy to do without any unsafety. It's a tradeoff, of course: GC languages let you avoid unsafe code at the cost of doing GCs, which in some applications is an issue. Rust's stroke of genius is that it can avoid GCs while giving you almost all the safety of a GC language. Overall I think it's safe (no pun intended) to say that Rust is significantly safer than C or C++, but slightly less safe than Java or C#. But of course both of those comparisons have lots of caveats and exceptions. And there are other factors than safety as well.
pjmlp 6y ago
Rust parallism guarantees are only applicable to threaded code and internal resources. We have already learned to scale down from threads and go back to processes for security and stability reasons. Here Rust doesn't help across IPC and data races of external resources. One way that Rust compiles way slower than C++ is its Gentoo approach to libraries. With C++ I only compile my own code.
- creata 6y ago
  > One way that Rust compiles way slower than C++ is its Gentoo approach to libraries. With C++ I only compile my own code. That's a very good point, and maybe I'm being needlessly pedantic by considering it a part of the current (and only) implementation rather than a fundamental part of the language. > We have already learned to scale down from threads and go back to processes for security and stability reasons. Who is "we"? I still see a lot of parallel code being written with threads or async/await, and Rust's ownership system gives additional safety in both cases.
  - pjmlp 6y ago
    The browser vendors for example.
    - creata 6y ago
      Is it really the case they "have already learned to scale down from threads"? I'm obviously not well-versed in browser internals, but here's the very first sentence of "Threading and Tasks in Chrome": > Chrome has a multi-process architecture and each process is heavily multi-threaded. https://chromium.googlesource.com/chromium/src/+/master/docs/threading_and_tasks.md https://chromium.googlesource.com/chromium/src/+/master/docs... Either way, I think browsers have a very specific scenario, where there isn't much interaction between the tabs, and they need to be well-isolated from each other. I don't think that's a good reason for everyone else to move away from threads.
      - pjmlp 6y ago
papaf 6y ago
Rust is no harder to learn well than C, as someone else has already commented. My experience is the opposite of this. Back when dinosaurs walked the earth, I moved from one system language (Ada) to C and, in a couple of months, I was writing device drivers. I have struggled with Rust on hobby projects for a few years and have given it up 3 times -- this is despite having 18 years of C++ experience. I would not say that you are wrong, just that this statement about the learning curve is not true for everyone.
- faceplanted 6y ago
  Would you mind going into more detail about what you found hard about learning Rust? I'm interested in a counter perspective as someone who hasn't learned it yet and has mostly only seen positive media about it.
  - papaf 6y ago
    Please don't let my negative experience put you off learning Rust -- its an important language and worth putting the effort in. I would recommend diving in and seeing if it works for you. For informational purposes, this is what I still find difficult: - The module system. It constantly catches me out. - I think that I understand traits but struggle using libraries that have a lot of traits in the public interface. - Error handling is nice but there are error handling libraries going in and out of fashion every few months. Which one do I use? - Callbacks combined with the borrow checker. - Complexity of idiomatic code such as state machines [1]. - The strict string handling. What about strings that should be UTF-8 but come over a network protocol? - Combining async code with non-async code. Also, how do you write a library that does I/O and supports both sync and async? - Iterators. I have some functional programming experience but I hit problems with iterators combined with the borrow checker. [1] This example has just 3 states and is much simpler than most real world examples: https://hoverbear.org/blog/rust-state-machine-pattern/ https://hoverbear.org/blog/rust-state-machine-pattern/
    - creata 6y ago
      Thanks, there are some good pain points there. > - The strict string handling. What about strings that should be UTF-8 but come over a network protocol? From your description, it looks like you're looking for String::{from_utf8,from_utf8_lossy,from_utf8_unchecked}[0], but I'm guessing you've seen those already, so I'm confused. > - Combining async code with non-async code. Also, how do you write a library that does I/O and supports both sync and async? I think you'll have to just duplicate the code, but I'd be happy to be proven wrong. [0]: https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8 https://doc.rust-lang.org/std/string/struct.String.html#meth...
johnfn 6y ago
> * 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++. Two points here. One, a comparison to C++ is a little disingenuous because C++ is notorious for slow compile times already. Two, it’s not really accurate to say that Rusts compile time is an implementation detail. In fact, many times over the lifetime of Rust the Rust developers have traded off compile time for particular features that they wanted to add. Compare this to, say, Go, which refuses to add any feature without a serious consideration of compile time impact. Sure, the current implementation could be sped up - but it certainly wasn’t designed to be.
- creata 6y ago
  "Disingenuous" is a little mean. Maybe we just have different standards of compilation speed? You're right — Rust could be a totally different language and get compile time speeds like Go. But that doesn't change the fact that much of the problems with Rust's compile times are a result of its packaging system and compiler, rather than intrinsic to the language.
  - johnfn 6y ago
    Yeah my mistake. Disingenuous meant something different than I thought. “Unfair” perhaps, but I don’t think you have any hidden motives here ;-)

by creata 6y ago

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.
  - creata 6y ago
    The same could be said of the standard libary vulnerability you linked. But for other code, (a) that's why people use cargo-geiger. (b) you're arguing about the very small number of virtual machines that don't give their users such escape hatches.
deleted 6y ago
[deleted]
creata 6y ago
> https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity Most of those issues are either about the compiler (it generates a lot of LLVM IR, it's single-threaded), or apply equally well to C++ (monomorphization, macros, build scripts). Nothing significantly impacting compilation times is fundamental to the language afaict. > It's same issue as in C# and many others: someone has to write and support the bindings, which adds cost. True. > In VM-based languages which don't use unsafe code Since you've added that qualifier, sure, Rust would be less safe. But how many VMs don't have such escape hatches? JavaScript in the browser is the only one that comes to mind. > vulnerabilities like this are impossible by design I find this very hard to believe. Even if your VM has no unsafe code, its standard library is probably implemented in unsafe code, where vulnerabilities like this can definitely happen.
- Const-me 6y ago
  > Most of those issues Some of these issues > monomorphization C++ language is equally bad, but there're well-known workarounds. If you don't abuse Alexandrescu-style, using compilation units, have sane architecture without God objects, it's often not too bad. > macros Not just any macros, macros who require multiple passes. C macros are single-pass and pretty efficient. > build scripts How that applies to C++? > how many VMs don't have such escape hatches? Java doesn't. In C# the hatch exists but can be reliably shut. > its standard library is probably implemented in unsafe code No, they don't. http://www.docjar.com/html/api/java/util/ArrayList.java.html http://www.docjar.com/html/api/java/util/ArrayList.java.html https://source.dot.net/#System.Private.CoreLib/List.cs https://source.dot.net/#System.Private.CoreLib/List.cs
  - Nullabillity 6y ago
    > Java doesn't. JNI, com.sun.misc.Unsafe, etc > In C# the hatch exists but can be reliably shut. P/Invoke?
    - azakai 6y ago
      Technically the unsafe escape hatches exist in those languages, but I think the point is that they are needed less. In Rust you need unsafe to implement some types of graphs, for example, which in GC languages are easy to do without any unsafety. It's a tradeoff, of course: GC languages let you avoid unsafe code at the cost of doing GCs, which in some applications is an issue. Rust's stroke of genius is that it can avoid GCs while giving you almost all the safety of a GC language. Overall I think it's safe (no pun intended) to say that Rust is significantly safer than C or C++, but slightly less safe than Java or C#. But of course both of those comparisons have lots of caveats and exceptions. And there are other factors than safety as well.

pjmlp 6y ago

Rust parallism guarantees are only applicable to threaded code and internal resources. We have already learned to scale down from threads and go back to processes for security and stability reasons. Here Rust doesn't help across IPC and data races of external resources. One way that Rust compiles way slower than C++ is its Gentoo approach to libraries. With C++ I only compile my own code.

creata 6y ago
> One way that Rust compiles way slower than C++ is its Gentoo approach to libraries. With C++ I only compile my own code. That's a very good point, and maybe I'm being needlessly pedantic by considering it a part of the current (and only) implementation rather than a fundamental part of the language. > We have already learned to scale down from threads and go back to processes for security and stability reasons. Who is "we"? I still see a lot of parallel code being written with threads or async/await, and Rust's ownership system gives additional safety in both cases.
- pjmlp 6y ago
  The browser vendors for example.
  - creata 6y ago
    Is it really the case they "have already learned to scale down from threads"? I'm obviously not well-versed in browser internals, but here's the very first sentence of "Threading and Tasks in Chrome": > Chrome has a multi-process architecture and each process is heavily multi-threaded. https://chromium.googlesource.com/chromium/src/+/master/docs/threading_and_tasks.md https://chromium.googlesource.com/chromium/src/+/master/docs... Either way, I think browsers have a very specific scenario, where there isn't much interaction between the tabs, and they need to be well-isolated from each other. I don't think that's a good reason for everyone else to move away from threads.
    - pjmlp 6y ago

papaf 6y ago

Rust is no harder to learn well than C, as someone else has already commented. My experience is the opposite of this. Back when dinosaurs walked the earth, I moved from one system language (Ada) to C and, in a couple of months, I was writing device drivers. I have struggled with Rust on hobby projects for a few years and have given it up 3 times -- this is despite having 18 years of C++ experience. I would not say that you are wrong, just that this statement about the learning curve is not true for everyone.

faceplanted 6y ago
Would you mind going into more detail about what you found hard about learning Rust? I'm interested in a counter perspective as someone who hasn't learned it yet and has mostly only seen positive media about it.
- papaf 6y ago
  Please don't let my negative experience put you off learning Rust -- its an important language and worth putting the effort in. I would recommend diving in and seeing if it works for you. For informational purposes, this is what I still find difficult: - The module system. It constantly catches me out. - I think that I understand traits but struggle using libraries that have a lot of traits in the public interface. - Error handling is nice but there are error handling libraries going in and out of fashion every few months. Which one do I use? - Callbacks combined with the borrow checker. - Complexity of idiomatic code such as state machines [1]. - The strict string handling. What about strings that should be UTF-8 but come over a network protocol? - Combining async code with non-async code. Also, how do you write a library that does I/O and supports both sync and async? - Iterators. I have some functional programming experience but I hit problems with iterators combined with the borrow checker. [1] This example has just 3 states and is much simpler than most real world examples: https://hoverbear.org/blog/rust-state-machine-pattern/ https://hoverbear.org/blog/rust-state-machine-pattern/
  - creata 6y ago
    Thanks, there are some good pain points there. > - The strict string handling. What about strings that should be UTF-8 but come over a network protocol? From your description, it looks like you're looking for String::{from_utf8,from_utf8_lossy,from_utf8_unchecked}[0], but I'm guessing you've seen those already, so I'm confused. > - Combining async code with non-async code. Also, how do you write a library that does I/O and supports both sync and async? I think you'll have to just duplicate the code, but I'd be happy to be proven wrong. [0]: https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8 https://doc.rust-lang.org/std/string/struct.String.html#meth...

johnfn 6y ago

> * 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++. Two points here. One, a comparison to C++ is a little disingenuous because C++ is notorious for slow compile times already. Two, it’s not really accurate to say that Rusts compile time is an implementation detail. In fact, many times over the lifetime of Rust the Rust developers have traded off compile time for particular features that they wanted to add. Compare this to, say, Go, which refuses to add any feature without a serious consideration of compile time impact. Sure, the current implementation could be sped up - but it certainly wasn’t designed to be.

creata 6y ago
"Disingenuous" is a little mean. Maybe we just have different standards of compilation speed? You're right — Rust could be a totally different language and get compile time speeds like Go. But that doesn't change the fact that much of the problems with Rust's compile times are a result of its packaging system and compiler, rather than intrinsic to the language.
- johnfn 6y ago
  Yeah my mistake. Disingenuous meant something different than I thought. “Unfair” perhaps, but I don’t think you have any hidden motives here ;-)