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

351–360 of 428 posts

Re: Moving from TypeScript to Rust / WebAssembly

#351

Post by victor106 »

jes5199 wrote: post #143
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’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…

Exactly this.

I was involved in developing large PHP and Rubby codebases and its so hard to maintain.

These days I just use SpringBoot. It strikes a good balance between providing speed to market (PHP/Ruby), maintainability and performance (the next version should support GraalVM). Cant complaint so far.

Re: Moving from TypeScript to Rust / WebAssembly

#352

Post by lacker »

filleduchaos wrote: post #102
lacker wrote: post #30

[TypeScript] does not actually ensure that the data you are manipulating corresponds to the type that you have declared to represent it. For example, the data might contain additional fields or even incorrect values for declared types. This is only a problem if you are mixing untyped code with typed code, isn't it? Like when you are parsing JSON, you need to do typechecking right then, rather than just using an "any"…

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

Re: Moving from TypeScript to Rust / WebAssembly

#353

Post by pjmlp »

treis wrote: post #315
masklinn wrote: post #204

Earlier quoted context omitted.

> This really nails why languages like PHP and Ruby have won out over static typed It really doesn't. Languages like PHP and Ruby "have won out" over statically typed languages because the representatives of statically typed languages at the time were Java and C++, both of which were bad (they still are, but they were): verbose, difficult (and verbose) to leverage for type-safety, missing a bunch of tremendously usef…

I think this is spot on. IMHO, everyone that uses Rails knows it's flawed. The problem is that there's not a better option out there that: (1) Is "batteries included" (2) Has the gem/engine ecosystem where basically every problem is already solved. (3) Expressive code like has_many :things If we could get those things + static typing + performance everyone would switch. But that doesn't exist.

.NET and Java have enough batteries, 20 years of libraries solving every problem, several expressive languages available, alongside AOT/JIT compilers.

Re: Moving from TypeScript to Rust / WebAssembly

#354

Post by mumblemumble »

zaphar wrote: post #269
The_rationalist wrote: post #212

Earlier quoted context omitted.

The dilemma: boilerplate vs dynamic languages is a thing of the past. Kotlin make code even clearer than in java while being the sexiest syntax out there. It's 100% compatible with your Java code so you can incrementally migrate starting now!

The dilemma was always a false choice. You don't need kotlin to get rid of your boilerplate. Java is just a capable of being concise as any other language. Java's verbosity is a cultural artifact not a technical one.

So, technically, you can get rid of a lot of the more egregious clutter with things like Project Lombok.

But I'd argue that, if you need to lean on compiler plugins to do it, it's sort of a rhetorical Pyrrhic victory.

Re: Moving from TypeScript to Rust / WebAssembly

#355

Post by treis »

pjmlp wrote: post #353
treis wrote: post #315

Earlier quoted context omitted.

I think this is spot on. IMHO, everyone that uses Rails knows it's flawed. The problem is that there's not a better option out there that: (1) Is "batteries included" (2) Has the gem/engine ecosystem where basically every problem is already solved. (3) Expressive code like has_many :things If we could get those things + static typing + performance everyone would switch. But that doesn't exist.

.NET and Java have enough batteries, 20 years of libraries solving every problem, several expressive languages available, alongside AOT/JIT compilers.

.NET has the problem if being a MS product. It's only relatively recently that they've decided to be fully cross platform and open source. I'm not sure if it's all the way there yet, but it could be a viable option.

Java is fine as a programming language. Java as a web app more or less means Spring. And Spring means XML files and annotations which come with their own problems. Kind of an out of the pan and into the fire thing.

Re: Moving from TypeScript to Rust / WebAssembly

#356

Post by zenhack »

zozbot234 wrote: post #200
zenhack wrote: post #88

Earlier quoted context omitted.

I think a lot of the best the best things in Rust don't really have anything to do with low level programming per-se. And I find that for most applications, even with all of the extra goodness, the lack of a GC totally craters productivity. Its not because I'm fighting the borrow checker -- I got the hang of it pretty quick. But it means that every API is complicated by the need to think about lifetimes and ownership…

> But it means that every API is complicated by the need to think about lifetimes and ownership, having to think about different types of smart pointer, etc. It means you have to manage all of these silly little details which for most applications are pretty irrelevant. Rust gives you the features to auto-manage these "silly little details", you simply have to opt-in to them with a bit of boilerplate. Stuff like Rc >…

You still have to deal with the fact that existing APIs use a broader range of types; using Rc everywhere in your own code doesn't save you from dealing with library interfaces.

Also "stuff like" is kind of the problem; all of the smart pointer types have differences that matter, and none of them is general enough to cover all use cases. Arc>> comes the closest to a "general" solution, but the boilerplate is rather a lot just for the sake of not having to think about this stuff, and you still can't use it if T isn't Send.

You're really picking a fight with the language if you insist on avoiding making these decisions, and in the end it will just slow you down even more than going with the grain. And to add insult to injury, if you write all your code like that it'll likely be slower than OCaml or Haskell anyway. Rust can't keep up with a good GC on allocation throughput; the performance advantages come from managing things yourself (and avoiding heavy allocation in the first place).

Rc and friends are useful, but they don't make the problem go away.

As I said, it's not that it's even really all that hard. But it is time consuming.

Re: Moving from TypeScript to Rust / WebAssembly

#357

Post by benschulz »

lacker wrote: post #30

[TypeScript] does not actually ensure that the data you are manipulating corresponds to the type that you have declared to represent it. For example, the data might contain additional fields or even incorrect values for declared types. This is only a problem if you are mixing untyped code with typed code, isn't it? Like when you are parsing JSON, you need to do typechecking right then, rather than just using an "any"…

No[1], TypeScript is unsound in many ways. Most of them are intentional trade-offs to catch as many bugs as possible while not being too restrictive/allowing most JavaScript code to be annotated.

[1]: https://codesandbox.io/s/te0pn?file=/index.ts

Edit: Apparently TypeScript playground links cannot be shared :( Edit2: Published on codesandbox.io, hopefully that works

Re: Moving from TypeScript to Rust / WebAssembly

#358

Post by pjmlp »

treis wrote: post #355
pjmlp wrote: post #353

Earlier quoted context omitted.

.NET and Java have enough batteries, 20 years of libraries solving every problem, several expressive languages available, alongside AOT/JIT compilers.

.NET has the problem if being a MS product. It's only relatively recently that they've decided to be fully cross platform and open source. I'm not sure if it's all the way there yet, but it could be a viable option. Java is fine as a programming language. Java as a web app more or less means Spring. And Spring means XML files and annotations which come with their own problems. Kind of an out of the pan and into the f…

Plenty of companies don't care one second that it is a MS product, in fact it is a positive value on their eyes regarding product support and tooling.

First of all there is more to Java Web development than JEE and Spring, which in any case, other eco-systems don't have a mature answer for many of their deployment scenarios and cross system integrations.

XML is beautiful, there is yet a format that supports machine manipulation, IDE graphical tooling, comments, schema validation as XML.

Anyone that praises Rails will be right at home with XML and annotations magic.

Re: Moving from TypeScript to Rust / WebAssembly

#359

Post by bigredhdl »

rubber_duck wrote: post #288
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 ;)

I started on C++ back in VS6 days and I wrote tons of it when I was in to game dev and graphics programming - but I would not want to work on those systems and kinds of problems when I can get paid the same to work on higher level stuff - the tooling quality and slow iteration cycle when I'm really stuck on something leads to a lot of stress - I just want low stress dev environment where I focus on solving problems I…

I agree. My team is just more productive in C#, so we just stay there as much as possible. As you say, the ability to work on just solving the actual problem is very under valued.

Re: Moving from TypeScript to Rust / WebAssembly

#360

Post by mwcampbell »

cs702 wrote: post #302
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…

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

> with high confidence that it will work and last a long time

And we need more of our software to be like that. Now if we could just do something about the constant pressure to compromise.

Post reply on HN