Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

291–300 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#291
post #290

Earlier quoted context omitted.

The team itself described the stabilization of async/await as being in an "MVP" state. Stuff that's been fixed since then: * error messages (I think there may be more to do, but they're better and better all the time) * size of tasks (Still more to do, but they've shrunk a lot since it was first implemented * async/await on no_std (initial implementation used TLS to manage some state, that's since been fixed) Stuff s…

Huh! Thanks for chiming in and that's good to know! Side note, I just want to say that I have mad respect for you always finding a way to stay so positive while continuing to be so heavily involved with the community, even with job changes and all of that stuff going on. You're an absolute role model for how to participate in community management and a godsend for Rust.

Thanks. It has taken a ton of work, frankly. I made a conscious decision to try and improve in this way a while back, and while I'm not perfect at it, I'm glad that I'm moving in that direction.

Re: Moving from TypeScript to Rust / WebAssembly

#292

Whenever I write Rust, I have a lot of fun, but I'm still not sold on it for most web dev. The analogy that comes to mind is that Rust is a really nice sports car with a great engine. It handles like a dream and you can feel the powerful engine humming while driving it. With the right open road, it's a great time. You can really optimize code, make great abstractions and work with data easily. Unfortunately, web dev…

You might enjoy this blog post I wrote: http://kyleprifogle.com/churn-based-programming/

It would be even more enjoyable if the text was black, had to use reader mode.

Re: Moving from TypeScript to Rust / WebAssembly

#293

Earlier quoted context omitted.

You might enjoy this blog post I wrote: http://kyleprifogle.com/churn-based-programming/

It would be even more enjoyable if the text was black, had to use reader mode.

Disadvantage of retina screens, I didn't even realize. Thanks for pointing out, i'll fix.

Re: Moving from TypeScript to Rust / WebAssembly

#294
post #274

Earlier quoted context omitted.

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.

I like Rust a lot - especially since I have a C++ background - unfortunately I don't see any opportunities to move to it ATM, but I haven't really tried hard enough - maybe I'll take a month off after my current project to write something substantial in it and try to find a Rust gig.

Re: Moving from TypeScript to Rust / WebAssembly

#295
post #208

Earlier quoted context omitted.

> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously usef…

because the representatives of statically typed languages at the time were Java and C++ And Pascal, Ada, Haskell, Eiffel, Standard ML, ...

Operative concept: representative.

None of the language you mention had any sort of wide-spread visibility at that time, meaning they were not representative of the (overwhelming) majority experience with statically typed languages.

Re: Moving from TypeScript to Rust / WebAssembly

#296

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.

I've got a large codebase i've been maintaining since 1999 that i've continued to evolve and is still in use today . I've been able to steadily improve it without breaking much. IDK maybe its being > 50 but I can appreciate less "dynamic" environments. I do we dev in vue with a go back end but I know the vue part is going to be a rewrite in 5 years. Who wants to keep doing that shit? not this 52 year old guy.

Re: Moving from TypeScript to Rust / WebAssembly

#297
post #105

I will only nitpick on the part about TypeScript not being type-safe enough, where extra fields are possible or wrong types can be sent over the wire. io-ts [0] completely solves this issue, to the point where I don't think it's less type-safe than Rust in any practical manner. I've been writing apps in TS this way for the past year and I have quite a large codebase in production. The errors you mention do not happen…

I love things like this, but at the same time when I look at the API this library provides, it's not junior-friendly. Even though I acknowledge it solves some problems I'd like to solve, if I put code using this library infront of a junior developer, they'd be paralaysed, and at best, if they weren't, write code with it that another junior wouldn't understand. That makes it difficult for me to justify introducing it.

That's not an unreasonable concern but it does mean you're writing code targeting the lowest common denominator. That's not a decision free from negative consequences.

Re: Moving from TypeScript to Rust / WebAssembly

#298

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#.

Rust never has to run a garbage collector, because it already figured out the lifetimes of all the values in your program statically, with relatively minor help from the programmer. This may make your code faster or more likely to be correct than code written in some of those languages.

I don't think you've understood the nature of the borrow checker in Rust. It doesn't add any extra runtime behaviour, in fact you could compile Rust code without running these checks (though I don't think rustc provides you with a way to do so). Rust's memory management tools are no different from C++: you have stack allocated structures with destructors, which the standard library uses to implement heap-allocated smart pointers, shared pointers, mutex guards, etc, and you can hand out pointers to any of these. The only difference in rust is it checks how these pointers get handed out so you don't get use-after-free, data races, etc.

Re: Moving from TypeScript to Rust / WebAssembly

#299
One thing articles like this always miss, and what I'm most keen on, is how exactly the bridging works. Is there a standard Rust wasm crate that exposes the DOM? Do you pass some struct with function pointers? Is the Rust code exposed as a black box with no connection to the outside world and you just call a few entrypoint functions? Can you call Rust from JS and JS from Rust? If you go JS->Rust->JS->Rust->JS and the innermost JS function throws an exception, is all that properly propagated up the stack?

Re: Moving from TypeScript to Rust / WebAssembly

#300

Earlier quoted context omitted.

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…

PHP is definitely not a meme, it's got a ton of actively developed frameworks, PHP 7 was a huge step forward for the language and PHP 8 is shaping up to be as well. It's been used at every workplace I've been at, sometimes well, sometimes not so well, just like any language. No idea what the point of blanket statements like this is.

Especially when said statements are just wrong. Anecdotal evidence from individual companies does not allow you to make representative statements about the entire internet...

https://w3techs.com/technologies/details/pl-php claims ~79% of websites whose backend is known use PHP.

https://w3techs.com/technologies/details/pl-ruby shows Ruby has grown from 2.5-3.5% over the last year.

Post reply on HN