6 ms·

GO promised to be very fast, but if you check the actual benchmarks: https://www.techempower.com/benchmarks/#section=test&runid=8ca46892-e46c-4088-9443-05722ad

• anewaccount2021 6y ago
  Go is slower than Rust but three times as fast as you'll ever need it to be Everything in Techempower that is in the top half of performance is likely to be fast enough that your own architectural issues will be gating your performance, not the language/framework
• Shadonototro 6y ago
  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
  • felipellrocha 6y ago
    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)
    • unanswered 6y ago
      Lack of garbage is a pro, not a con.
    • jmaygarden 6y ago
      Rust does not build fast. It’s more comparable to C++ if not worse.
      • drenvuk 6y ago
        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.
        • saagarjha 6y ago
          Dependencies make this much worse, but Rust itself is not really very fast at being compiled.
    • Shadonototro 6y ago
      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
  • aaomidi 6y ago
    > - 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.
    • Shadonototro 6y ago
      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
      • phabora 6y ago
        Neither Go nor Zig are spelled ALLCAPS
  • madushan1000 6y ago
    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.
    • atraac 6y ago
      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?
      • merb 6y ago
        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.)
  • MaxBarraclough 6y ago
    > 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.
  • Kipters 6y ago
    > 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-to-run https://docs.microsoft.com/en-us/dotnet/core/deploying/ready... [1]: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
  • hiptobecubic 6y ago
    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.
• xtacy 6y ago
  They key takeaway really is that for high performance, the way you think about memory layout, data structures, memory management, etc. all start to really matter. It is possible to write programs with memory pools to reuse data structures as much as possible without having to defer the work to the GC, which can then introduce performance spikes. That said, C# and JVM are both mature and have decades of GC improvements, which could explain why golang is falling behind. Time will tell.
• d1str0 6y ago
  Performance is rarely the top priority for a software engineering project. If you task a whole team to switch from Go to Rust or C# purely because “Rust goes brrr” you’re going to have a bad time. I use Go because its decently fast, I like the syntax, has a great stdlib, and I feel like it’s very easy to share a Go codebase with other engineers.
  • steve_adams_86 6y ago
    One of the key things I like about Go, despite shortcomings, is your last point. Our team effortlessly shares Go code, and its tooling makes it so any of us at any time can easily compile and run projects without hassles or hang ups. The other day we reviewed some oldish and complex code and it was so plain to see what it was doing and get back into the flow of that logic. I don’t find this happens with other languages as much. I’m not saying Go is the right tool everywhere for everyone. I do love that about it though.
    • jariel 6y ago
      We might want to highlight this more often that not. Code legibility is starting to become a primary if not the primary factor for a lot of software these days, because that's what allows it to be maintained. I think more analysis should be done on why this is for go. Java and C# should be similarly legible, they are not complex languages either. It's possible that go encourages certain paradigms.
    • shakezula 6y ago
      Definitely agree with this. Go is one of the only languages I've worked in where I can jump into _any_ project and it feels familiar, I just have to dig around to get into the specifics. I have never had that same familiarity from Python, Ruby, JavaScript. I think there's something to be said about that in Go's favor.
      • jokethrowaway 6y ago
        While I agree with you on the familiarity across different projects (and I applaud ideas like gofmt) - it's also very verbose code (due to the simplicity of the language). That makes it very hard to read go code and build a mental model in your head.
• hu3 6y ago
  Have you seen the kind of C# code they write to compete in Tech Empower? It's nowhere near what one would write on a daily basis: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/CSharp/aspnetcore/PlatformBenchmarks/BenchmarkApplication.Fortunes.cs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Perhaps Go folks should just use inline assembly to demonstrate how useless these benchmarks are.
  • infensus 6y ago
    This 1000x times. Should be posted every time someone links to TechEmpower benchmark results. And especially for the most contrived benchmarks like "Plaintext" and "JSON serialization", which are basically echo server competitions that have nothing to do with real applications.
  • thelazydogsback 6y ago
    Most code is not CPU-bound, and for code that is, a hot spot is all the usually needs to be optimized. Today .Net Core is remarkably performant, and the fact that just by writing code carefully, or using Span<> etc., you can get close to bare-metal perf with w/o resorting to FFI to unsafe code is a good thing. This is much easier than trying to keep your friendly Rust borrow-checker happy even for moderately complex data-structures with varying lifetimes.
    • hu3 6y ago
      When you put it that way .NET Core runtime does seem to offer great performance at low cost.
  • DennisP 6y ago
    That's nowhere near as bad as inline assembly. It might not be the usual way to write a web app, but it's normal C# with common libraries. Any C# dev could use that as an example if they ran into a major performance issue. These benchmarks aren't intended to show the performance of everyday code. They show what experts can achieve on each platform. That's why they take pull requests instead of writing the code themselves from tutorials.
• deleted 6y ago
  [deleted]
• cletus 6y ago
  Why? Well, for one, Go produces a statically linked binary and C# requires a runtime be installed. If we’ve learned nothing from Java and Python, it’s that managing runtimes and environment can be a huge pain point. EDIT: swipe keyboard put ringtone instead of runtime and I missed it. Corrected.
  • meepmorp 6y ago
    >C# requires a ringtone be installed. This confused the hell out of me until I realized it's supposed to be runtime.
    • philwelch 6y ago
      Thanks. I assumed it was an allusion to the .Net runtime having a bunch of unnecessary crap built into it, including a ringtone for some arcane reason.
    • thaumasiotes 6y ago
      Autocorrect: turning simple, obvious mistakes into opaque, irrecoverable mistakes. It's never been clear to me why someone would want this.
    • tantalic 6y ago
      On the other hand, would you be surprised to learn the .NET runtime includes a ringtone?
      • meepmorp 6y ago
        That's probably why it confused me so much; I couldn't rule out that interpretation reliably enough to interpret it as a typo.
  • tonyedgecombe 6y ago
    You can do that with C#: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
  • 6y ago
• PragmaticPulp 6y ago
  If performance is the top priority and time to market can take a back seat, I skip Go and choose Rust (or other known-fast languages). However, time to market is almost always a priority. Unless my margins are razor-thin, spending twice as much on servers for shorter development cycles is a net win in most cases.
• Thaxll 6y ago
  Go is as fast as dot net in the same benchmark you posted: https://www.techempower.com/benchmarks/#hw=ph&test=plaintext https://www.techempower.com/benchmarks/#hw=ph&test=plaintext aspcore 7,016,966 gnet 7,010,982 People share results of benchmark where some languages are missing.
  • mikece 6y ago
    It wasn't that long ago that compariing .NET to Go was insane: Go was far faster but now it's a toss-up in some cases. Go still wins on small size of binary but in cloud workloads does it really matter if my lambda in go is half the memory and half the execution time when the "bigger, slower" C# version is still under 128MB and executing only a few milliseconds slower? In cloud cost terms the difference is small enough not to matter.
    • Thaxll 6y ago
      It tooks years and a lot of work for them to make it on part or faster, Go did not focus on performance recently. Also you should take benchmark with a grain of salt, every recent language can be fast nowdays.
• jamra 6y ago
  One of the things to consider when comparing C# and Go is how it does parallelism. In C#, the new async/await mechanism can go horribly wrong if the programmer doesn't use it correctly. This can cause threads to start up, which is in fact slower than older .NET tech that had larger starting thread pools. You can view this with PerfView to see if it's your load issue. In Go, the scheduler is smart enough to stop something even when it's not blocking on IO. This makes it more robust. Of course, use what you need for when you need it. Rust definitely shines in some circumstances.
  • chrisoverzero 6y ago
    > In C#, the new async/await mechanism […] C# grew the `await` operator in C# 5.0, released in August of 2012. Go altogether hit 1.0 on 2012-03-28. If the one is new, the other is new.
• stiray 6y ago
  I am not saying Go is faster or anything I am just saying that take the grain of salt with reading the benchmarks as they are on same level as googling for "best microwave oven in 2021" where you know it is better not to even start reading the results as they will be full of paid "fake" reviews. Not to even start about microwave oven brand fanboys. You have to understand that the programming language is a product in same way as anything else and there are influencers, marketing bribes, paid advertisements, forum/hn/fb/... paid spammers, etc. Just remember what spam spike the Rust (I am again not talking about rust as a language... just about the noise everyone made) had here when it emerged, they threw the shadow on the Nigerian spam, oh the amount of noise from Rust-Distributed-Evangelist-Task-Force (they will probably downvote me to hell for mentioning this :D), I had a lot of fun reading HN at that time, the most used word was 'and', the second was 'rust', it was so exaggerated that it was like watching Monty Python. In today world the only review, or if you want, benchmark, is the one you make. Nothing else counts and if you feel that C# is faster then enjoy using it. And quite frankly, who cares about speed today (except some very strange people like me), people are using very strange languages and want to run them on backend. And they actually do. Ignore the benchmarks, no one cares (except those that would like to advertise themself like "faster than C" :D). Just threw in some more vapor on the cloud and you have "fixed" the speed issues. /s