5 ms·

I'll do just about anything to avoid JavaScript, including learning Rust.

by fmakunbound 6y ago

alpineidyll3 6y ago
You read my mind.
thealienthing 6y ago
I can only imagine how many JS diehard fans are screaming in rage when they read this. I’m with you.
- ahmedalsudani 6y ago
  All three of them :) Mostly there are diehard haters for JS, not diehard fans. A lot of people who use JS are pragmatists and fantastic problem solvers that I have a ton of respect for. -Someone who's not too fond of JS
  - shepherdjerred 6y ago
    I used to be a die-hard hater but converted to a die-hard fa n when I started actually learning the language. Once you know the quirks it's quite nice. Of course since it's dynamically typed it's hard to use for larger programs, but TypeScript solves that.
- gwbas1c 6y ago
  I took the time to learn some modern JavaScript and I love it... But give me a statically typed compiled language any day! The browser is so important that we shouldn't be locked into using a single language, so I fully support being able to choose between Rust or a JavaScript!
nobleach 6y ago
While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes, I really just want to read a CSV and create a Map<String, String> from a few of the columns. But oh my god if Rust doesn't make that a nightmare. Is it a String? an &str? Do I want to allocate that string on the stack? I won't know the size of it at compile time, so of course not... right? So no to 'static? Give me a nice middle of the road like TypeScript, Kotlin, OCaml/Reason... Rust just goes SO FAR in the other direction that I don't find it a pleasant experience. I get that it's the ULTIMATE in performance, I just always question if I really need it for doing web work.
- crazypython 6y ago
  Dlang let's you write GC code at first-- let's you allocate a string however you want-- and later convert that into @nogc code, or into GC code with manual deletions. The generational garbage collector will help with deleting strings. Best of both worlds-- fast prototyping, with the ability to drop down for faster code. Furthermore, like interpreted languages, Dlang compiles very fast because the language implementers believe fast compilation is a core goal.
  - eloff 6y ago
    I always rather thought D had a lot of good ideas. But it hasn't caught on, and I don't see that changing. If you can't get a job in it ( comparatively), can't find quality libraries for common tasks, and don't have a large user base running into painful edge cases before you do, it's going to be a rough ride.
- kgraves 6y ago
  To me this is a non issue here, I find Rusts strings far easier than many other languages. (and also safer) Overtime this knowledge becomes second nature to get used to and less of a pain point to grok.
- bluejekyll 6y ago
  Rust wants the things that are expensive to be obvious. Going from &str to String allocates, so that requires an upfront conversion before use. On the other-hand String has a Deref impl to &str, so you can call any method defined on &str directly from a variable of type String. That doesn’t require any cast, and those methods can be called directly on the variable making it very easy. To me this feels like a good trade off in ergonomics vs. performance.
- Yxven 6y ago
  I think this Rust complaint is just inexperience. You wanted a Map<String, String>, and that's exactly what you should have made. A String is a convenience wrapper for storing a &str on the heap, so storing a String on the heap is redundant. The other options are for performance concerns, which you haven't mentioned any.
marcosdumay 6y ago
I'll fight the lifetime analysis with a smile if it means avoiding the null reference errors that happen all the way across the code and the bad type conversions causing all kind of user visible issues.
gitgud 6y ago
Watch out, it will be trans-piled to JavaScript, so there's a chance you might be learning it while debugging!
- coder543 6y ago
  WebAssembly is not JavaScript. This code does not transpile to JavaScript. There might be some JavaScript glue code to call the WASM that's bundled into the website, but that's not what your comment is claiming.
  - gitgud 6y ago
    Whoops was a bit misleading in hindsight. I was just trying to be facetious, but yes you're right "WebAssembly is not JavaScript"
heavyset_go 6y ago
Now that there are viable options for Rust via WASM, I'm actually excited to work on the front end. TypeScript feels the same way that CoffeScript did 6 years ago: it's a stopgap measure until JavaScript picks up the transpiled language's good features. Also, it's another layer on top of the already unruly JavaScript toolchain. In comparison, Rust and its toolchain are pleasures to work with. I wouldn't choose to use TypeScript unless there is an explicit requirement to use JavaScript.
AlexITC 6y ago
Try scala-js [1], there is a nice side-by-side [2] comparison with JavaScript, but with a powerful compiler behind. [1]: https://www.scala-js.org https://www.scala-js.org [2]: https://www.scala-js.org/doc/sjs-for-js/ https://www.scala-js.org/doc/sjs-for-js/

I'll do just about anything to avoid JavaScript, including learning Rust.

alpineidyll3 6y ago

You read my mind.

thealienthing 6y ago

I can only imagine how many JS diehard fans are screaming in rage when they read this. I’m with you.

ahmedalsudani 6y ago
All three of them :) Mostly there are diehard haters for JS, not diehard fans. A lot of people who use JS are pragmatists and fantastic problem solvers that I have a ton of respect for. -Someone who's not too fond of JS
- shepherdjerred 6y ago
  I used to be a die-hard hater but converted to a die-hard fa n when I started actually learning the language. Once you know the quirks it's quite nice. Of course since it's dynamically typed it's hard to use for larger programs, but TypeScript solves that.
gwbas1c 6y ago
I took the time to learn some modern JavaScript and I love it... But give me a statically typed compiled language any day! The browser is so important that we shouldn't be locked into using a single language, so I fully support being able to choose between Rust or a JavaScript!

nobleach 6y ago

While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes, I really just want to read a CSV and create a Map<String, String> from a few of the columns. But oh my god if Rust doesn't make that a nightmare. Is it a String? an &str? Do I want to allocate that string on the stack? I won't know the size of it at compile time, so of course not... right? So no to 'static? Give me a nice middle of the road like TypeScript, Kotlin, OCaml/Reason... Rust just goes SO FAR in the other direction that I don't find it a pleasant experience. I get that it's the ULTIMATE in performance, I just always question if I really need it for doing web work.

crazypython 6y ago
Dlang let's you write GC code at first-- let's you allocate a string however you want-- and later convert that into @nogc code, or into GC code with manual deletions. The generational garbage collector will help with deleting strings. Best of both worlds-- fast prototyping, with the ability to drop down for faster code. Furthermore, like interpreted languages, Dlang compiles very fast because the language implementers believe fast compilation is a core goal.
- eloff 6y ago
  I always rather thought D had a lot of good ideas. But it hasn't caught on, and I don't see that changing. If you can't get a job in it ( comparatively), can't find quality libraries for common tasks, and don't have a large user base running into painful edge cases before you do, it's going to be a rough ride.
kgraves 6y ago
To me this is a non issue here, I find Rusts strings far easier than many other languages. (and also safer) Overtime this knowledge becomes second nature to get used to and less of a pain point to grok.
bluejekyll 6y ago
Rust wants the things that are expensive to be obvious. Going from &str to String allocates, so that requires an upfront conversion before use. On the other-hand String has a Deref impl to &str, so you can call any method defined on &str directly from a variable of type String. That doesn’t require any cast, and those methods can be called directly on the variable making it very easy. To me this feels like a good trade off in ergonomics vs. performance.
Yxven 6y ago
I think this Rust complaint is just inexperience. You wanted a Map<String, String>, and that's exactly what you should have made. A String is a convenience wrapper for storing a &str on the heap, so storing a String on the heap is redundant. The other options are for performance concerns, which you haven't mentioned any.

marcosdumay 6y ago

I'll fight the lifetime analysis with a smile if it means avoiding the null reference errors that happen all the way across the code and the bad type conversions causing all kind of user visible issues.

gitgud 6y ago

Watch out, it will be trans-piled to JavaScript, so there's a chance you might be learning it while debugging!

coder543 6y ago
WebAssembly is not JavaScript. This code does not transpile to JavaScript. There might be some JavaScript glue code to call the WASM that's bundled into the website, but that's not what your comment is claiming.
- gitgud 6y ago
  Whoops was a bit misleading in hindsight. I was just trying to be facetious, but yes you're right "WebAssembly is not JavaScript"

heavyset_go 6y ago

Now that there are viable options for Rust via WASM, I'm actually excited to work on the front end. TypeScript feels the same way that CoffeScript did 6 years ago: it's a stopgap measure until JavaScript picks up the transpiled language's good features. Also, it's another layer on top of the already unruly JavaScript toolchain. In comparison, Rust and its toolchain are pleasures to work with. I wouldn't choose to use TypeScript unless there is an explicit requirement to use JavaScript.

AlexITC 6y ago

Try scala-js [1], there is a nice side-by-side [2] comparison with JavaScript, but with a powerful compiler behind. [1]: https://www.scala-js.org https://www.scala-js.org [2]: https://www.scala-js.org/doc/sjs-for-js/ https://www.scala-js.org/doc/sjs-for-js/