Hacker News Reader

Comment by vasergen | Hacker News Reader

What does it mean "blazing fast"? Every new thing is blazingly fast nowadays.. deno, bun, turbopack, etc. I don't even know what does it mean to me as a user, does it really super fast or it is just some fancy words. "blazingly fast" compared to what?

View on HN

I'm starting to wonder why people are saying their stuff is fast. Much of the time there's no benchmark.

Blazing fast is so fast, one cannot measure it. You'd try and fail because, woof, it's gone. And you know it's good because it has Zing! in it.

Comes free with most snake oil marketing kit.

It is a meme, but at the same time performance has become a popular selling point again.

Saying "It's super fast" isn't a selling point.

facebook/zstd has performance as a selling point, by doing extensive benchmarks and presenting them.

I never understood the meaning of using "tm" with "blazing fast" and "it just works", is it a joke that is well known in tech?

Yes. "It just works" is a famous Apple meme. Others using "tm" are memeing on companies that come up with stupid marketing names for every little thing that doesn't require any branding at all.

Something that helps me: instead of reading "blazing/blazingly fast" as "blazingly fast", read it as "blazingly fast". As in, it is fast at doing whatever it's doing, as are almost all entrants in... whatever this stuff is. But it is doing it in a way that is figuratively analogous to a large conflagration. Whatever is running on it will end up a blackened, twisted pile of wreckage. Perhaps after achieving its purpose, perhaps a bit before.

I'm not saying that's what they're saying, but I am saying it's a valid interpretation of what they're saying. It's worth speculating about which interpretation better fits the subject at hand.

Yeah this kind of statement drives me up the wall. It's even more annoying when they do show some benchmark stats, but don't provide any details on how to run the benchmark yourself.

Especially considering that SpiderMonkey is definitively not blazing fast compared to V8 or JSC, for common web workloads anyway. At most it’s comparable. Somehow doubt adding a layer of wasm indirection makes it faster. But I suppose everything is indeed blazing fast when compared to no target at all.

Yeah they have to sell bytecode based runtimes, never done before.

I assume they mean startup speed (cold-start). Since they're not using JIT (WASM doesn't support it) the runtime performance will be miles beyond V8 and JSC.

I'm on old curmudgeon and just want to go back to saying, "C#...It's fast enough!"

A good catch. Blazing fast when your webpack's build decreases from 40 seconds to 400 milliseconds: https://esbuild.github.io/

Anything else marketing staff.

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.

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.

Cough, native apps.

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

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

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?

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

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.

Reply on news.ycombinator.com