[lionkor]

They use Rust (i like Rust), so they have to somehow convince themselves that their mess of overly abstracted code strewn across 2000 crates is, in fact, very very fast and it's all worth it.

I think people use a language like Rust because they hear its got potential for performance, but its told to them like so: "Rust is blazing fast!". So they perpetuate that idea, and just hope to god that their program, even if its horribly cache-inefficient, allocates aggressively, context switches constantly, etc. is still fast enough that it feels fast.

Also, of course, on dev machines which often have high end hardware, it probably does feel very fast. "I can't even see any time between input and result, its so fast!", said the programmer running his script on an overclocked i9-9900k with nothing else open

To be clear, nothing about Rust or C or C++ is fast. They allow you to write faster code than most other languages, some more easily than others. All of those you can easily write the slowest code imaginable in. Try doing a bunch of very expensive copies in C# or Java - youd have to go out of your way. In C++ its default behavior.

[biorach]

> their mess of overly abstracted code strewn across 2000 crates

Have you actually taken the time to read the source code of this project to see how many creates are used and how it is architected, or are you just piling shit on them for no reason?

[threatofrain]

I use leetcode as my way of learning new programming languages, since if you already know the concepts then you can just focus on language ergonomics (how does this language look like when solving a problem I've seen before?). In general my naive Rust code is 2x faster and also leaner on memory than my Go code, and my Go code has the same relationship to Node.

But I wouldn't say this is a special quality of Rust. I'd expect similar winnings had I chosen any other non-GC compiled language like, say, Zig. Just saying that the well known tiering of languages has held true for me.

[devjab]

I’m struggling to understand what you mean. Why on earth would you compare whatever poorly optimised concept you have in your head with .Net or the JVM? Like really? How is that helpful or even remotely related to the problem at hand? The idea here is to write service workers which are more efficient than nodeJS service workers, and winterJS seems to succeed very well at this. It doesn’t really matter what goes into the build process, it’s what happens once it’s executed we care about and if you have any Java or C# code to rival or surpass WinterJS then I really think you should share it.

I’m sorry if you’re one of the developers who’s stuck on Java or C# and feeling frustrated for whatever reasons. The JVM is fast and will continue to power much of the world for decades to come, and C#, well, it’s probably not going anywhere either. But what you’re writing about here doesn’t really make a lot of sense in the greater scheme of things. Right now, the client side of things is JavaScript and while we build it in a lot of different ways it’s hard to argue against the need for better service workers until we have a suitable replacement, which we likely won’t have in our careers.

[lionkor]

I'm saying languages with a Runtime and everything-is-a-(nullable)-reference dont have this issue of programmers being able to write super awful code. There is a clear limit to how slow simple looking code can be in C# or java, whereas languages like C++ (which I have a few years experience in) definitely allow you to write the worlds slowest code without the code looking like it.

Maybe you expected me to have a combative point due to my introduction, but i dont - im just pointing out that people use languages like Rust and C++ thinking they are fast, when really, an inexperienced programmer in either will write slower code than an inexperienced programmer in a lot of other languages.

They feel they dont need benchmarks, because their language is "fast".

[devjab]

I still don't think your point makes a lot of sense. C# and Java aren't going to protect you from writing bad code. I've had to do enough re-writes to remove RestSharp from codebases to know that C# developers aren't exactly "good" at using C# or it's standard toolage. So in that sense, it's very similar to Rust.

You're right of course. It's very easy to write shitty code with much futher reaching consequences in C++, but I've never really experienced it. Like, we use Typescript for basically everything (not because we necessarily like Typescript but because it allows us to share developer resources across basically everything) but when we need performance we turn to C or C++. We also use C and C++ for embedded, but that's mostly because we kind of have to. We'll eventually turn to Rust exactly because it offers some of the benefits you talk about from Java or C# without any of the downsides.

I know both Java and C# have large fanbases, and for Java at least, there is good reason behind that, but even if you went that road in 2023, I'm not sure why you wouldn't follow the good people at places like Lunar and simple turn to Go. Unless of course you're stuck with some huge legacy codebase, which in itself is a very good reason to stick with Java.

> They feel they dont need benchmarks, because their language is "fast".

It's not though. Even if you use Java or C# you're eventually going to need to turn to C and C++ for better computation. I know a lot of medium sized C# houses never get there, but maybe there is a reason C# is basically only used by companies that stagnate at a certain size?

[basique]

> There is a clear limit to how slow simple looking code can be in C# or java

Java/C# code can become incredibly slow if you allocate way too many objects, use Streams/LINQ or touch URL#equals. Why are managed languages specifically better here?

[pjmlp]

Cough, native apps.