Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

181–190 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#181

Earlier quoted context omitted.

> This really nails why languages like PHP and Ruby have won out over static typed ... Real reason is lowering the bar of entry, and that explains why web is horribly broken. The "bootcamp webshit" meme exists for a reason. That's not gatekeeping - lowering the bar to entry below a certain level leads to drastic decrease in quality.

A lot of it is affordances. Every function signature is a user interface for your fellow programmer. And if you are used to poorly-designed UI, you will expect poorly-designed UI from yourself.

Less testing, Documentation, Guarding against typos, better IDE support, better performance;

But there is a whole new generation of web developers who don't bother to learn algorithms or low level programming, and just churn out code with that hot new framework. That kind of programmers are also the ones that choose a technology because "it looks easier".

The world would be nice if management people understood not all programmers are equal, the 10x programmer is not a myth. But here on HN or reddit you see most people arguing that all programmers are similarly productive. And what we get for this is more electron apps.

Re: Moving from TypeScript to Rust / WebAssembly

#182
post #2

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.

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 abi…

Best comment in this thread. To the point and factual.

Re: Moving from TypeScript to Rust / WebAssembly

#183
post #71

Earlier quoted context omitted.

This is the fallacy of the grey. Yes, there are nuances and special circumstances, but the overwhelming majority of the time, static typing is simply better. That's one of a small handful of clear consensuses from the last 20-30 years of programming language evolution.

It's not any better if business trade-offs make another decision better. You don't have "all things equal" trade-offs in the real world. Want an easy concrete example? You and your cofounder have 10 years of Ruby experience and investors/customers who want a product yesterday. Or the deliverable that makes most sense is a PHP script that users can drag into CPanel because that's your customer base. The tinkerer insid…

> Want an easy concrete example? You and your cofounder have 10 years of Ruby experience and investors/customers who want a product yesterday. Or the deliverable that makes most sense is a PHP script that users can drag into CPanel because that's your customer base.

True but facile. Sure, for every imaginable technology, there is a conceivable scenario in which that technology is the right choice. Doesn't mean there's no such thing as a good or bad technology.

> The tinkerer inside you always wants to try new things and convince you that some greener tech on the other side of the fence are going to make the difference. It's usually just procrastination from the actual hard stuff: building things people want, today.

That's actually an argument for being more absolutist about the technical side: you're unlikely to be in the obscure circumstances where a dynamic language would actually be helpful, and even more unlikely to have that be more important than your business decision. So rather than carefully considering your circumstances and weighing up the tradeoffs, it's better to follow the consensus for what's a good general-purpose language (which these days means a statically typed language) and get on with building your business.

Re: Moving from TypeScript to Rust / WebAssembly

#184
post #100

Earlier quoted context omitted.

I don't totally agree about its strengths not being relevant. Memory safety is an extremely low bar that the web has generally managed to meet, but Rust has a lot of value elsewhere. The author talks about significant performance improvements, which would be very welcome on many sites, as well as improved error handling and data validation patterns.

Most things thank goodness are not SPAs, nor do they have to be. The problem here is the concept of SPA itself - it's a complete hack which is plastered over with various tricks to make it halfway usable. This has been going on for years now. Websites on the other hand are slow because of the tracking and the ads which load tons of JS. Remove that and the web will be blazing fast.

> Remove that and the web will be blazing fast.

With sufficient ad blocking and JS white listing, I can attest to this.

After removing ads and analytics, sites that rely on JavaScript to render significant amounts of content are the slowest.

Re: Moving from TypeScript to Rust / WebAssembly

#185

Earlier quoted context omitted.

I think you get it backwards. Things are disjointed, loosely coupled because highly dynamic languages have won. The flexibility of dynamic languages, which can be great when working around dynamic corner cases, does not force developers into fixed, well-defined contracts keeping everything loose and disjoint. PHP is highly to blame. PHP, being a scripting language, is easy to deploy and keeps chugging along at all co…

Applying a schema doesn’t fix an architecture problem. Describing those fixed well defined contracts on top of the architurally absurd stack that is TCP/DNS/TLS/HTTP/Ajax/Dom/JS engine/Server side graphql/rpc/rest / database... doesnt by you anything but slower iteration speed and an unwieldy schema. These components don’t have the same impedance, the same flavour to their design. Necessarily their schema would be a…

> Also, what stops something like [defining add as subtraction]

cmon... "it doesn't guard you against every logic error under the sun" isn't a great argument

Re: Moving from TypeScript to Rust / WebAssembly

#186

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…

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#187

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…

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

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#188

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…

It's still a significant upgrade over JavaScript. I'm developing a web app with the Backend in Rust and Front-end in Vuejs/JavaScript. Sure Rust was slower to develop, but it doesn't throw errors like 'val in undefined' and then I have to go debugging where I check for the value of val. You do that beforehand on Rust and that avoid a whole class of problems.

JavaScript is cheaper to get started but becomes way more expensive to maintain. My Rust code on the other hand: Once it works it keeps working. If it compile it probably won't bug down the road.

I'd switch to Rust / WebAssembly once the libraries are mature/stable/documented enough. The overhead cost is worth it in the long run.

Re: Moving from TypeScript to Rust / WebAssembly

#189

Keep in mind that WebAssembly is not a silver bullet for performance, and carefully crafted JS application (written in engine-friendly way) will perform roughly the same or even better than its WA equivalent. I've rewritten chunk of my math-intensive app in AssemblyScript half a year ago - it took me about a month to fight through all the compiler bugs, I used every optimization possible (used floats everywhere, disa…

That's pretty interesting. Could you share you project? There are benchmark which compare JavaScript and AssemblyScript: https://github.com/nischayv/as-benchmarks https://github.com/nischayv/as-benchmarks/issues/3#issuecomm...

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#190

Earlier quoted context omitted.

A lot of it is affordances. Every function signature is a user interface for your fellow programmer. And if you are used to poorly-designed UI, you will expect poorly-designed UI from yourself.

Less testing, Documentation, Guarding against typos, better IDE support, better performance; But there is a whole new generation of web developers who don't bother to learn algorithms or low level programming, and just churn out code with that hot new framework. That kind of programmers are also the ones that choose a technology because "it looks easier". The world would be nice if management people understood not al…

> the 10x programmer is not a myth

You are right that quality of programmer skill and productivity has high variance, but the way people talked about the "10x programmer" was a vague vision that people pasted their ideas and personal bugaboos onto. So people got into increasingly-heated arguments and talked past each other. When we create social concepts, we need to strive for something like falsifiability -- something that lets you look at an example and say "Well actually no, thats not 'high-performing programmer' behavior -- for {{describable reason}}"

Categories matter. We should shape our categories for human happiness and human effectiveness, but categories matter.

Post reply on HN