4 ms·

I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an e

by Yoric 4y ago

I agree that safety should affect API design, which means that there is at least one major piece missing after the rewrite. Either the ability to switch to an even stricter type system (e.g. Rust) or a ~zero cost binding generator to a stricter language (again, e.g. Rust). However, before reaching that point, piecewise refactoring is something of considerable value. There are huge C++ codebases lying around that I believe would benefit immensely from a rewrite in a safer language, even if it's not as safe as Rust (or Scala, or F#, etc.) Firefox and Chromium have already paid the entry price for piecewise refactoring into Rust, so they're probably not the best candidates. But there are many other examples that undoubtedly are, e.g. LLVM.

mjburgess 4y ago
Scala and F# are safer than Rust since they're on a VM.
- Yoric 4y ago
  Well, you can compile Rust to WASM. But yes, point taken, out of the box, Scala and F# have a safer execution mode.
- tialaramex 4y ago
  As far as I understand, both these languages are subject to data races whereas (safe) Rust is not. Now, Scala is a JVM language and so presumably you get Java's rules, you aren't Sequentially Consistent but the damage is constrained - however human programmers still can't successfully reason about this state in non-trivial programs.
  - pjmlp 4y ago
    There are plenty of other races that Rust doesn't provide any help, and those are much more relevant in distributed computing workloads.
- thesuperbigfrog 4y ago
  >> Scala and F# are safer than Rust since they're on a VM. Do you have any evidence to back up your claim? Both the JVM (Scala's VM) and the CLR (F#'s VM) have a history of vulnerabilities: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspot https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspo... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr Programming languages running on VM is not a safety guarantee.
  - pjmlp 4y ago
    Well, it is the same 30% that Rust also cannot help much.
  - mjburgess 4y ago
    In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages. The semantics of F#/Scala are memory safe because they're defined to be dynamic. The semantics of Rust are not memory safe. A subset of Rust is provably memory safe, but none that uses eg. much of the standard library which is unprovably memory safe against the lang's own semantics.
    - tialaramex 4y ago
      It seems weird to treat stuff that Scala must rely on but you can't write in Scala as part of the implementation, and yet not do the same for stuff Safe Rust has to rely on from Unsafe Rust.
      - mjburgess 4y ago
        Breaking down the full argument is very subtle, sure. But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language. To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer. The whole argument about "saftey" in the sense Rust addresses is between languages of "manual allocation". To imagine that any of these language is "safer", is to have misunderstood a great deal. Rust is about enabling an otherwise C-programmer to limit the impact of manual memory handling, it is *not* to prevent eg,. use-after-free errors in javascript. Since there are no such errors by construction.
zozbot234 4y ago
C++ templates cannot be reused or rewritten piecemeal in a new language, it's practically impossible. There's a reason why the Rust folks were very careful to separate out generics from the more flexible case of macros (that come in both rewrite-based and procedural varieties).
- Yoric 4y ago
  Out of the box, they can't, but I can imagine mitigations for that, if you have robust enough static analysis on your new language. For many cases, it's fairly trivial to generate a piece of .cpp that simply instantiates a template for a specific type and can be linked against. Of course: - this doesn't cross library boundaries; - this assumes robust enough static analysis, which is not possible in the general case, since templates are non-decidable in the general case – so you need to restrict your new language to more reasonable semantics; - let's not even get started on the interaction between templates and C-style macros – at some point, you need to throw the towel.

by Yoric 4y ago

mjburgess 4y ago

Scala and F# are safer than Rust since they're on a VM.

Yoric 4y ago
Well, you can compile Rust to WASM. But yes, point taken, out of the box, Scala and F# have a safer execution mode.
tialaramex 4y ago
As far as I understand, both these languages are subject to data races whereas (safe) Rust is not. Now, Scala is a JVM language and so presumably you get Java's rules, you aren't Sequentially Consistent but the damage is constrained - however human programmers still can't successfully reason about this state in non-trivial programs.
- pjmlp 4y ago
  There are plenty of other races that Rust doesn't provide any help, and those are much more relevant in distributed computing workloads.
thesuperbigfrog 4y ago
>> Scala and F# are safer than Rust since they're on a VM. Do you have any evidence to back up your claim? Both the JVM (Scala's VM) and the CLR (F#'s VM) have a history of vulnerabilities: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspot https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+hotspo... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dotnet+clr Programming languages running on VM is not a safety guarantee.
- pjmlp 4y ago
  Well, it is the same 30% that Rust also cannot help much.
- mjburgess 4y ago
  In the relevant sense of safety, they are safer. The commenter's claim was not about vulnerabilities, since those apply to implementations, not to languages. The semantics of F#/Scala are memory safe because they're defined to be dynamic. The semantics of Rust are not memory safe. A subset of Rust is provably memory safe, but none that uses eg. much of the standard library which is unprovably memory safe against the lang's own semantics.
  - tialaramex 4y ago
    It seems weird to treat stuff that Scala must rely on but you can't write in Scala as part of the implementation, and yet not do the same for stuff Safe Rust has to rely on from Unsafe Rust.
    - mjburgess 4y ago
      Breaking down the full argument is very subtle, sure. But, at the outset, we can simply observe that the "safety" Rust provides is memory safety, which is a non-issue in a dynamic language. To say that Rust is as safe, or more safe, than a dynamic lang is false. It's strictly less safe, since by construction, it is a language where allocation is managed by the programmer. The whole argument about "saftey" in the sense Rust addresses is between languages of "manual allocation". To imagine that any of these language is "safer", is to have misunderstood a great deal. Rust is about enabling an otherwise C-programmer to limit the impact of manual memory handling, it is *not* to prevent eg,. use-after-free errors in javascript. Since there are no such errors by construction.

zozbot234 4y ago

C++ templates cannot be reused or rewritten piecemeal in a new language, it's practically impossible. There's a reason why the Rust folks were very careful to separate out generics from the more flexible case of macros (that come in both rewrite-based and procedural varieties).

Yoric 4y ago
Out of the box, they can't, but I can imagine mitigations for that, if you have robust enough static analysis on your new language. For many cases, it's fairly trivial to generate a piece of .cpp that simply instantiates a template for a specific type and can be linked against. Of course: - this doesn't cross library boundaries; - this assumes robust enough static analysis, which is not possible in the general case, since templates are non-decidable in the general case – so you need to restrict your new language to more reasonable semantics; - let's not even get started on the interaction between templates and C-style macros – at some point, you need to throw the towel.