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