4 ms·

> 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/rus

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

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.