8 ms·

This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability o

This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.

steveklabnik 2y ago
> like Microsoft with its TypeScript rewrite in Go Go is also memory safe.
- Keyb0ardWarri0r 2y ago
  But can't be embedded in other projects as easily as Rust (FFI, WASM).
  - steveklabnik 2y ago
    I don't disagree, but "not as easily" is different than "cannot be."
- gpm 2y ago
  I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.
  - steveklabnik 2y ago
    Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7 https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...
    - EE84M3i 2y ago
      It's been quite a while since I worked with golang details but I seem to remember writes to the same map from multiple goroutines being UB if GOMAXPROCS>1? Did they eventually solve that, or is that excluded from the definition of memory-safe language because it's a different type of safety?
      - gpm 2y ago
        This is my understanding (both that that can occur, and that it does not count as memory safe). I called out the types I did in my post specifically because they're the types where data races can result in arbitrary memory corruption (in the actual implementation, the spec is arguably not even that strict). Per https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions (the same linke as in Steve's reply to me)
      - steveklabnik 2y ago
        I believe that post 1.6, the runtime will try and detect this, but it's not my area of expertise.
    - cyberax 2y ago
      Java is not similar. It guarantees memory safety even for multithreaded code with data races. It can result in stack overflows, infinite loops, but not in memory corruption. That's not the case for Go, it's trivially easy to create memory corruption with multiple threads there.
      - steveklabnik 2y ago
        "Similar" does not mean "the same," you are correct that Java's guarantee is stronger.
    - ameliaquining 2y ago
      IIUC word tearing in Java cannot cause arbitrary memory corruption. Any read is guaranteed to see either the old value, or the new value, or half of each. Since these are just numbers we're talking about, not pointers, and the language doesn't otherwise allow memory-unsafe things like pointer arithmetic, a data race resulting in word tearing in Java can at worst result in a runtime crash or a logic bug, not arbitrary memory corruption. By contrast, in Go, all it takes to cause full-blown undefined behavior, in the same sense as C or C++ or Rust, is accessing an interface/map/slice value in a racy way, not having the race detector on, and being sufficiently unlucky. I agree that in practice this doesn't stop people from calling Go a memory-safe language. I think it's reasonable to argue that this statement is just wrong. That said, I think the Carbon people once said something along the lines of, in their experience, it's rare in practice for memory corruption bugs in C++ to be caused solely by data races. So a language that's memory-safe in single-threaded contexts, but where concurrency is not memory-safe, is "good enough". Maybe it's the same in Go. I am still suspicious of this, though. Maybe it's just that concurrent operations are rarer in general because they're so famously hard to get right, and this makes it less likely that you'll have one that's exactly the right kind of wrong to cause memory corruption. Certainly it seems at odds with the notion that you want the exceptions to memory safety to be auditable.
- GaggiX 2y ago
  Go can have data races, so I would not consider it memory safe.
- tedunangst 2y ago
  Since you've mentioned that you never see the annoying strike force threads that others complain about, you're in one.
  - steveklabnik 2y ago
    I said that I do not see them happening at the rate that people say they happen. I never said they don't happen.
K0nserv 2y ago
In a similar way Rust can be very useful for the hot path in programs written in Python, Ruby, etc. You don't have to throw out and rewrite everything, but because Rust can look like C you can use it easily anywhere C FFI is supported.
TheCoreh 2y ago
> like Microsoft with its TypeScript rewrite in Go My understanding is that Microsoft chose Go precisely to avoid having to do a full rewrite. Of all the “modern” native/AoT compiled languages (Rust, Swift, Go, Zig) Go has the most straightforward 1:1 mapping in semantics with the original TypeScript/JavaScript, so that a tool-assisted translation of the whole codebase is feasible with bug-for-bug compatibility, and minimal support/utility code. It would be of course _possible_ to port/translate it to any language (Including Rust) but you would essentially end up implementing a small JavaScript runtime and GC, with none or very little of the safety guarantees provided by Rust. (Rust's ownership model generally favors drastically different architectures.)
- jeppester 2y ago
  As I understood their arguments it was not about the effort needed to rewrite the project. It was about being able to have two codebases (old and new) that are so structurally similar, that it won't be a big deal to keep updating both
  - IshKebab 2y ago
    No, it was absolutely about the effort needed to rewrite the project. They couldn't afford a rewrite, only a port. They're not going to keep maintaining the Typescript version once they have transitioned to the Go version.
    - serial_dev 2y ago
      Yes, they distinguish between a rewrite and a port (first time I heard the distinction like that, but it intuitively makes sense). A Go port looks roughly the same as TypeScript, same “shape”, same concepts, so they don’t need to re-architect the code, they can just “translate” TypeScript to Go, then clean up where makes sense or needed. For a good while (definitely years, probably half a decade, if you ask me) while both projects are maintained, adding fixes and features will be therefore easy. The two codebases can be expected to have almost the same output and bugs, both is good for maintainability. With Rust, the translation wouldn’t work as Rust is significantly different. This would mean rethinking everything, the architecture would diverge, resulting in two possibly very different set of bugs. With different structure, tweaking both at the same would be very difficult.
deleted 2y ago
[deleted]
mdriley 2y ago
Hi, I lead Chrome's Rust efforts. I think the Typescript folks made a great and well-reasoned decision.
- aapoalas 2y ago
  Thank you, it's really nice seeing cooler heads prevail on the question of "why didn't they build in my favourite thing X?" In entirely unrelated news, I think Chrome should totally switch engines from V8 to a Rust built one, like hmm... our / my Nova JavaScript engine! j/k Great stuff on the font front, thank you for the articles, Rust/C++ interop work, and keep it up!
wavemode 2y ago
You're saying choosing Go over Rust was a mistake? Why?
timewizard 2y ago
"If you build it they will come."
raggi 2y ago
Odd comparison / statement in the context of MS rewriting GDI in Rust

steveklabnik 2y ago

> like Microsoft with its TypeScript rewrite in Go Go is also memory safe.

Keyb0ardWarri0r 2y ago
But can't be embedded in other projects as easily as Rust (FFI, WASM).
- steveklabnik 2y ago
  I don't disagree, but "not as easily" is different than "cannot be."
gpm 2y ago
I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.
- steveklabnik 2y ago
  Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7 https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...
  - EE84M3i 2y ago
    It's been quite a while since I worked with golang details but I seem to remember writes to the same map from multiple goroutines being UB if GOMAXPROCS>1? Did they eventually solve that, or is that excluded from the definition of memory-safe language because it's a different type of safety?
    - gpm 2y ago
      This is my understanding (both that that can occur, and that it does not count as memory safe). I called out the types I did in my post specifically because they're the types where data races can result in arbitrary memory corruption (in the actual implementation, the spec is arguably not even that strict). Per https://go.dev/ref/mem#restrictions https://go.dev/ref/mem#restrictions (the same linke as in Steve's reply to me)
    - steveklabnik 2y ago
      I believe that post 1.6, the runtime will try and detect this, but it's not my area of expertise.
  - cyberax 2y ago
    Java is not similar. It guarantees memory safety even for multithreaded code with data races. It can result in stack overflows, infinite loops, but not in memory corruption. That's not the case for Go, it's trivially easy to create memory corruption with multiple threads there.
    - steveklabnik 2y ago
      "Similar" does not mean "the same," you are correct that Java's guarantee is stronger.
  - ameliaquining 2y ago
    IIUC word tearing in Java cannot cause arbitrary memory corruption. Any read is guaranteed to see either the old value, or the new value, or half of each. Since these are just numbers we're talking about, not pointers, and the language doesn't otherwise allow memory-unsafe things like pointer arithmetic, a data race resulting in word tearing in Java can at worst result in a runtime crash or a logic bug, not arbitrary memory corruption. By contrast, in Go, all it takes to cause full-blown undefined behavior, in the same sense as C or C++ or Rust, is accessing an interface/map/slice value in a racy way, not having the race detector on, and being sufficiently unlucky. I agree that in practice this doesn't stop people from calling Go a memory-safe language. I think it's reasonable to argue that this statement is just wrong. That said, I think the Carbon people once said something along the lines of, in their experience, it's rare in practice for memory corruption bugs in C++ to be caused solely by data races. So a language that's memory-safe in single-threaded contexts, but where concurrency is not memory-safe, is "good enough". Maybe it's the same in Go. I am still suspicious of this, though. Maybe it's just that concurrent operations are rarer in general because they're so famously hard to get right, and this makes it less likely that you'll have one that's exactly the right kind of wrong to cause memory corruption. Certainly it seems at odds with the notion that you want the exceptions to memory safety to be auditable.
GaggiX 2y ago
Go can have data races, so I would not consider it memory safe.
tedunangst 2y ago
Since you've mentioned that you never see the annoying strike force threads that others complain about, you're in one.
- steveklabnik 2y ago
  I said that I do not see them happening at the rate that people say they happen. I never said they don't happen.

K0nserv 2y ago

In a similar way Rust can be very useful for the hot path in programs written in Python, Ruby, etc. You don't have to throw out and rewrite everything, but because Rust can look like C you can use it easily anywhere C FFI is supported.

TheCoreh 2y ago

> like Microsoft with its TypeScript rewrite in Go My understanding is that Microsoft chose Go precisely to avoid having to do a full rewrite. Of all the “modern” native/AoT compiled languages (Rust, Swift, Go, Zig) Go has the most straightforward 1:1 mapping in semantics with the original TypeScript/JavaScript, so that a tool-assisted translation of the whole codebase is feasible with bug-for-bug compatibility, and minimal support/utility code. It would be of course _possible_ to port/translate it to any language (Including Rust) but you would essentially end up implementing a small JavaScript runtime and GC, with none or very little of the safety guarantees provided by Rust. (Rust's ownership model generally favors drastically different architectures.)

jeppester 2y ago
As I understood their arguments it was not about the effort needed to rewrite the project. It was about being able to have two codebases (old and new) that are so structurally similar, that it won't be a big deal to keep updating both
- IshKebab 2y ago
  No, it was absolutely about the effort needed to rewrite the project. They couldn't afford a rewrite, only a port. They're not going to keep maintaining the Typescript version once they have transitioned to the Go version.
  - serial_dev 2y ago
    Yes, they distinguish between a rewrite and a port (first time I heard the distinction like that, but it intuitively makes sense). A Go port looks roughly the same as TypeScript, same “shape”, same concepts, so they don’t need to re-architect the code, they can just “translate” TypeScript to Go, then clean up where makes sense or needed. For a good while (definitely years, probably half a decade, if you ask me) while both projects are maintained, adding fixes and features will be therefore easy. The two codebases can be expected to have almost the same output and bugs, both is good for maintainability. With Rust, the translation wouldn’t work as Rust is significantly different. This would mean rethinking everything, the architecture would diverge, resulting in two possibly very different set of bugs. With different structure, tweaking both at the same would be very difficult.

deleted 2y ago

[deleted]

mdriley 2y ago

Hi, I lead Chrome's Rust efforts. I think the Typescript folks made a great and well-reasoned decision.

aapoalas 2y ago
Thank you, it's really nice seeing cooler heads prevail on the question of "why didn't they build in my favourite thing X?" In entirely unrelated news, I think Chrome should totally switch engines from V8 to a Rust built one, like hmm... our / my Nova JavaScript engine! j/k Great stuff on the font front, thank you for the articles, Rust/C++ interop work, and keep it up!

wavemode 2y ago

You're saying choosing Go over Rust was a mistake? Why?

timewizard 2y ago

"If you build it they will come."

raggi 2y ago

Odd comparison / statement in the context of MS rewriting GDI in Rust