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

141–150 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#141

Post by entha_saava »

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…

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

Re: Moving from TypeScript to Rust / WebAssembly

#142

Post by tigershark »

lmm wrote: post #95
tigershark wrote: post #83

Earlier quoted context omitted.

...Haskell and scala are not part of the ML family. OCAML and F# are languages belonging to the ML family.

By what definition? Haskell and Scala both have the complete ML featureset (in particular they have sum types and full pattern matching; they're also part of the small group of languages that has typeclasses, which were originally invented for Standard ML) and are on record as being heavily influenced by ML languages (via Miranda in the case of Haskell).

https://en.m.wikipedia.org/wiki/ML_(programming_language)

“Today there are several languages in the ML family; the three most prominent are Standard ML (SML), OCaml and F#. Ideas from ML have influenced numerous other languages, like Haskell, Cyclone, Nemerle, ATS,[citation needed] and Elm.[3]”

If you know F#, OCAML, Haskell and scala you can see that the first two have an extremely similar syntax to ML while for the last two the syntax is very different.

Re: Moving from TypeScript to Rust / WebAssembly

#143

Post by jes5199 »

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…

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 rather slog through ten times as much Java boilerplate, because later I’d expect that I could still refactor code without fearing that the whole thing would collapse around me

Re: Moving from TypeScript to Rust / WebAssembly

#144

Post by irjustin »

friendzis wrote: post #135
aphextron wrote: post #67

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…

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…

I agree with both of you in that I don't think the direction of the origin really matters.

The problem is when dealing with other teams/products/api's it's a mess. Varying standards, varying strictness, corner cases everywhere. There are plenty of JAVA, ASP.Net APIs that are absolute nightmares to integrate with despite being strictly typed beginnings.

If you have a highly federated space, you control everything and thusly can do cool things like Rust, Lua, what have you. But, most engineers don't get such a luxury. Languages that can be rapidly morphed to accommodate all those situations achieve shipped solutions to business problems faster.

In the end, that makes money and that turns our world.

Regardless, here's the loosely related XKCD's Standards: https://xkcd.com/927/

Re: Moving from TypeScript to Rust / WebAssembly

#145

Post by entha_saava »

cies wrote: post #125
laurencerowe wrote: post #50

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

I'd be hard pressed if a backend in Rust gives the same perf as Kotlin/F#. Especially if you write the Rust with an async stack you will likely come out significantly faster than the other options: small binaries, short startup time, less memory usage, more throughput, slightly shorter request cycles, ... The only place that the langs you mention probably win is: learning curve (F# maybe not so much) a.k.a. getting l…

You forgot development times.

Re: Moving from TypeScript to Rust / WebAssembly

#146

Post by collyw »

blub wrote: post #84
aphextron wrote: post #67

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…

They've "won" so far because static types languages were cumbersome and unpleasant to use, but this is changing and dynamic languages are learning some type tricks too. The issue here is with Rust: its strengths are mostly irrelevant for the web and its weaknesses (particularly slow development compared to the competition because of having to pacify the type checker) are really important. Op is painstakingly beating…

I think they have "won" in certain domains. Java and C are still widely used in loads of places, though less so in web dev.

Re: Moving from TypeScript to Rust / WebAssembly

#147

Post by collyw »

mastrsushi wrote: post #131

Migrating a web app to a static typed system programming language is asinine. I swear these fanatics will do anything to say they rewrote it in Rust. This site is full of language-specific indulgent blog posts that are no more sophisticated than arguing over Pokemon cards. I want to see more posts about exciting new concepts like WebAssembly. So sick of hearing that the world would be a better place if the sky and tr…

Have an upvote from me, your attitude put a smile on my face, which is unusual for a comment on HN.

Re: Moving from TypeScript to Rust / WebAssembly

#150

Post by CraigJPerry »

friendzis wrote: post #135
aphextron wrote: post #67

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…

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

Also, what stops something like

    function add(int a, int b) -> int {
        return a-b;
    }
Typing is overrated. It has productive use cases for sure, but only in specific scenarios. It is no panacea.

What would be nice is typing like typescript - optional typing. Where i can provide a typings binding separate from the code (in the way that i can bring my own tests without changing anything of production code if you’ve made an unholy mess of testing). Same argument for optional typing outside the main source code - odds on you’re going to misunderstand or misuse types, I’d like to use them where they make sense and ignore your steaming pile of types. Impossible in a language like haskell where types are inline rather than annotations attached to code.

Post reply on HN