7 ms·

I don’t know Rust and haven’t done JavaScript for years but isn’t JavaScript a bit more of a higher level language, which would make a developer more productive

I don’t know Rust and haven’t done JavaScript for years but isn’t JavaScript a bit more of a higher level language, which would make a developer more productive? Rust being closer to the hardware should require more code, and effort, to accomplish the same task.

yarg 6y ago
JavaScript's a sloppier language.
phailhaus 6y ago
Depends on what you're optimizing for. If you want memory efficiency and near-native speeds, then you need WebAssembly. And Rust is a fantastic source language to compile to WebAssembly because of its memory safety.
- iMuzz 6y ago
  Mind explaining a bit more here why Rust is a particularly good language to compile to wasm? Why does memory safety help here? Asking out of ignorance!
  - sanxiyn 6y ago
    Mostly because WebAssembly does not include GC yet, so being a non-GC language helps.
  - esperent 6y ago
    From what I understand, this mainly means that a lot of work has been put into making this process possible, while for some other languages the workflow to wasm is lacking.
  - jkelleyrtp 6y ago
    There aren’t very many good wasm options that will produce web-friendly binary sizes. The options are really c/c++, rust, and some other less-supported languages like Zig and Nim. Rust has a good mix of high-level constructs (making it more productive than C) and has a good ecosystem around it. Cross compiling is never easy, and the rust wasm story is arguably the best and most supported via wasm-bindgen.
  - gboss 6y ago
    WASM doesn’t have a garbage collector built in. Languages that use a garbage collector have to also convert their language runtime into WASM which can dramatically increase the WASM file sizes and is more work to process by the browser. Since rust doesn’t have a garbage collector this should make its WASM files smaller and more performant
  - connicpu 6y ago
    There isn't necessarily any inherent thing about the language itself that makes it better at WASM than others, it's more that it was one of the first languages that was ready for WASM. - It's low level like C and C++ so it maps cleanly onto WASM - In your average Rust project, all dependencies are already built from source, greatly increasing the likelihood all your dependencies can be built for WASM - Already using LLVM as the compiler backend made WASM targeting a lot less work than for languages that need to do that work from scratch - Probably most importantly, a lot of developers involved in core rustc development were motivated to get Rust working on WASM At least that's my perception for how Rust became such a prominent language for WASM development early on
    - jillesvangurp 6y ago
      You forgot the most important thing: it doesn't need a garbage collector. This is important because wasm garbage collection is a work in progress. The solution other languages targeting wasm typically use is bundling their own garbage collector in the compiled code, which of course adds a bit of code bloat. E.g. C# blazor wasm applications are not exactly small for this reason. There was a message yesterday in the Kotlin slack about them starting work on a wasm compiler backend for Kotlin (they already have java, native, and js compilers). https://github.com/JetBrains/kotlin/tree/master/compiler/ir/backend.wasm https://github.com/JetBrains/kotlin/tree/master/compiler/ir/... Interestingly they plan to depend on the wasm GC proposal instead of bundling their own: https://github.com/WebAssembly/gc/ https://github.com/WebAssembly/gc/ So, things are improving on this front. But it's a big reason why Rust is particularly popular for wasm right now because they have no GC and lots of developer tools that are relatively mature because they've been working on this for a while. IMHO, this will take another few years to fully mature but inevitably lots of people are going to be writing web applications that don't involve any or very little javascript. Kotlin is starting to look very solid for any kind of cross platform Android, IOS, and web based development (as well as server development, which is what I do). Swift would be another candidate and there already is a wasm compiler for that as well.
      - rhlsthrm 6y ago
        Interesting, one of the big reasons I want to learn Rust is to "future proof" myself once JS loses its monopoly on the web. Maybe Kotlin will be a better one than Rust?
  - fulafel 6y ago
    Wasm is not memory safe inside the sandbox, so the language should enforce it if you care about correctness and/or dislike the C/C++ memory bugs and debugging.
empath75 6y ago
It’s not that bad once you get used to it.
satvikpendem 6y ago
Rust actually can be a higher language. It has true generics, static algebraic data types, functional programming features, and so on, even as it is closer to the metal. It is closer to Haskell or OCaml, but more pragmatic.
- sweeneyrod 6y ago
  In what ways is Rust more pragmatic than OCaml?
  - satvikpendem 6y ago
    A good package manager, multicore support, larger community, and so on.
  - fluffything 6y ago
    Does not really require you to drop to a lower-level language for performance, unless you really need to use assembly for something. OCaml is great for the application level stuff, and also performs quite well in general. But for building fundamental parts of the stack in which perf is important (like the multi-threading runtime, the garbage collector, etc.) you need to drop down to C++, C, or Rust. OCaml is definitely much nicer to use than C and C++. But I don't find it that much nicer to use than Rust TBH.
    - wtetzner 6y ago
      > OCaml is definitely much nicer to use than C and C++. But I don't find it that much nicer to use than Rust TBH. I find OCaml quite a bit nicer to use than Rust, though in a lot of ways that's due to my preference for structuring code using modules and functors. However, due to Cargo and the fact that Rust has good Windows support, I end up reaching for Rust much more often than I do for OCaml.
      - fluffything 6y ago
        Modules is pretty much the only OCaml feature I miss in Rust. I can work around functors with some effort in Rust, and hopefully GATs will make this even simpler (although I don't expect GATs to give Rust functors).
genuine_smiles 6y ago
Rust’s type system is sound, unlike TypeScript, and Rust provides a lot more performance by default. You can get good performance out of JavaScript, but it can be difficult, and the code can end up being difficult to maintain. If you’re trying to right very fast, very correct code in JavaScript/TypeScript then Rust may be more productive.
echelon 6y ago
> isn’t JavaScript a bit more of a higher level language Rust has zero-cost abstractions that feel like using Ruby and a rich type system that makes it incredibly expressive. Working in other languages feels like going back to assembly. I wouldn't want to design state machines in any other language. Rust's enums make it feel smooth as butter. They're a killer app. (The whole ecosystem is. Cargo. Package naming. Traits. So much good stuff.) Rust is my most productive language now, and I work in Python, Java, and Typescript codebases frequently. Edit: I'm being downvoted for expressing preference? What's with all the Rust hate? Learn it instead of being a hater. It's a wonderful tool, and it's silly to dismiss because you think people are being hipsters or something. There's a reason people love it.
- shpongled 6y ago
  I'm a big Rust fan too. I have experience in all of the languages you've mentioned, and I'm most productive in Rust as well. It's funny you mention enums, there was just another thread last week where I brought up how crazy it is that sum types (Rust enums) and pattern matching have been around since the 70s but have largely been limited to the FP languages. After extensively using Rust for ~3 years now, I don't ever want to use a language without sum types - you can write incredibly expressive and concise code with them. The other major productivity boost for me is the ability to compose and chain Iterators and mix those with collection types.
  - hombre_fatal 6y ago
    People often demand generics in Go. But I think that actual sum types would be a bigger boon (if I got to choose). You can basically avoid interface{} in generic Go code with some copy and paste. But you can't really avoid it when you're trying to write code that would be cleaned up by an actual sum type. Not to commit the predicable sin of comparing Rust to Go any time either is brought up. I just mean to +1 the idea that sum types should actually be a fundamental tool that we can reach for in every language. So weird that it's taking so long to go mainstream, so to speak.
  - eloff 6y ago
    I just implemented an iterator in rust yesterday. After having done it in c++ back in the day, I was blown away by how easy and powerful it is.
bluejekyll 6y ago
This is complicated. I’m no expert with WASM, but I’m fairly familiar with Rust and have toyed around with Rust and WASM. With Rust and WASM you pay an expense of FFI between the languages. There are tools that minimize this, but there’s still a cost. Transferring data is limited to very primitive data types today, which adds a cost to translation between Rust and JS. I expect this to reduce in cost as WASM gains abilities to access the DOM and such, but it is overhead. This generally means that for many things Rust is not much faster than JS, but it is for very hot loops over CPU bound computations. As to productivity. This debate between languages will never end. JS like Python and other interpreted languages give the impression that tasks are being accomplished, but until all code paths are tested, knowing if it is correct is not obvious. Rust like many other typesafe languages (and it’s definitely on the further end of type safe) allow the compiler to detect errors in usage at compile time, well before testing and production usage. Some of us consider this to be more “productive” as it reduces the overall maintenance of the program after it’s released, but YMMV.
- jevgeni 6y ago
  Best comment in this thread. To the point and factual.
- azakai 6y ago
  This is an important point. Languages compiled to wasm have an FFI cost, and we will never fully remove it because it just uses different types than Web APIs do. This isn't a Rust problem or a C problem, it's just how wasm is. Wasm also can't use the JS standard library, and usually ends up shipping some runtime support, like malloc or string handling, which increases download size. Both of those limitations are why wasm won't make sense for the great majority of web dev work. But wasm shines for "engine" type code, like in this post - pure computation, without lots of links to the outside JS/DOM world.
lmm 6y ago
ML family languages are so much more productive that that probably outweighs the costs of manual memory management. Rust will always be less productive than Haskell or Scala, but a language with a decent type system is going to have a huge advantage over JavaScript.
- tigershark 6y ago
  ...Haskell and scala are not part of the ML family. OCAML and F# are languages belonging to the ML family.
  - lmm 6y ago
    By what definition? Haskell and Scala both have the complete ML featureset (in particular they have sum types and full pattern matching; they're also part of the small group of languages that has typeclasses, which were originally invented for Standard ML) and are on record as being heavily influenced by ML languages (via Miranda in the case of Haskell).
    - tigershark 6y ago
      https://en.m.wikipedia.org/wiki/ML_(programming_language) https://en.m.wikipedia.org/wiki/ML_(programming_language) “Today there are several languages in the ML family; the three most prominent are Standard ML (SML), OCaml and F#. Ideas from ML have influenced numerous other languages, like Haskell, Cyclone, Nemerle, ATS,[citation needed] and Elm.[3]” If you know F#, OCAML, Haskell and scala you can see that the first two have an extremely similar syntax to ML while for the last two the syntax is very different.
      - lmm 6y ago
        If you actually click down to [3] in your own link it says '"these languages" is referring to Haskell, OCaml, SML, and F#'.
Dowwie 6y ago
An experienced Rust programmer will write generally better solutions in roughly the same amount of time as what is taken to write a solution in NodeJS, where the work is familiar. There is absolutely more code to write for a language where you can have fine control over practically everything, as long as it's within the constraints governing the compiler. However, web development consists of well-treaded paths using familiar patterns of data access and manipulation. If a new project does not benefit by code re-use, the experienced Rust programmer is going to have to use more tools and techniques to accomplish something similar in functionality to that created in other languages, but with far more guarantees and control. Who cares about guarantees and control? The team that is going to have to share the burden of maintaining the code you write. With the patterns and libraries used in just this example, you can write a very high performance, memory efficient web server that can handle a large volume of concurrent requests that involve database interactions: https://github.com/actix/examples/tree/master/async_pg https://github.com/actix/examples/tree/master/async_pg All of the work has been consolidated down to a single file for illustration purposes, and it would usually be spread across files. Does it seem like a ridiculous amount of additional work, compared to other languages? I am misleading you some as there is actually a lot more to write the moment we move beyond plain vanilla workflows but this example proves what is possible.

yarg 6y ago

JavaScript's a sloppier language.

phailhaus 6y ago

Depends on what you're optimizing for. If you want memory efficiency and near-native speeds, then you need WebAssembly. And Rust is a fantastic source language to compile to WebAssembly because of its memory safety.

iMuzz 6y ago
Mind explaining a bit more here why Rust is a particularly good language to compile to wasm? Why does memory safety help here? Asking out of ignorance!
- sanxiyn 6y ago
  Mostly because WebAssembly does not include GC yet, so being a non-GC language helps.
- esperent 6y ago
  From what I understand, this mainly means that a lot of work has been put into making this process possible, while for some other languages the workflow to wasm is lacking.
- jkelleyrtp 6y ago
  There aren’t very many good wasm options that will produce web-friendly binary sizes. The options are really c/c++, rust, and some other less-supported languages like Zig and Nim. Rust has a good mix of high-level constructs (making it more productive than C) and has a good ecosystem around it. Cross compiling is never easy, and the rust wasm story is arguably the best and most supported via wasm-bindgen.
- gboss 6y ago
  WASM doesn’t have a garbage collector built in. Languages that use a garbage collector have to also convert their language runtime into WASM which can dramatically increase the WASM file sizes and is more work to process by the browser. Since rust doesn’t have a garbage collector this should make its WASM files smaller and more performant
- connicpu 6y ago
  There isn't necessarily any inherent thing about the language itself that makes it better at WASM than others, it's more that it was one of the first languages that was ready for WASM. - It's low level like C and C++ so it maps cleanly onto WASM - In your average Rust project, all dependencies are already built from source, greatly increasing the likelihood all your dependencies can be built for WASM - Already using LLVM as the compiler backend made WASM targeting a lot less work than for languages that need to do that work from scratch - Probably most importantly, a lot of developers involved in core rustc development were motivated to get Rust working on WASM At least that's my perception for how Rust became such a prominent language for WASM development early on
  - jillesvangurp 6y ago
    You forgot the most important thing: it doesn't need a garbage collector. This is important because wasm garbage collection is a work in progress. The solution other languages targeting wasm typically use is bundling their own garbage collector in the compiled code, which of course adds a bit of code bloat. E.g. C# blazor wasm applications are not exactly small for this reason. There was a message yesterday in the Kotlin slack about them starting work on a wasm compiler backend for Kotlin (they already have java, native, and js compilers). https://github.com/JetBrains/kotlin/tree/master/compiler/ir/backend.wasm https://github.com/JetBrains/kotlin/tree/master/compiler/ir/... Interestingly they plan to depend on the wasm GC proposal instead of bundling their own: https://github.com/WebAssembly/gc/ https://github.com/WebAssembly/gc/ So, things are improving on this front. But it's a big reason why Rust is particularly popular for wasm right now because they have no GC and lots of developer tools that are relatively mature because they've been working on this for a while. IMHO, this will take another few years to fully mature but inevitably lots of people are going to be writing web applications that don't involve any or very little javascript. Kotlin is starting to look very solid for any kind of cross platform Android, IOS, and web based development (as well as server development, which is what I do). Swift would be another candidate and there already is a wasm compiler for that as well.
    - rhlsthrm 6y ago
      Interesting, one of the big reasons I want to learn Rust is to "future proof" myself once JS loses its monopoly on the web. Maybe Kotlin will be a better one than Rust?
- fulafel 6y ago
  Wasm is not memory safe inside the sandbox, so the language should enforce it if you care about correctness and/or dislike the C/C++ memory bugs and debugging.

empath75 6y ago

It’s not that bad once you get used to it.

satvikpendem 6y ago

Rust actually can be a higher language. It has true generics, static algebraic data types, functional programming features, and so on, even as it is closer to the metal. It is closer to Haskell or OCaml, but more pragmatic.

sweeneyrod 6y ago
In what ways is Rust more pragmatic than OCaml?
- satvikpendem 6y ago
  A good package manager, multicore support, larger community, and so on.
- fluffything 6y ago
  Does not really require you to drop to a lower-level language for performance, unless you really need to use assembly for something. OCaml is great for the application level stuff, and also performs quite well in general. But for building fundamental parts of the stack in which perf is important (like the multi-threading runtime, the garbage collector, etc.) you need to drop down to C++, C, or Rust. OCaml is definitely much nicer to use than C and C++. But I don't find it that much nicer to use than Rust TBH.
  - wtetzner 6y ago
    > OCaml is definitely much nicer to use than C and C++. But I don't find it that much nicer to use than Rust TBH. I find OCaml quite a bit nicer to use than Rust, though in a lot of ways that's due to my preference for structuring code using modules and functors. However, due to Cargo and the fact that Rust has good Windows support, I end up reaching for Rust much more often than I do for OCaml.
    - fluffything 6y ago
      Modules is pretty much the only OCaml feature I miss in Rust. I can work around functors with some effort in Rust, and hopefully GATs will make this even simpler (although I don't expect GATs to give Rust functors).

genuine_smiles 6y ago

Rust’s type system is sound, unlike TypeScript, and Rust provides a lot more performance by default. You can get good performance out of JavaScript, but it can be difficult, and the code can end up being difficult to maintain. If you’re trying to right very fast, very correct code in JavaScript/TypeScript then Rust may be more productive.

echelon 6y ago

> isn’t JavaScript a bit more of a higher level language Rust has zero-cost abstractions that feel like using Ruby and a rich type system that makes it incredibly expressive. Working in other languages feels like going back to assembly. I wouldn't want to design state machines in any other language. Rust's enums make it feel smooth as butter. They're a killer app. (The whole ecosystem is. Cargo. Package naming. Traits. So much good stuff.) Rust is my most productive language now, and I work in Python, Java, and Typescript codebases frequently. Edit: I'm being downvoted for expressing preference? What's with all the Rust hate? Learn it instead of being a hater. It's a wonderful tool, and it's silly to dismiss because you think people are being hipsters or something. There's a reason people love it.

shpongled 6y ago
I'm a big Rust fan too. I have experience in all of the languages you've mentioned, and I'm most productive in Rust as well. It's funny you mention enums, there was just another thread last week where I brought up how crazy it is that sum types (Rust enums) and pattern matching have been around since the 70s but have largely been limited to the FP languages. After extensively using Rust for ~3 years now, I don't ever want to use a language without sum types - you can write incredibly expressive and concise code with them. The other major productivity boost for me is the ability to compose and chain Iterators and mix those with collection types.
- hombre_fatal 6y ago
  People often demand generics in Go. But I think that actual sum types would be a bigger boon (if I got to choose). You can basically avoid interface{} in generic Go code with some copy and paste. But you can't really avoid it when you're trying to write code that would be cleaned up by an actual sum type. Not to commit the predicable sin of comparing Rust to Go any time either is brought up. I just mean to +1 the idea that sum types should actually be a fundamental tool that we can reach for in every language. So weird that it's taking so long to go mainstream, so to speak.
- eloff 6y ago
  I just implemented an iterator in rust yesterday. After having done it in c++ back in the day, I was blown away by how easy and powerful it is.

bluejekyll 6y ago

This is complicated. I’m no expert with WASM, but I’m fairly familiar with Rust and have toyed around with Rust and WASM. With Rust and WASM you pay an expense of FFI between the languages. There are tools that minimize this, but there’s still a cost. Transferring data is limited to very primitive data types today, which adds a cost to translation between Rust and JS. I expect this to reduce in cost as WASM gains abilities to access the DOM and such, but it is overhead. This generally means that for many things Rust is not much faster than JS, but it is for very hot loops over CPU bound computations. As to productivity. This debate between languages will never end. JS like Python and other interpreted languages give the impression that tasks are being accomplished, but until all code paths are tested, knowing if it is correct is not obvious. Rust like many other typesafe languages (and it’s definitely on the further end of type safe) allow the compiler to detect errors in usage at compile time, well before testing and production usage. Some of us consider this to be more “productive” as it reduces the overall maintenance of the program after it’s released, but YMMV.

jevgeni 6y ago
Best comment in this thread. To the point and factual.
azakai 6y ago
This is an important point. Languages compiled to wasm have an FFI cost, and we will never fully remove it because it just uses different types than Web APIs do. This isn't a Rust problem or a C problem, it's just how wasm is. Wasm also can't use the JS standard library, and usually ends up shipping some runtime support, like malloc or string handling, which increases download size. Both of those limitations are why wasm won't make sense for the great majority of web dev work. But wasm shines for "engine" type code, like in this post - pure computation, without lots of links to the outside JS/DOM world.

lmm 6y ago

ML family languages are so much more productive that that probably outweighs the costs of manual memory management. Rust will always be less productive than Haskell or Scala, but a language with a decent type system is going to have a huge advantage over JavaScript.

tigershark 6y ago
...Haskell and scala are not part of the ML family. OCAML and F# are languages belonging to the ML family.
- lmm 6y ago
  By what definition? Haskell and Scala both have the complete ML featureset (in particular they have sum types and full pattern matching; they're also part of the small group of languages that has typeclasses, which were originally invented for Standard ML) and are on record as being heavily influenced by ML languages (via Miranda in the case of Haskell).
  - tigershark 6y ago
    https://en.m.wikipedia.org/wiki/ML_(programming_language) https://en.m.wikipedia.org/wiki/ML_(programming_language) “Today there are several languages in the ML family; the three most prominent are Standard ML (SML), OCaml and F#. Ideas from ML have influenced numerous other languages, like Haskell, Cyclone, Nemerle, ATS,[citation needed] and Elm.[3]” If you know F#, OCAML, Haskell and scala you can see that the first two have an extremely similar syntax to ML while for the last two the syntax is very different.
    - lmm 6y ago
      If you actually click down to [3] in your own link it says '"these languages" is referring to Haskell, OCaml, SML, and F#'.

Dowwie 6y ago

An experienced Rust programmer will write generally better solutions in roughly the same amount of time as what is taken to write a solution in NodeJS, where the work is familiar. There is absolutely more code to write for a language where you can have fine control over practically everything, as long as it's within the constraints governing the compiler. However, web development consists of well-treaded paths using familiar patterns of data access and manipulation. If a new project does not benefit by code re-use, the experienced Rust programmer is going to have to use more tools and techniques to accomplish something similar in functionality to that created in other languages, but with far more guarantees and control. Who cares about guarantees and control? The team that is going to have to share the burden of maintaining the code you write. With the patterns and libraries used in just this example, you can write a very high performance, memory efficient web server that can handle a large volume of concurrent requests that involve database interactions: https://github.com/actix/examples/tree/master/async_pg https://github.com/actix/examples/tree/master/async_pg All of the work has been consolidated down to a single file for illustration purposes, and it would usually be spread across files. Does it seem like a ridiculous amount of additional work, compared to other languages? I am misleading you some as there is actually a lot more to write the moment we move beyond plain vanilla workflows but this example proves what is possible.