8 ms·

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are rea

by Nican 6y ago

There is an advocate on our team that wants to migrate our web service from Nodejs to Rust. While I am not a huge fan of Typescript, at least libraries are readily available and generally easy to use. On the other hand, being able to show that we are able to do monitoring, user auditing, ORM, opentracing, gRPC-web with Rust is non trivial. Now that I think of it, being able to do a "hello world" on any language is pretty simple. But having all the tools around it to build a production level service is a different story.

pestaa 6y ago
What is your take on TypeScript, what is it you don't like?
- jamil7 6y ago
  Not the OP but my take is that Typescript has done great things for improving JS but it's still JS and carries a lot of it's baggage with it. There is only so far you can take it while maintaining compatibility and the type system is overly complicated in places because of this. It also doesn't really give you the same guarantees that something like Rust does, I don't believe the two type systems are that comparable. On top of that unless you use all TS packages types are maintained and installed separately adding to an already tricky to maintain dependency graph that comes with Node development.
- Nican 6y ago
  I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs. 1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request. 2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that. 3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2] 4. Sometimes libraries does not use async correctly, and breaks stack traces. 5. Sometimes TypeScript's generic errors can be as bad as C++. My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people. [1] https://github.com/hapijs/hapi/issues/4111 https://github.com/hapijs/hapi/issues/4111 [2] (GitHub is down, or I would grab the link)
  - seer 6y ago
    I can feel the pain on all 5 points. One thing I did notice though is that NodeJS has such a huge breadth of packages that its _very_ hard to actually pick something good. But there is almost always an alternative that's maybe not as popular, but is a lot more "solid" alternative. For example we used SOHU-Co/kafka-node for a while as a kafka client, until we hit some bugs that made us dig through its internals and we realised it had some deep issues. We then switched to kafkajs which turned out to be much more mature and polished, even though it was less "popular". Sequalize in particular I think was developed in an era before TypeScript was a thing so it follows the ideals of that time, more in line with Ruby and being easy to use and malleable. We switched to using slonik for our query needs, with a more declarative and static approach, skipping ORMs and query builders altogether - just raw strictly typed queries. I think in the end its a better approach for our needs. I guess what I'm trying to say is that TypeScript was built to be able to handle _all_ of the weird and wonderful world of JS from its most amateurish and fun, to its most solemn and strict. And it's just a matter of picking up where on the spectrum you want to operate and make your dependencies match that vibe. It's limiting and freeing at the same time.
    - Nican 6y ago
      I will have to take a look Slonik. I feel like I have been to hell and back with ORMs, between Sequelize, Entity Framework, Hibernate, SQLAlchemy, etc.. and frankly, I think they just cause more headaches than solve problems. I would love to have strongly typed SQL queries, but I have found that Dapper [1] fills a special place in my heart. [1] https://github.com/StackExchange/Dapper https://github.com/StackExchange/Dapper
      - seer 6y ago
        I've been following https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped for awhile. It should give you TS types from sql files (and even sql template literals) directly. Though I haven't used it in prod. Might be worth a look.
ec109685 6y ago
Some of the things you listed can be moved into a proxy like Envoy, so you don’t have to rewrite those wheels as you change languages.
TheUndead96 6y ago
I would wait and see whether GraalVM would not help significantly with performance. After that I would try running the web service with Deno. Then I would rewrite in Go, then I would rewrite in Rust. That is not to say I think Go is better than Rust in every dimension (I prefer Rust for most things), but I think the Go community have really optimised for this one single usecase.
jimbob45 6y ago
What does he think will improve? Migration for the sake of migration is a waste of everyone’s time.
- rwmj 6y ago
  His own resume probably. The company takes all the risk and he takes the reward.
- emerongi 6y ago
  I'd say there is value in learning for the sake of learning. Even if you later on decide that the Rust implementation is not production-ready, you can draw conclusions from the project, and the next time someone considers Rust for a bigger project, there is a member on the team who can provide insight into potential issues. Of course, the project would have to be sufficiently small to not waste too much time.
Cthulhu_ 6y ago
Rewriting is very expensive, and the advocate will need to make a VERY strong case for Rust if they're asking your company to invest in replacing it - and alternatives have to be suggested as well, including other languages and a good list of things wrong with Node / TS. Consider developer availability as well. I don't think a strong enough argument can be made. I'm sure you CAN write web services in Rust, and that in very specific cases it'll have some benefits over Node, but honestly very few people work in an area like that. Disclaimer: I've settled on using Go to rewrite an existing application. The original app was written in PHP; nothing wrong with PHP per se, but the existing codebase is a mess and the PHP version is hard to keep up to date because of LTS versions of operating systems + very slow and careful updates at our customers (it's network infrastructure). For me, switching to a compiled language that produces a self-contained executable was a compelling argument. I have to admit that I do kinda pine for something like Java again though.
- Nican 6y ago
  Yeah. I am being very cautious about their desires. I learned that the best way to discourage someone from taking a large project is to show how much work it would be. Just shutting down developers is not nice.
  - nazka 6y ago
    I agree too. Rewrites are a scary thing. The best is to do some test with a few new micro services and see how it feel to code from 0 to production. Learning the tool chain etc..
- philosopher1234 6y ago
  What do you miss about java?
  - tomerbd 6y ago
    The ecosystem, i.e. Spring.
    - 6y ago
nilkn 6y ago
Generally when I’ve successfully advocated for new languages or tools at work, it’s been by gradually introducing the language in newer and fairly self-contained projects where the risk is relatively low. This provides a safe space to explore all the concerns you just mentioned without compromising any working code. If you have some interest in Rust, that’s what I’d personally recommend instead of migrating an existing service to a different language.
pdr2020 6y ago
Rust is much too low level for most glue/web services. Unless you have a specific high performance requirement (and Go doesn't meet this), there's no real strong case for migration here.
- zozbot234 6y ago
  Rust itself is not inherently "low level" per se. But others are probably right that the whole web services ecosystem for Rust is rather half-baked at this time, the OP notwithstanding.
  - rob74 6y ago
    Actually the OP only wrote that the current state of the ecosystem is surprisingly mature, but he doesn't recommend writing anything serious in it yet. Personally I don't see the point to implement a typical web application in Rust - the performance improvements you get will be lost on IO-bound applications, but you'll still be saddled with the complexity of the memory management. I'd rather suggest to rewrite VS Code or the Slack client in Rust (i.e. apps which currently use Web technologies on the desktop) - those would definitely benefit more from increased performance and reduced memory footprint...
    - zozbot234 6y ago
      > the performance improvements you get will be lost on IO-bound applications Performance starts mattering even in IO-bound applications as soon as you're trying to seriously scale out. Especially when running on a cloud-based platform. As for "the complexity of memory management", people like to bring this up about Rust but OP suggests that it's not a huge concern with the language. I do agree that rewriting stuff like Electron-based apps should be a priority, and that Rust can help this via easy bindings to native OS and GUI platforms.
    - deleuze 6y ago
      Stability is often more important than performance.
  - 6y ago
plmu 6y ago
As far as I know, you need grpc-web only because there is no direct grpc implementation for javascript. For rust, c++ etc. you would use grpc natively.
- Nican 6y ago
  grpc-web is attractive to our use case because it would take away from manually implementing REST interfaces and every once in a while having type mismatches. The less room for mistakes, the better. .NET Core just recently last month that gRPC-web is stable [1]. It would remove a huge amount of boilerplate in setting up services on both client and server side. Some people also recommend to use Envoy [2], but usually the less cogs the better. [1] https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-available/ https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-a... [2] https://grpc.io/docs/languages/web/basics/ https://grpc.io/docs/languages/web/basics/
stunt 6y ago
Your development cost will skyrocket. Even if you ignore everything that the ecosystem may not offer to you at this point (which is a big deal), you will have a hard time to find experienced Rust developers that like to build web services with it.
jariel 6y ago
What are the advantages of Rust? Probably speed, robustness, but probably not speed of development and iteration. If you're doing image processing, you may want to have node.js do the user interaction bits, and have the sophisticated image processing in Rust. But I don't really see Rust as the go-to platform for crud APPS with DB access etc..

by Nican 6y ago

pestaa 6y ago

What is your take on TypeScript, what is it you don't like?

jamil7 6y ago
Not the OP but my take is that Typescript has done great things for improving JS but it's still JS and carries a lot of it's baggage with it. There is only so far you can take it while maintaining compatibility and the type system is overly complicated in places because of this. It also doesn't really give you the same guarantees that something like Rust does, I don't believe the two type systems are that comparable. On top of that unless you use all TS packages types are maintained and installed separately adding to an already tricky to maintain dependency graph that comes with Node development.
Nican 6y ago
I come from a C# background, but to list out a few hurdles that I have already deal with with TypeScript/NodeJs. 1. C#'s AsyncLocal has made a few things simpler to trace SQL queries to a request. 2. We chose to use hapi.js some 2 years ago, because we found the interface superior to Express, but I did not expect the sole developer of hapi.js to decide stop working on the project [1], and left my head scratching on what I am going to do about that. 3. TypeScript's interface sometimes feels too much like just "suggestions", and every once in a while run across scenarios that are not fully supported. One that I really dislike is that Sequelize's "where" options has no type support for the model. [2] 4. Sometimes libraries does not use async correctly, and breaks stack traces. 5. Sometimes TypeScript's generic errors can be as bad as C++. My favorite feature of TypeScript is being able to just define types/objects in-line, but I actually like to stay on the side of caution and stability on a large project with many people. [1] https://github.com/hapijs/hapi/issues/4111 https://github.com/hapijs/hapi/issues/4111 [2] (GitHub is down, or I would grab the link)
- seer 6y ago
  I can feel the pain on all 5 points. One thing I did notice though is that NodeJS has such a huge breadth of packages that its _very_ hard to actually pick something good. But there is almost always an alternative that's maybe not as popular, but is a lot more "solid" alternative. For example we used SOHU-Co/kafka-node for a while as a kafka client, until we hit some bugs that made us dig through its internals and we realised it had some deep issues. We then switched to kafkajs which turned out to be much more mature and polished, even though it was less "popular". Sequalize in particular I think was developed in an era before TypeScript was a thing so it follows the ideals of that time, more in line with Ruby and being easy to use and malleable. We switched to using slonik for our query needs, with a more declarative and static approach, skipping ORMs and query builders altogether - just raw strictly typed queries. I think in the end its a better approach for our needs. I guess what I'm trying to say is that TypeScript was built to be able to handle _all_ of the weird and wonderful world of JS from its most amateurish and fun, to its most solemn and strict. And it's just a matter of picking up where on the spectrum you want to operate and make your dependencies match that vibe. It's limiting and freeing at the same time.
  - Nican 6y ago
    I will have to take a look Slonik. I feel like I have been to hell and back with ORMs, between Sequelize, Entity Framework, Hibernate, SQLAlchemy, etc.. and frankly, I think they just cause more headaches than solve problems. I would love to have strongly typed SQL queries, but I have found that Dapper [1] fills a special place in my heart. [1] https://github.com/StackExchange/Dapper https://github.com/StackExchange/Dapper
    - seer 6y ago
      I've been following https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped for awhile. It should give you TS types from sql files (and even sql template literals) directly. Though I haven't used it in prod. Might be worth a look.

ec109685 6y ago

Some of the things you listed can be moved into a proxy like Envoy, so you don’t have to rewrite those wheels as you change languages.

TheUndead96 6y ago

I would wait and see whether GraalVM would not help significantly with performance. After that I would try running the web service with Deno. Then I would rewrite in Go, then I would rewrite in Rust. That is not to say I think Go is better than Rust in every dimension (I prefer Rust for most things), but I think the Go community have really optimised for this one single usecase.

jimbob45 6y ago

What does he think will improve? Migration for the sake of migration is a waste of everyone’s time.

rwmj 6y ago
His own resume probably. The company takes all the risk and he takes the reward.
emerongi 6y ago
I'd say there is value in learning for the sake of learning. Even if you later on decide that the Rust implementation is not production-ready, you can draw conclusions from the project, and the next time someone considers Rust for a bigger project, there is a member on the team who can provide insight into potential issues. Of course, the project would have to be sufficiently small to not waste too much time.

Cthulhu_ 6y ago

Rewriting is very expensive, and the advocate will need to make a VERY strong case for Rust if they're asking your company to invest in replacing it - and alternatives have to be suggested as well, including other languages and a good list of things wrong with Node / TS. Consider developer availability as well. I don't think a strong enough argument can be made. I'm sure you CAN write web services in Rust, and that in very specific cases it'll have some benefits over Node, but honestly very few people work in an area like that. Disclaimer: I've settled on using Go to rewrite an existing application. The original app was written in PHP; nothing wrong with PHP per se, but the existing codebase is a mess and the PHP version is hard to keep up to date because of LTS versions of operating systems + very slow and careful updates at our customers (it's network infrastructure). For me, switching to a compiled language that produces a self-contained executable was a compelling argument. I have to admit that I do kinda pine for something like Java again though.

Nican 6y ago
Yeah. I am being very cautious about their desires. I learned that the best way to discourage someone from taking a large project is to show how much work it would be. Just shutting down developers is not nice.
- nazka 6y ago
  I agree too. Rewrites are a scary thing. The best is to do some test with a few new micro services and see how it feel to code from 0 to production. Learning the tool chain etc..
philosopher1234 6y ago
What do you miss about java?
- tomerbd 6y ago
  The ecosystem, i.e. Spring.
  - 6y ago

nilkn 6y ago

Generally when I’ve successfully advocated for new languages or tools at work, it’s been by gradually introducing the language in newer and fairly self-contained projects where the risk is relatively low. This provides a safe space to explore all the concerns you just mentioned without compromising any working code. If you have some interest in Rust, that’s what I’d personally recommend instead of migrating an existing service to a different language.

pdr2020 6y ago

Rust is much too low level for most glue/web services. Unless you have a specific high performance requirement (and Go doesn't meet this), there's no real strong case for migration here.

zozbot234 6y ago
Rust itself is not inherently "low level" per se. But others are probably right that the whole web services ecosystem for Rust is rather half-baked at this time, the OP notwithstanding.
- rob74 6y ago
  Actually the OP only wrote that the current state of the ecosystem is surprisingly mature, but he doesn't recommend writing anything serious in it yet. Personally I don't see the point to implement a typical web application in Rust - the performance improvements you get will be lost on IO-bound applications, but you'll still be saddled with the complexity of the memory management. I'd rather suggest to rewrite VS Code or the Slack client in Rust (i.e. apps which currently use Web technologies on the desktop) - those would definitely benefit more from increased performance and reduced memory footprint...
  - zozbot234 6y ago
    > the performance improvements you get will be lost on IO-bound applications Performance starts mattering even in IO-bound applications as soon as you're trying to seriously scale out. Especially when running on a cloud-based platform. As for "the complexity of memory management", people like to bring this up about Rust but OP suggests that it's not a huge concern with the language. I do agree that rewriting stuff like Electron-based apps should be a priority, and that Rust can help this via easy bindings to native OS and GUI platforms.
  - deleuze 6y ago
    Stability is often more important than performance.
- 6y ago

plmu 6y ago

As far as I know, you need grpc-web only because there is no direct grpc implementation for javascript. For rust, c++ etc. you would use grpc natively.

Nican 6y ago
grpc-web is attractive to our use case because it would take away from manually implementing REST interfaces and every once in a while having type mismatches. The less room for mistakes, the better. .NET Core just recently last month that gRPC-web is stable [1]. It would remove a huge amount of boilerplate in setting up services on both client and server side. Some people also recommend to use Envoy [2], but usually the less cogs the better. [1] https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-available/ https://devblogs.microsoft.com/aspnet/grpc-web-for-net-now-a... [2] https://grpc.io/docs/languages/web/basics/ https://grpc.io/docs/languages/web/basics/

stunt 6y ago

Your development cost will skyrocket. Even if you ignore everything that the ecosystem may not offer to you at this point (which is a big deal), you will have a hard time to find experienced Rust developers that like to build web services with it.

jariel 6y ago

What are the advantages of Rust? Probably speed, robustness, but probably not speed of development and iteration. If you're doing image processing, you may want to have node.js do the user interaction bits, and have the sophisticated image processing in Rust. But I don't really see Rust as the go-to platform for crud APPS with DB access etc..