Hacker News Reader

Comment by Shadonototro | Hacker News Reader

Don't look at that kind of benchmark, most cheat, and notice how latency is bad, because C# is not native code, so the JIT needs warmup just like java, wich introduces hicups and non-deterministic performance

So these perfect situations where you only do the same thing and call same code over and over never happen; never!

Anyways, GO isn't popular for its RAW perf, GO is popular because:

- Simple language

- Native code

- GC

- Cross compilation

- Fast iteration (build/rebuild/deploy)

- Relatively tiny, statically compiled executable

View on HN

> - Simple language

So simple it can't do Object.keys()

Don't get me wrong, I enjoy writing code in Go, Rust, and TS. But my god, Go literally is a pain in the ass every time I want to do something that isn't a map reduce problem. And even for map reduce problems it's annoying due to lack of generics.

Maybe generics will finally give Go something that every other language has. A strong, useful, standard library for collections.

I agree with you, i'm not using Go myself, i tried it many times but i always hit a roadblock, it's interesting because i hit the same kind of issues with ZIG

Simple on paper, but what's the experience as a result? some are okay with it, some love the restrictions and limitations, but i personally don't enjoy them

But again, i can understand the choices and the benefits

Neither Go nor Zig are spelled ALLCAPS

I mean those benchmarks are mostly web server related. And it's pretty common in web servers to trigger the same code path over and over again all the time. There's a reason why people are not rewriting their java web server application in something native to get more performance out of it.

These benchmarks also in no way represent actual webapps. Have you seen this code? Have you ever written a webapp where not using hardcoded, static headers like Content-Length was a bottleneck?

the plaintext c# one actually only sets a content length manually since without it it would be a streaming response (Transfer-Encoding: chunked), which would not make the server slower, but the client, because of buffers (also as far as I know the Content-Length needs to be set in this benchmark). btw. go does not do that when calling w.Write without wrapping the responsewriter inside a buffer (which is probably also the case why it is slower, since it needs to know the size of the written response before it goes over the network and btw. only go-std is slow because it's written for simple use cases, there are others like fasthttp who do stuff a little bit more like c# and thus are faster (even inside ;-) go-std never cared about being the fastest.)

> the JIT needs warmup just like java

You can use ReadyToRun[0] to pre-JIT portions of the code for faster startup. Full AOT compilation is in the works too[1] albeit it's still experimental.

[0]: https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...

[1]: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

I think you're missing the point. The point is that you can get all those properties in Rust without the performance hit. (Except for, well, GC, obviously)

Lack of garbage is a pro, not a con.

Rust does not build fast. It’s more comparable to C++ if not worse.

that depends on your dependencies I believe. If the people who keep including serde into their crates would stop everyone would have faster compile times.

Stop using serde. please.

Dependencies make this much worse, but Rust itself is not really very fast at being compiled.

The problem with rust is the language is kind of scary to learn, once you get past the learning curve, it is okay i guess

And on top of that iteration time is hurt because of both the language, the compiler perf, and the lifetime problems that you need to constantly think about

The benefits of using rust on other hand is non-negligible, i wish the team would focus on solving that kind of immediate problems

> the JIT needs warmup just like java

That doesn't sound right. .Net has good support for caching of generated native code. It's well ahead of Java in this regard.

Did you even read the article? That's exactly what their code is doing. It's a giant LRU cache on a very hot path.

Reply on news.ycombinator.com