Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

Post reply on HN
Print view View original

271–280 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#271

Post by steveklabnik »

zozbot234 wrote: post #191
codemac wrote: post #78

Earlier quoted context omitted.

As a complete noob to rust, I found attempting to manage a memory pool that is handed out per request to cause all kinds of borrow checking headaches. My bet is people choose to allocate heavily rather than figure out how to share memory correctly with Rust. I need to learn more rust to get a hang of it so I don't allocate so much. Are there any rust folks who have a great "list of memory management models for rust"?

Rust does not yet have local custom allocators ala C++. (You can change the global allocator, but this doesn't help the "memory arena" use case.) The feature is very much on the roadmap, though.

While this is true, this doesn't inherently mean you can't do this pattern. https://crates.io/crates/typed_arena for example. It depends on exactly how allocations and your data structure are tied together.

Re: Moving from TypeScript to Rust / WebAssembly

#272

Post by peterholcomb »

colmvp wrote: post #259
rubber_duck wrote: post #248

Earlier quoted context omitted.

b, to_s, to_i, to_a, to_c, to_h, to_r, etc. Should have said methods but you get what I mean. And I've encountered ambiguous and pointless abbreviations all over the place.

It's weird, when I was I younger I used to love shortform syntax like that as well as removing unnecessary punctuation But now that I'm older, I appreciate things being more descriptive and orderly, including strict use of semicolons, functions that say what they are doing (e.g. to_string), or being explicit about converting (e.g. static_cast ) I think it's because I find trying to make everything as succinct as poss…

Well said. "Clean Code" goes into this a lot and it helped me realize why I was starting to become more and more bothered by looking back at the short variable names I wrote years ago on my projects.

Re: Moving from TypeScript to Rust / WebAssembly

#274

Post by Dowwie »

rubber_duck wrote: post #175
aphextron wrote: post #67

Earlier quoted context omitted.

This really nails why languages like PHP and Ruby have won out over static typed, compiled ones for application level web development. The web is a massive collection of disjointed, loosely coupled APIs that all (just barely) interoperate to provide a massive array of functionality. Languages that tend to work well with it are those that are highly flexible around the corner cases of these technologies, and allow you…

Won ? Ruby fell off a cliff once it got to a point where people had to maintain that shit in production - I'm currently working on a large mature RoR codebase and I'm switching jobs ASAP because it's incredibly painful to work with and feels like a dead end career wise - and I like the gig otherwise - good product and a decent team - but the technology is draining so much of my life energy on nonsense it's ridiculous…

I think you would really appreciate Rust for backend web dev. Quite a few people who were once upon a time hardcore rubyists gravitated to Rust and became some of its greatest contributors: Steve K., Sean G., Carl L., Florian G., and many more.

Re: Moving from TypeScript to Rust / WebAssembly

#275

Post by gen220 »

cmrdporcupine wrote: post #265
wwright wrote: post #225

Earlier quoted context omitted.

I say this a lot, but if you are this irritated by Rails, then you ought to see the 20+ year old legacy C/C++ some of us get to work with ;)

This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.

This is, IMO, one of the most underrated aspects of the monorepo, that has such a valuable impact over time.

It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.

Re: Moving from TypeScript to Rust / WebAssembly

#276

Post by SAI_Peregrinus »

colmvp wrote: post #259
rubber_duck wrote: post #248

Earlier quoted context omitted.

b, to_s, to_i, to_a, to_c, to_h, to_r, etc. Should have said methods but you get what I mean. And I've encountered ambiguous and pointless abbreviations all over the place.

It's weird, when I was I younger I used to love shortform syntax like that as well as removing unnecessary punctuation But now that I'm older, I appreciate things being more descriptive and orderly, including strict use of semicolons, functions that say what they are doing (e.g. to_string), or being explicit about converting (e.g. static_cast ) I think it's because I find trying to make everything as succinct as poss…

I type fast enough that somewhat longer names don't hurt. Also tab completion has existed both in IDEs and in shells for many years now. But just like very nearly everyone else I fall into the "7 ± 2 items in working memory at once" capability range. Having to remember what a command/function/syntax element does instead of reading a word that says what it does takes away from that working memory.

Long-term memory is similar, while it's not bounded in the same way it takes time and effort to develop. I'd rather type `git new-branch` than have to remember `git checkout -b` and I certainly don't alias it to `git nb` or something: I can type `git n` and let that complete it.

Re: Moving from TypeScript to Rust / WebAssembly

#277

Post by steveklabnik »

zozbot234 wrote: post #206
hombre_fatal wrote: post #32

Earlier quoted context omitted.

When you're writing synchronous, single-threaded code like, say, a binary file parser or even an HTML scraper with blocking APIs, Rust is 1:1 with high level languages, and usually better. Where Rust diverges is when you're doing async or multithreaded things with complicate lifetimes. Getting things right from the start instead of solving them JIT as runtime issues pop up in production over the course of the year is…

> But even after using Rust for three years, I sometimes feel like I'm one requirement-change away from a problem I can't solve myself in Rust where I could solve it in a couple hours in another language. Rust does have these sorts of issues wrt. managing highly generic graph-like data, possibly with cycles. That's where tracing GC actually shines, and where writing that whole portion separately in something like Go…

That is true if you have to write your own. 99.99% of the time, if you need a graph, you use petgraph and move on with life.

Re: Moving from TypeScript to Rust / WebAssembly

#278

Post by steveklabnik »

jfkebwjsbx wrote: post #263
connicpu wrote: post #26

Earlier quoted context omitted.

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…

> - In your average Rust project, all dependencies are already built from source That is only the case for open source code like crates.io, there is nothing that guarantees you will get the source code of a third-party, though. I mention this because in the native world it is common to give customers precompiled libraries. > - Already using LLVM as the compiler backend Some people don't seem to know this, but all lan…

> all languages that target LLVM (including C, C++, Fortran, Ada, Julia, Swift and others) can be used in WebAssembly.

Having LLVM doesn't mean that webassembly Just Works, in the same way that having LLVM doesn't mean that all of its architectures Just Work. And even after getting past the "hello world" stage, there's a lot of other work to do to make it more than just a toy.

Let's take Ada, for example. https://blog.adacore.com/use-of-gnat-llvm-to-translate-ada-a... talks about how to use Ada to build stuff for wasm, but you need to include https://github.com/godunko/adawebpack/ to make things work well. Someone had to write that code.

Re: Moving from TypeScript to Rust / WebAssembly

#279

Post by dljsjr »

pas wrote: post #209
laurencerowe wrote: post #50

Earlier quoted context omitted.

For backend web development I was somewhat disappointed to see that many of the new web frameworks (all async) allocate extensively on the heap (for example lots of Strings in their http request types.) I mean it works but I don't understand why I would go to the bother of thinking about lifetimes when it seems performance would be similar to Kotlin / Swift / F#.

The short answer is that because async is not done yet in Rust. The long answer probably includes GATs (generic associated types), and the even longer answer starts with the amazing work that Nico et al. does to reinvent the internals of the Rust type checker. (Basically - if I remember correctly - the compiler team is currently refactoring big parts of rustc, to librarify the type checker, and replace it with a PROL…

Can I ask what you mean when you say that async isn't done? async/await and Futures are on stable now. There is no runtime in the core/std but that's by design, there is no short term intent from the Rust team to do that. Tokio and async-std are both fairly usable as well.

Re: Moving from TypeScript to Rust / WebAssembly

#280

Post by randall »

gen220 wrote: post #275
cmrdporcupine wrote: post #265

Earlier quoted context omitted.

This is one nice thing about working at Google. We have C++ codebases that are 20 years old, but you'd never be able to tell because they are still continuously worked on and even if not there's a team of people at Google who constantly run company-wide refactorings and the like to modernize things.

This is, IMO, one of the most underrated aspects of the monorepo, that has such a valuable impact over time. It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.

Ya, fb feels the same way fwiw. I'm very sold on the benefits of monorepos now.
Post reply on HN