4 ms·

Rust support could be good, but does that mean a lot of work? I mean, a lots of features that natively supported in Go require crates or coding-by-hand in Rust

by rqs 9y ago

Rust support could be good, but does that mean a lot of work? I mean, a lots of features that natively supported in Go require crates or coding-by-hand in Rust, maybe that's why Go gets supported first.

ddorian43 9y ago
The reason is that Go is more mainstream.
- eyko 9y ago
  And Go has supported cross compilation from the very beginning. Cross compiling in Rust has not been historically that good or accessible for beginners.
  - curun1r 9y ago
    Xargo isn't that bad, and neither is using a Docker container to build. Plus, a lot of teams generate their build artifacts in CI environments that are already Linux. So there's a bunch of pretty easy ways to get Rust code running in Lambda. Honestly the reason why official Rust support may never make sense is that it's so easy to use Neon to build native Node modules with Rust. Not one line of JS is needed and the impedance between the two languages is minimal. Go would require more hacks and copying thanks to both it and Node having their own GC. Basically Rust is flexible enough that official support isn't necessary whereas Go requires official support to avoid ugly hacks. FWIW, I've never used Lambda to do what I'm suggesting above, but I've done it with GCP's equivalent and it works great.
    - bpicolo 9y ago
      > why official Rust support may never make sense is that it's so easy I suspect the only thing Amazon will care about here is consumer demand, and potentially the ability of consumers to move from other platforms to theirs (e.g. if Google cloud supports <thing> they are more likely to do so in order to convince people to move). Rust is a cool language, but it's use in HTTP services is not as widespread as Go, and there are a bunch of other languages I'd expect first (PHP, Ruby?)
awj 9y ago
I would assume that the Lambda team is more likely to fill in gaps in support for things that already have official SDKs before starting to officially support something that the rest of AWS isn't yet working on.

by rqs 9y ago

ddorian43 9y ago

The reason is that Go is more mainstream.

eyko 9y ago
And Go has supported cross compilation from the very beginning. Cross compiling in Rust has not been historically that good or accessible for beginners.
- curun1r 9y ago
  Xargo isn't that bad, and neither is using a Docker container to build. Plus, a lot of teams generate their build artifacts in CI environments that are already Linux. So there's a bunch of pretty easy ways to get Rust code running in Lambda. Honestly the reason why official Rust support may never make sense is that it's so easy to use Neon to build native Node modules with Rust. Not one line of JS is needed and the impedance between the two languages is minimal. Go would require more hacks and copying thanks to both it and Node having their own GC. Basically Rust is flexible enough that official support isn't necessary whereas Go requires official support to avoid ugly hacks. FWIW, I've never used Lambda to do what I'm suggesting above, but I've done it with GCP's equivalent and it works great.
  - bpicolo 9y ago
    > why official Rust support may never make sense is that it's so easy I suspect the only thing Amazon will care about here is consumer demand, and potentially the ability of consumers to move from other platforms to theirs (e.g. if Google cloud supports <thing> they are more likely to do so in order to convince people to move). Rust is a cool language, but it's use in HTTP services is not as widespread as Go, and there are a bunch of other languages I'd expect first (PHP, Ruby?)

awj 9y ago

I would assume that the Lambda team is more likely to fill in gaps in support for things that already have official SDKs before starting to officially support something that the rest of AWS isn't yet working on.