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

361–370 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#361

Post by Matthias247 »

loxs wrote: post #115
Matthias247 wrote: post #57

Earlier quoted context omitted.

>> 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. I think even if it is faster in general, you might lose all that advantage as soon as you have to cross the WASM JS boundary and have to create new object instances (and associated garbage) th…

I am writing an app that needs worker threads both on the backend and also on the frontend (because of some heavy processing of large amounts of "objects") and my experience with TS so far is very poor. JS runtimes are just not suitable for heavy concurrent/parallel processing. Serialization/deserialization overhead between threads is probably (much) worse than it would be if the worker threads were in Rust. It's not…

Javascript runtimes do fine with concurrent operations, but obviously are not intended for parallelism.

On the WASM side: Does WASM support real threads yet? Otherwise moving to Rust wouldn't really help you? If it's just "WebWorker" like multiple runtimes, you might still pay serialization costs to move objects between workers.

Re: Moving from TypeScript to Rust / WebAssembly

#362

Post by filleduchaos »

lacker wrote: post #352
filleduchaos wrote: post #102

Earlier quoted context omitted.

> This is only a problem if you are mixing untyped code with typed code, isn't it? I find it a bit strange that people talk about this as "only a problem", as though it was some weird niche edge case and not an ever-present issue. The written-in-plain-JS ecosystem completely dwarfs the written-in-TypeScript one; unless you're doing something rather trivial you're quite likely to end up depending on a library that bar…

You don't have to depend on badly-written untyped third-party libraries, just because there are a lot of them out there. Many projects and companies will avoid doing so. This is especially reasonable if your comparison is switching to a language like Rust; there are probably fewer third-party libraries available in Rust overall than there are libraries with accurate TypeScript definitions available.

"Badly-written" is of course subjective, but as for untyped/loosely typed I think it's a bit difficult to claim that people are avoiding using them when (for example) the typings for an obviously popular library like Express are chock-full of `any` types[0]. Including several (like request bodies) that should instead be `unknown`. I'm sorry but it's rather naïve to expect a beginner to TypeScript, especially one that's coming from JS, to not trip up at all using typings like that and a compiler/language spec that implicitly casts things declared as `any`.

0. https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Re: Moving from TypeScript to Rust / WebAssembly

#364

Post by cygx »

masklinn wrote: post #295
cygx wrote: post #208

Earlier quoted context omitted.

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.

As far as I'm aware, Pascal and Ada were still significant in the early 90s (ie when Python arrived). You're right that they where far less so when PHP entered the picture, but it's not as if they were dead (Borland Delphi and PHP 1.0 were realeased the same year).

Re: Moving from TypeScript to Rust / WebAssembly

#365

Post by eloff »

dnautics wrote: post #325
eloff wrote: post #42

Earlier quoted context omitted.

That it can be done doesn't mean is the optimal approach. I was a diehard fan of dynamic languages for a decade, but eventually I saw the light. I still use dynamic languages daily, but the bigger the project the more I want proper static typing. None of that mypy stuff, the real deal.

You're just using the wrong dynamic programming language. Don't get me wrong type checking, static or otherwise, is useful, but eventually you're going to have to throw in the towel and deal with truly hard problems like distributed systems, which in the end must be dynamic (you cannot safely assume that a node separated by time and space respects the same type system your node does). I have a 20k LOC distributed sys…

That you can't capture all constraints in s type system does not make a type system unnecessary.

You still drive value based on how much of the correctness checking you can offload to the compiler.

I don't really get why programmers better than anyone understand the value of automating work with a computer, but fail to grasp that value applied to their own craft. Let the computer do more of the work in making sure your program is correct.

Re: Moving from TypeScript to Rust / WebAssembly

#366

Post by jes5199 »

thepratt wrote: post #173
jes5199 wrote: post #143

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…

Have you used sorbet on these codebases? I'd be curious if there'd be a benefit here in terms of maintainability.

sorbet is relatively new and I've been avoiding ruby for the last two years

Re: Moving from TypeScript to Rust / WebAssembly

#367

Post by steveklabnik »

RyanGoosling wrote: post #363

If you push Rust to client-side WASM, can it still perform DOM manipulations?

Yes. It has to call out to JS to do so. It's implemented in a way that's forwards-compatible so once wasm can do so natively, your code will just magically get faster.

Re: Moving from TypeScript to Rust / WebAssembly

#368

Post by deltron3030 »

ralmidani wrote: post #347
deltron3030 wrote: post #338

Earlier quoted context omitted.

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

I don't have any statistics, but based on the amount of learning articles, books, etc. out there it seems like Vapor is the dominant Swift Web framework. Kitura looked promising, but IBM has stopped supporting it, so its future is not clear (the last commit to the main branch was in November 2019). Also, the two main Vapor devs are members of the Swift Server Work Group (with the other two being from Apple): https://…

Thanks for your answer. So Vapor for building APIs, not web monoliths, good to know. It kinda makes sense considering that most of the users will use mobile apps on the client side.

Personally I also find Elixir and the Phoenix framework very interesting.

Re: Moving from TypeScript to Rust / WebAssembly

#369

Post by [deleted] »

vorpalhex wrote: post #301
entha_saava wrote: post #141

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.

You realize the web started with just HTML at first right? The web was always meant to be a platform anyone could easily build on, whether they were experts or someone's little old grandma who barely knew what a keyboard was. Not only is it gatekeeping, it's historically wrong and betrays a flawed understanding of the platform. The web has always been about ease of use and there have always been people who went out o…

[deleted]

Re: Moving from TypeScript to Rust / WebAssembly

#370

Post by ralmidani »

deltron3030 wrote: post #368
ralmidani wrote: post #347

Earlier quoted context omitted.

I don't have any statistics, but based on the amount of learning articles, books, etc. out there it seems like Vapor is the dominant Swift Web framework. Kitura looked promising, but IBM has stopped supporting it, so its future is not clear (the last commit to the main branch was in November 2019). Also, the two main Vapor devs are members of the Swift Server Work Group (with the other two being from Apple): https://…

Thanks for your answer. So Vapor for building APIs, not web monoliths, good to know. It kinda makes sense considering that most of the users will use mobile apps on the client side. Personally I also find Elixir and the Phoenix framework very interesting.

No problem! Vapor does have its own template system if you don't want to build "just" an API: https://github.com/vapor/leaf

I have also looked at Elixir and Phoenix, but have not written any code in them. I have yet to really dive into anything outside the C-like languages (Python, JS, Java, Swift, Ruby, C, C++), and Elixir seems like a good reason to venture outside my comfort zone.

By the way, no pressure, but if you ever want to discuss Swift, maybe do some paired programming/studying, let me know. I'm still fairly new but I have experimented with building a Swift-to-CSS DSL that I would like to eventually spend more time on. If you want to email me, ragheed.almidani is the name, and protonmail.com is the domain.

Post reply on HN