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

341–350 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#341

Post by _bxg1 »

MaxBarraclough wrote: post #241
chjj wrote: 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…

I'd be interested to see how current-day WASM stacks up against current-day Java. Don't suppose you've ported your crypto code to Java? Other than the maturity of the JIT compilers, are there reasons we should expect WASM to be any slower?

In some ways it should be faster because it isn't garbage-collected. But I agree that would be a much better benchmark for what should be possible.

Re: Moving from TypeScript to Rust / WebAssembly

#343

Post by tome »

memexy wrote: post #334
anyfoo wrote: post #333

Earlier quoted context omitted.

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

> Here is a comment from 9 years ago. It sounds like parody to me

It is a parody, isn't it?

Re: Moving from TypeScript to Rust / WebAssembly

#344

Post by nikki93 »

chjj wrote: 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…

Another consideration here is that you can use languages that offer control over data layout as a natural feature, which can matter a lot for good cache utilization etc. In many cases the data layout matters a lot for performance.

You can do this in JS too with TypedArray and whatnot but the key word here is 'natural.'

I've been working on a game engine as a side project with C++ and WASM -- and there are already many improvements over what I was getting with JS due to less GC, better data layout (the data layout thing is also esp. helpful for managing buffers that you drop into the GPU). I don't think it was about 'pure compute' as much as these things. C++ and Rust give you tools to manage deterministic resource utilization automatically which really helps.

A bonus is that the game runs with the same code on native desktop and mobile.

Re: Moving from TypeScript to Rust / WebAssembly

#345

Post by cs702 »

otoburb wrote: post #331
cs702 wrote: post #302

Earlier quoted context omitted.

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

For ML/scientific computing, it can fulfill both roles, I'd say. Julia looks about as flexible and easy to use as Python, R, and matlab for experimenting and iterating quickly with throwaway code, and superior to those languages in every other important dimension except one: it lacks Python's gigantic ecosystem.

Re: Moving from TypeScript to Rust / WebAssembly

#346

Post by memexy »

tome wrote: post #343
memexy wrote: post #334

Earlier quoted context omitted.

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

> Here is a comment from 9 years ago. It sounds like parody to me It is a parody, isn't it?

Yes, it is. But it makes a valid point about HN and the elevation of technical prowess over other concerns. It points out the danger of using an echo chamber as a gauge for reality.

I don't use technical recommendations from HN users because they consistently underestimate pragmatic concerns because the HN echo chamber overvalues technical virtuosity so real world pragmatic concerns get drowned out by other voices.

Re: Moving from TypeScript to Rust / WebAssembly

#347

Post by ralmidani »

deltron3030 wrote: post #338
ralmidani wrote: post #323

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

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://swift.org/server/

I'm not sure how to answer your question regarding whether Vapor is viable for indie hackers, because I've only been skimming the docs and looking at small examples. But it seems to draw a lot of inspiration from Express.js and/or Ruby's Sinatra library. It doesn't seem to have the up-front complexity of something like Java's Spring Framework, although I understand you can use services and dependency injection if needed. So my first impression is it's easy to get started, but it enables you to refactor to something more complex if your application demands it.

Re: Moving from TypeScript to Rust / WebAssembly

#348

Post by pjmlp »

aphextron wrote: post #67
hardwaregeek wrote: post #29

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…

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…

Depends what one considers application level web development, over here it has been pretty much Java and .NET, with occasional C and C++ written libraries, during the last 20 years.

Re: Moving from TypeScript to Rust / WebAssembly

#349

Post by LandR »

swebs wrote: post #256
tracker1 wrote: post #218

Earlier quoted context omitted.

Why can't you use C#? .Net Core (upcoming .Net 5) are pretty decent to work with. I'd still rather use node for the most part though. I have been playing with Rust, but not sure about how good an idea it is for the front end yet though.

Pretty sure the parent comment was talking about client side.

You can use C# on the front end now with Blazor. It's pretty new though so I don't know how good it is yet.

Re: Moving from TypeScript to Rust / WebAssembly

#350

Post by pjmlp »

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.

Yeah, the problem is that the large majority of the world isn't Google, software isn't their main business, and their codebases are maintained by a continuous rotation of external contractors that are paid by the tickets that they get to implement.
Post reply on HN