5 ms·

> We chose Rust for this rewrite because it combines best-in-class speed with low resource usage while still offering the safety of standard server languages. L

> We chose Rust for this rewrite because it combines best-in-class speed with low resource usage while still offering the safety of standard server languages. Low resource usage was particularly important to us because some of the performance issues with the old server were caused by the garbage collector. Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem? Given all the other issues they noted with using a less mature language like Rust in production, that's a pretty heavy load to take on in exchange for not having to tune GC. Isn't GC tuning a fairly well understood problem? Is there something about encoding large documents that makes it a significantly greater obstacle? Or are there other unstated considerations at play here? For example, I mean this completely earnestly and not cynically, but there is a lot more PR and recruitment value in blogging about a hot new cutting-edge language than "how we rewrote our TypeScript server in Java".

steveklabnik 8y ago
One thing that we've been hearing for a while is that even if you can tune a GC, it still takes up significantly more memory than the equivalent Rust program. GCs can be memory hungry. Sometimes, you care a lot about RSS. It just depends.
vvanders 8y ago
GC still brings its own set of problems like Finalizers and the like. GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear.
- staticassertion 8y ago
  > GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear. I've experienced this, having previously worked on Java services. It can be quite a pain and can throw a wrench into your understanding of how you intended to scale.
observer12 8y ago
>Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem? The post says GC was already a problem in their old system.
- abalone 8y ago
  Their old Nodejs system. Java GC tuning is more robust and well understood. So I'm wondering if it was truly a case of "Java GC is going to be a nightmare, let's take on a very early stage language with lots of unknown risks instead." Or if perhaps there's some champing at the bit to adopt a hot new language for its own sake. FWIW, I'm excited for Rust and also Swift for exactly these reasons. I just want to see hard justifications for using them in production this early.
  - seangrogg 8y ago
    Problem: We're running into an issue with the garbage collector which, given the nature of the task, is not actually adding any value. Potential solution 1: Replace with code that doesn't have garbage collector overhead in the first place Potential solution 2: Replace with code that has different, robust garbage collector I get where you're coming from, but even I would be inclined to choose solution 1 in this case. That they chose Rust instead of C++ is their own business, but that they chose either of those over Java just seems sensible to me.
    - abalone 8y ago
      That's not really a fair summary. The issue is that less mature language have lots of other issues that come along with the good. Just in this article they noted immature libraries, difficulties with async that kept them from migrating fully off of node.js, and difficulties with error handling. So you have to weigh those in the comparison, not just focus on the one major benefit.
      - seangrogg 8y ago
        They were able to resolve a performance-critical issue that was problematic to a critical part of their application by basically writing a script rather than needing to refactor their code base. They can benefit further by choosing something more performance-oriented than Node.js, sure. But they weren't having issues with their whole application failing - just a specific piece. When you want to expand your driveway your first thought shouldn't be what materials you want to build your new house in.
Thaxll 8y ago
Lot of companies pick x.y.z because it's fancy not because it's the best solution. ofc Java would have been a great solution here.
- Ar-Curunir 8y ago
  Java still has GC overhead and higher resource consumption in general, when compared to rust or C++
nicoburns 8y ago
Rust might immature, but it's rock solid. I don't think lack of maturity of the core language is a reason not to use it in production anymore. Lack of available libraries may be an issue, but if it's not then Rust seems like a pretty goos choice to me.
tazjin 8y ago
Language maturity is not a one-dimensional problem and it's also not equal to the age of the language. To name just two ways in which I consider Rust more mature than Java: * It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example). * Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], the Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there. The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same problems. Sometimes even the well-known and used ones are of very questionable quality[2]. [1]: https://serde.rs/ https://serde.rs/ [2]: https://github.com/FasterXML/jackson-databind/pull/1423 https://github.com/FasterXML/jackson-databind/pull/1423
- blub 8y ago
  The type system has no relationship to language maturity. It's just a different type system with different trade-offs. Your second point is invalidated by the blog itself: "Many libraries are still early".
- dkarl 8y ago
  Jackson's status as the de facto Java standard for reading and writing JSON really reflects poorly on the Java community. Too often the biggest, hairiest solutions get anointed as the safe "best practices" choice for all new development when really they should only be used if you know specific reasons why they will pull their weight relative to simpler solutions. Jackson is an 800lb gorilla with an impressive arsenal of features, but there's no way in hell it should be the default choice for a simple greenfield CRUD application.
  - abalone 8y ago
    Without turning this into a long tangent subthread.. could you point to some support for this? The comparisons I've seen are more nuanced.[1] [1] https://blog.takipi.com/the-ultimate-json-library-json-simple-vs-gson-vs-jackson-vs-json/ https://blog.takipi.com/the-ultimate-json-library-json-simpl...

steveklabnik 8y ago

One thing that we've been hearing for a while is that even if you can tune a GC, it still takes up significantly more memory than the equivalent Rust program. GCs can be memory hungry. Sometimes, you care a lot about RSS. It just depends.

vvanders 8y ago

GC still brings its own set of problems like Finalizers and the like. GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear.

staticassertion 8y ago
> GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear. I've experienced this, having previously worked on Java services. It can be quite a pain and can throw a wrench into your understanding of how you intended to scale.

observer12 8y ago

>Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem? The post says GC was already a problem in their old system.

abalone 8y ago
Their old Nodejs system. Java GC tuning is more robust and well understood. So I'm wondering if it was truly a case of "Java GC is going to be a nightmare, let's take on a very early stage language with lots of unknown risks instead." Or if perhaps there's some champing at the bit to adopt a hot new language for its own sake. FWIW, I'm excited for Rust and also Swift for exactly these reasons. I just want to see hard justifications for using them in production this early.
- seangrogg 8y ago
  Problem: We're running into an issue with the garbage collector which, given the nature of the task, is not actually adding any value. Potential solution 1: Replace with code that doesn't have garbage collector overhead in the first place Potential solution 2: Replace with code that has different, robust garbage collector I get where you're coming from, but even I would be inclined to choose solution 1 in this case. That they chose Rust instead of C++ is their own business, but that they chose either of those over Java just seems sensible to me.
  - abalone 8y ago
    That's not really a fair summary. The issue is that less mature language have lots of other issues that come along with the good. Just in this article they noted immature libraries, difficulties with async that kept them from migrating fully off of node.js, and difficulties with error handling. So you have to weigh those in the comparison, not just focus on the one major benefit.
    - seangrogg 8y ago
      They were able to resolve a performance-critical issue that was problematic to a critical part of their application by basically writing a script rather than needing to refactor their code base. They can benefit further by choosing something more performance-oriented than Node.js, sure. But they weren't having issues with their whole application failing - just a specific piece. When you want to expand your driveway your first thought shouldn't be what materials you want to build your new house in.

Thaxll 8y ago

Lot of companies pick x.y.z because it's fancy not because it's the best solution. ofc Java would have been a great solution here.

Ar-Curunir 8y ago
Java still has GC overhead and higher resource consumption in general, when compared to rust or C++

nicoburns 8y ago

Rust might immature, but it's rock solid. I don't think lack of maturity of the core language is a reason not to use it in production anymore. Lack of available libraries may be an issue, but if it's not then Rust seems like a pretty goos choice to me.

tazjin 8y ago

Language maturity is not a one-dimensional problem and it's also not equal to the age of the language. To name just two ways in which I consider Rust more mature than Java: * It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example). * Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], the Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there. The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same problems. Sometimes even the well-known and used ones are of very questionable quality[2]. [1]: https://serde.rs/ https://serde.rs/ [2]: https://github.com/FasterXML/jackson-databind/pull/1423 https://github.com/FasterXML/jackson-databind/pull/1423

blub 8y ago
The type system has no relationship to language maturity. It's just a different type system with different trade-offs. Your second point is invalidated by the blog itself: "Many libraries are still early".
dkarl 8y ago
Jackson's status as the de facto Java standard for reading and writing JSON really reflects poorly on the Java community. Too often the biggest, hairiest solutions get anointed as the safe "best practices" choice for all new development when really they should only be used if you know specific reasons why they will pull their weight relative to simpler solutions. Jackson is an 800lb gorilla with an impressive arsenal of features, but there's no way in hell it should be the default choice for a simple greenfield CRUD application.
- abalone 8y ago
  Without turning this into a long tangent subthread.. could you point to some support for this? The comparisons I've seen are more nuanced.[1] [1] https://blog.takipi.com/the-ultimate-json-library-json-simple-vs-gson-vs-jackson-vs-json/ https://blog.takipi.com/the-ultimate-json-library-json-simpl...