Thro4l31

The problems come with maintaining the translated code bases:

1. A code base written in C and a team of C engineers that have a good mental model of the code base to be able to maintain it.

2. An automatically translated Rust code base. Potentially (I'd say probably, but that is just my gut feeling) harder to read and understand than the original one.

3. Now you need a team of Rust engineers that have a good mental model of the code base that was generated.

If you already have that team of Rust engineers, I'd rather let them rewrite the code manually as they can improve it and have the correct mental model from the start.

I don't think people will migrate to Go, as they most likely chose Node (or Deno) because of full-stack Typescript or Javascript. People who need the great performance of Go are probably already using it. For a Rust, Typescript, C#, Kotlin or the like user, Go is a hard pill to swallow due to it's limited type system and cumbersome DX. Also, Go modules are typically un-intuitive.

I also think that Bun will have a very hard time to become relevant. The hype is already over. Their benchmarks and marketing are old and sketchy. I mean, they're using uwebsocktesJS under the hood, which you could use with Node or Deno as well, if it's important to you to serve 2000000 times per second a static "hello world". Startup times for JS runtimes have been debunked recently. (You can prepopulate some caches which makes the startup surprisingly fast, https://deno.com/blog/aws-lambda-coldstart-benchmarks)

If you take a closer look at Deno's core api and std lib, there's much to like. The advantage compared to Node a significant, but I agree that they might not be decisive for most projects. Time will tell.

Deno (with Typescript of course) is my "smaller Rust". Whenever I don't need the performance and efficiency of Rust, I fall back to Deno. The development speed is much higher while the result is reasonable fast and safe.

- Typescript (compared to other main stream languages like Go or Java) comes pretty close to Rust regarding the type system, e.g. discriminated unions (https://mkosir.github.io/typescript-style-guide/#discriminat...) or null-checks as "the second best version of null safety". (The best is still the option type.)

- Deno has an exceptional core api and std lib. Performance is great. In my experience it's very stable (except some newer Node APIs). The tooling is great and now the move to JSR and Node compatibility widens the ecosystem while trying to make it safer. I wonder how the Deno team plans to push JSRs adoption.

- It's single threaded. Yes, I think it's a feature. Multithreading via Webworkers might not be as fast as sharing memory, but it's much safer. I even think it has an edge over Go, if you don't need the extra performance of Go. Go is generally faster, esp. for computations. Web stuff in Deno is fast enough as they use Hyper under the hood.

I really hope JSR adoption will grow.

Of course React can handle complex and large scenarios. And those scenarios aren't even large. It's good that you created that proof. Still, Svelte is much easier while more performant, even if that extra performance is most often not needed. Large amounts of data can be managed by react-virtualized in React. IME Svelte (and Vue) can handle more without virtualization, but for really large data sets you need it anyway. The downsides of React are not performance IMO, but DX.

> I really am disappointed svelte5 is turning into react-ish framework.

This is very wrong. Read the announcement and the docs: https://svelte.dev/blog/svelte-5-release-candidate https://svelte-5-preview.vercel.app/docs/introduction

Svelte 5 has change its reactivity model to signals. I anything, it's became similar to SolidJS. All other changes are minor but make Svelte even simpler to use.