Moving from TypeScript to Rust / WebAssembly • Hacker News Board

Re: Moving from TypeScript to Rust / WebAssembly

#211

Post by jashmatthews » Thu, Jul 09, 2020, 10:17 AM UTC

Lorkki wrote: post #169

blub wrote: post #86

Earlier quoted context omitted.

It didn't figure them out at all, the programmer had to figure them out the hard way and then code them in so that the compiler understands them. GC is figuring out things mostly correctly and the programmer can focus on other things, at least until they hit a performance problem :)

For the most part, lifetime is inferred from scope, so there isn't anything special to figure out; objects live exactly for as long as you can see and use them. This also includes such things as lock handles, or references to refcounted objects.

Only in the most trivial cases. Tons of real Rust uses copying or RC/ARC or even unsafe to avoid dealing with complex lifetimes because it's... complex.

Re: Moving from TypeScript to Rust / WebAssembly

#212

Post by The_rationalist » Thu, Jul 09, 2020, 10:18 AM UTC

tluyben2 wrote: post #165

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…

Exactly; I guess a lot of people just work on projects/jobs and then move on. Once you need to go back to systems you forgot about (things you wrote 5-10-15-20+ years ago), Ruby (in your example and indeed my experience) is a nightmare on speed. The (strange to me) idea that people have that their code won't be around that long, hits me in the face every time a client asks me to 'connect to something made by someone…

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!

Re: Moving from TypeScript to Rust / WebAssembly

#213

Post by jashmatthews » Thu, Jul 09, 2020, 10:24 AM UTC

zozbot234 wrote: post #196

adrianN wrote: post #155

Earlier quoted context omitted.

I doubt that you'll write a large Rust program without relying on refcounting at least for some of your objects. Refcounting is not fundamentally different than a GC.

Reference counting is a kind of garbage collection (taken broadly), but it's quite different from tracing GC.

Naive use of RC doesn't look like tracing much but as soon as you need cycle-aware RC like the CactusRef the algo looks a lot like tracing GC https://github.com/artichoke/cactusref#cycle-detection

Re: Moving from TypeScript to Rust / WebAssembly

#214

Post by sweeneyrod » Thu, Jul 09, 2020, 10:24 AM UTC

imtringued wrote: post #197

blub wrote: post #92

Earlier quoted context omitted.

What's puzzling is why a language designed for memory safety and low-level control and performance is even being considered for web development where they had the former all along and they generally don't care about the latter. Or if they do they use Java, Go or throw a couple dozen more servers at the problem.

With Java you only need to throw more RAM at the server. The performance is perfectly acceptable compared to something like Python or Ruby. You can always squeeze out more performance with Rust but the primary benefit is the lack of a GC.

I don't understand your last sentence. What benefits does lack of a GC have other than more performance?

Re: Moving from TypeScript to Rust / WebAssembly

#215

Post by zurn » Thu, Jul 09, 2020, 10:25 AM UTC

cygx wrote: post #208

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…

because the representatives of statically typed languages at the time were Java and C++ And Pascal, Ada, Haskell, Eiffel, Standard ML, ...

Yep and on the dynamic side there were also Erlang, Python, Lua, Lisp, etc.

Re: Moving from TypeScript to Rust / WebAssembly

#216

Post by unrealhoang » Thu, Jul 09, 2020, 10:26 AM UTC

flohofwoe wrote: post #167

cies wrote: post #125

Earlier quoted context omitted.

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…

If you allocate and free small memory chunks at high frequency in a non-GC language, then it's quite likely that similar code in a GC'ed language will come out faster. The point of manual memory management isn't that it is "automatically" faster than a GC, but that it gives you a lot of control to reduce the allocation frequency (e.g. by grouping many small items into few large allocations, or moving allocations out…

Modern allocators (jemalloc, mimalloc) do pooling optimization just as well as GC. The point of non-GC language is usually about pointing directly to the source data instead of copy and having value type that nicely fit together in the same memory page instead of jumping around in heap space. I know JIT can do all that, but reliably? We'd need Sufficiently Smart Compiler.

Re: Moving from TypeScript to Rust / WebAssembly

#217

Post by sweeneyrod » Thu, Jul 09, 2020, 10:28 AM UTC

satvikpendem wrote: post #8

melling wrote: post #2

I don’t know Rust and haven’t done JavaScript for years but isn’t JavaScript a bit more of a higher level language, which would make a developer more productive? Rust being closer to the hardware should require more code, and effort, to accomplish the same task.

Rust actually can be a higher language. It has true generics, static algebraic data types, functional programming features, and so on, even as it is closer to the metal. It is closer to Haskell or OCaml, but more pragmatic.

In what ways is Rust more pragmatic than OCaml?

Re: Moving from TypeScript to Rust / WebAssembly

#218

Post by tracker1 » Thu, Jul 09, 2020, 10:29 AM UTC

jfkebwjsbx wrote: post #113

blub wrote: post #84

Earlier quoted context omitted.

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…

For a lot of "usual" webdev, any reasonably modern language will do. Even modern JavaScript will be fine. Something like C# would have been way better, though, but we cannot change that now. However... software development has become a mess of slow technologies and abstractions one on top of the other. Some people are working routinely in a text editor that is behind three operating systems: the VM/hypervisor, the us…

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.

Re: Moving from TypeScript to Rust / WebAssembly

#219

Post by satvikpendem » Thu, Jul 09, 2020, 10:32 AM UTC

sweeneyrod wrote: post #217

satvikpendem wrote: post #8

Earlier quoted context omitted.

Rust actually can be a higher language. It has true generics, static algebraic data types, functional programming features, and so on, even as it is closer to the metal. It is closer to Haskell or OCaml, but more pragmatic.

In what ways is Rust more pragmatic than OCaml?

A good package manager, multicore support, larger community, and so on.

Re: Moving from TypeScript to Rust / WebAssembly

#220

Post by zrail » Thu, Jul 09, 2020, 10:33 AM UTC

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 the only way I can function in anything larger than a 10 line script these days. I’ve started adding it to personal projects because it makes revisiting them later so much easier.