Rust can be difficult to learn and frustrating, but it's also very exciting

Post by user111233 » Sun, Oct 28, 2018, 11:49 PM UTC

ovao wrote: post #128

MaulingMonkey wrote: post #91

Earlier quoted context omitted.

If you could just throw any data into JavaScript functions and have it work, we wouldn't need TypeScript.

One often doesn’t need TypeScript. TS solves some classes of problems that would otherwise become crippling in projects of certain sizes and of certain levels of complexity, but, by design, JavaScript tends to happily let you throw any data into functions and have it work (by some definition of “work”).

If you define work as not throwing an error. You can't just put anything in to a function and have it return a useful result. Thats why typed language programs like haskell programs often define datatypes that are just an Int because user_id is not the same kind of data as product_id even if they are just an int.

Post by nicoburns » Mon, Oct 29, 2018, 1:33 AM UTC

ammaskartik wrote: post #45

nicoburns wrote: post #31

Earlier quoted context omitted.

I think the tokio/async ecosystem just isn't ready for prime time. Hopefully this (and compile times!) get much better.

While compile times can be slow, the rust system is checking so much for you, so that you can have a predictable @scale runtime. What was the issue with tokio? Plus, with async/await Futures coming in soon, already on nightly right, this should become good if not already? Rust went down the Kotlin route of not including coroutines/async/await initially and allowed Lib devs to build, but now have included as we all kn…

Rust is checking a lot, but type checking is not the slow part! (I can usually run cargo check within a couple of seconds max). Rusts LLVM IR output, LLVM, and linking seem to be the main culprits. And I'm hopeful that these can be greatly improved :)

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

Re: Rust can be difficult to learn and frustrating, but it's also very exciting