4 ms·

You can also rewrite to C++, OCaml, Go... Each language has benefits and drawbacks, and there is good reason for each them to exist. Would your project benefit

by hbbio 9y ago

You can also rewrite to C++, OCaml, Go... Each language has benefits and drawbacks, and there is good reason for each them to exist. Would your project benefit a lot from algebric datatypes -> OCaml is a great fit! You want to port as soon as you can: C++ is your friend. You plan to write HTTPS service nodes: Go has the best standard library out there.

lobster_johnson 9y ago
If you read the article you'll notice that he proposes that Rust is a better language because it allows incremental rewriting, rather than a complete one; Rust doesn't have a runtime, doesn't have GC, and can fairly seamlessly/painlessly integrate with C (you can both call and be called from C easily). That changes the equation considerably, compared to something like Go where none of these benefits exists. For example, exporting code from Go not only requires the runtime and GC, there's also significant function call overhead because of the way Go maps goroutines to threads. There are many other good languages, but few of them have these benefits. C++ is probably the option with the least amount of friction against C, but then you're also inheriting most of the unsafety of C.
- rbehrends 9y ago
  Incremental rewriting introduces the potential for new issues, as foreign function interfaces are inherently unsafe. Rust also has its own costs. Its biggest limitation when it comes to mixing in code with that written in another language is probably its poor support for shared ownership (i.e. multiple references of the same object), while in most languages, shared ownership is the norm. Multi-language setups (which you invariably get with an incremental rewrite) also generally create other interfacing issues when they share objects. How are you going to represent `std::shared_ptr<T>` or `std::vector<T>` in Rust, for example? They are opaque types, after all. Can you guarantee that Rust properly observes C++ semantics with regard to assignment, move assignments, and destructors when dealing with instances declared entirely in C++ code once you start mixing and matching C++ and Rust?

by hbbio 9y ago

lobster_johnson 9y ago

If you read the article you'll notice that he proposes that Rust is a better language because it allows incremental rewriting, rather than a complete one; Rust doesn't have a runtime, doesn't have GC, and can fairly seamlessly/painlessly integrate with C (you can both call and be called from C easily). That changes the equation considerably, compared to something like Go where none of these benefits exists. For example, exporting code from Go not only requires the runtime and GC, there's also significant function call overhead because of the way Go maps goroutines to threads. There are many other good languages, but few of them have these benefits. C++ is probably the option with the least amount of friction against C, but then you're also inheriting most of the unsafety of C.

rbehrends 9y ago
Incremental rewriting introduces the potential for new issues, as foreign function interfaces are inherently unsafe. Rust also has its own costs. Its biggest limitation when it comes to mixing in code with that written in another language is probably its poor support for shared ownership (i.e. multiple references of the same object), while in most languages, shared ownership is the norm. Multi-language setups (which you invariably get with an incremental rewrite) also generally create other interfacing issues when they share objects. How are you going to represent `std::shared_ptr<T>` or `std::vector<T>` in Rust, for example? They are opaque types, after all. Can you guarantee that Rust properly observes C++ semantics with regard to assignment, move assignments, and destructors when dealing with instances declared entirely in C++ code once you start mixing and matching C++ and Rust?