Live data from Hacker News

Moving from TypeScript to Rust / WebAssembly

nicolodavis.com

331–340 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#331
post #302

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…

> 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. I prefer a different analogy: Rust is high-end automated industrial equipment for machining high-precision metal…

>>But if you're under pressure to build lots of small, partially documented, constantly changing parts every day, you might be better off using more flexible equipment and materials (balsa wood, bailing wire, masking tape, etc.) to get the job done, even if the result will be messier and more prone to breaking.

Python & Deno/Node fit the bill for the latter category. Would you consider Julia in the former or latter category for ML use-cases?

Re: Moving from TypeScript to Rust / WebAssembly

#332

Earlier quoted context omitted.

I’ve worked on several large Ruby codebases, and the thing is, the same qualities that make it easy to get a Ruby project up and working quickly make it a complete nightmare to maintain later. Its expressiveness and malleability mean that you can never really be sure that you understand how code is being used, and the complexity that emerges from a few years of that is incredibly overwhelming. Nowadays I would much r…

I've discovered in large, long-lived Java codebases that it's common to Greenspun expressiveness and malleability back into the language through heavy reliance on things like Spring, stringly typed mechanisms, and dynamic code generation. The impact on maintainability is about what you'd expect. Maybe, on an abstract level, the software isn't as complex as what you can do in Ruby, but the verbosity of the language br…

What I find interesting about dynamism, is that every templating library I’ve ever used has a tendency to become php over time. Even templating libs in php! It’s fascinating to watch, since each new feature really makes sense because certain logic is trivial in the template, that would be way more complicated elsewhere, and so the template lib has pressure to add little things. Next thing you know the complexity and feature set of the lib is it’s own beast to deal with.

Re: Moving from TypeScript to Rust / WebAssembly

#333
post #20

As long as you use a language with a good, static type system, I don't care so much what you use. TypeScript or Rust, for all I care you can transpile Haskell into JavaScript if you feel adventurous. But don't use a dynamically typed language as the source language for anything that is supposed to be more than a simple script.

> But don't use This is just cargo-culting static typing: "If I avoid dynamic typing at all cost, the cargo crates will surely rain on down!" You'll find that picking a language is more of a business decision than the sort of technical static-vs-dynamic checkbox test you might use to pick the language of your next weekendware. This kind of absolutist rule of thumb is more flame bait than morsel of wisdom.

A business decision, what drivel. By that argument, no technical merit of anything ever matters, and yet many things of what’s considered viable in a “business” have changed all the time, some of them because of the push of engineers towards better things.

This is a forum for engineers (not only, I know), who collectively will at least have a large part in steering what languages are considered common in future.

Re: Moving from TypeScript to Rust / WebAssembly

#334
post #333

Earlier quoted context omitted.

> But don't use This is just cargo-culting static typing: "If I avoid dynamic typing at all cost, the cargo crates will surely rain on down!" You'll find that picking a language is more of a business decision than the sort of technical static-vs-dynamic checkbox test you might use to pick the language of your next weekendware. This kind of absolutist rule of thumb is more flame bait than morsel of wisdom.

A business decision, what drivel. By that argument, no technical merit of anything ever matters, and yet many things of what’s considered viable in a “business” have changed all the time, some of them because of the push of engineers towards better things. This is a forum for engineers (not only, I know), who collectively will at least have a large part in steering what languages are considered common in future.

I actually don't pay any attention to what HN considers technically valid. Collective opinion among HNers is often very skewed from the actual reality.

Here is a comment from 9 years ago. It sounds like parody to me and demonstrates how echo chambers eventually deviate from reality. HN can often be an echo chamber

> A good programmer should wake up at 6 am in the morning get a solid 2.5hrs of coding done by 8:30 am, at 8:30 leave for work, work till 6 (it goes without saying that the lunchbreak must be spent trying to learn the Haskell or if you are feeling lazy answering questions on stackoverflow). Commute from 6 to 6:30 (it's a bonus if you listen to a technical podcast during this time and no stuff like TWIT does not count, perhaps audio lectures from the Advanced Algorithms course on MIT OCW). 6:30 to 7:00 time for supper and excellent time to catchup on r/programming and hackernews. 7-8:30pm is the time for relaxation by doing some recreational mathematics, doing problems from project Euler and that proof from The Art of Computer Programming excercises which you have been itching to get a go at! 8:30pm to 1 am code contribute to that open-source project, write patches for the Linux kernal and continue working on your startup.

> Anyone who does less programming that what is mentioned above cannot call himself a "good programmer", I would have serious reservations in calling that person even a mediocre programmer.

--

https://news.ycombinator.com/item?id=2664409

Re: Moving from TypeScript to Rust / WebAssembly

#335
post #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 e…

> JavaScript is cheaper to get started but becomes way more expensive to maintain.

I think this is assumption is a bit too broad. There is another side of this:

In JS you write less code than in Rust and there is less explicit coupling in a dynamic codebase. So changes tend to be smaller and faster as well.

For example if you pass a top-level data-structure X through A, B... and C but only C cares about some part Z. Then you change how Z is produced in A and consumed in C.

If you are dynamic you just do exactly that, which is actually just fine. In a static language you have to change all the B's. Or you take the time and write a sensible abstraction over Z or X so in the future you don't have to change the B's anymore, which is better, but ultimately less readable and more complex.

Stuff that is well understood and specified in advance suits a language like Rust better. You get all these runtime guarantees and performance. You get all this expressive (but explicit!) power to fine-tune abstractions and performance. It's great.

But the closer you get to a UI (especially GUI) and non-technical, direct(!) users, the more dynamic you want to be. Because in this context you are more of a human to computer translator: requirements get discovered via iterations, interactions need to be tested and evolve etc.

Re: Moving from TypeScript to Rust / WebAssembly

#336

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…

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#337
post #259

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…

When I was first learning java I loathed the verbosity, but I was coding everything in vi. Now days with good ides, I don't mind java's verbosity or even the boiler plate.

I find myself more annoyed by dynamic languages, because the tooling just isn't at the same level. All sorts of 'hints' that I rely on in java simply aren't there in other languages, and the ide throws up it's hands and is like '...? I guess this is right? Godspeed sir', and I wind up having to go lookup documentation rather than ctrl clicking into underlying functions and code. It's really annoying, and it's made me be more appreciative of staticly typed languages.

Re: Moving from TypeScript to Rust / WebAssembly

#338

As someone who has (mostly) enjoyed working with Python and JS (CoffeeScript in the past, and ES6+ and TypeScript more recently), and also dabbled in Ruby/Rails, I've been intrigued by Rust for a while. Its promise of being close in speed to C/C++, but safer and more ergonomic, sounds great. I have not attempted to build anything with it yet, but I've looked at what (I think) is enough examples to be familiar with it…

Is Vapor the rails-like go to web framework for Swift? Is it viable for indie hackers, or is it more like Java geared towards the enterprise? I find Swift interesting as a language because it seems that it's well balanced, usable for low level systems programming and higher level applications. But protocol first kinda indicates big design up front, something more geared towards enterprise usecases..

Re: Moving from TypeScript to Rust / WebAssembly

#339
post #46

> webassembly is faster than javascript Everyone says this, but I would dispute it as misleading in a lot of cases. I've been experimenting a lot with wasm lately. Yes, it is faster than javascript, but not by all that much. It's the speed of generic 32 bit C. It leaves a lot to be desired in the way of performance. My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript…

> Yes, it is faster than javascript, but not by all that much. ... My crypto library, when compiled to web assembly, is maybe 2-3x the speed of the equivalent javascript code. 2-3x may not be the 15-16x you see in native code, but it's still a massive speedup in already optimized code, and is likely enough to make a bunch of applications that weren't quite feasible to do in on the web now feasible.

I think the point is only certain use cases (usually related to number crunching like crypto, but undoubtedly games too) may see substantial improvements, they still aren't close to "native" speed, and nearly all other use cases won't see much if any benefit, especially compared to the additional complexity of another language, compiling to was, etc.

Plus things like competitive games and what I'll call "pretty" games have to squeeze out as much performance as possible, and no hitching is acceptable to competitive games, which IMO means WASM is still a no-go for those types of games(although games that don't have this requirement undoubtedly benefit)

Re: Moving from TypeScript to Rust / WebAssembly

#340

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 took the phrase too literally. I'm assuming by won they didn't mean that Ruby and PHP will dominate the web landscape for eternity. I'll just point out that dynamic programming languages have for most of the webs history been the primary tool for developers.
Post reply on HN