3 ms·

The claims are plenty substantiated. I wrote a lot of C# and a lot of Go. C# has so much more ceremony that it is more verbose and it shows even in the code we

by kjksf 6y ago

The claims are plenty substantiated. I wrote a lot of C# and a lot of Go. C# has so much more ceremony that it is more verbose and it shows even in the code we're discussing. You just have to be willing to look. Fair comparison between C# and Go is actually very easy. Those languages are so similar that you can transliterate a given benchmark from one language into another. Then benchmark those versions. There's just no way that on an average program Go (language statically compiled to assembly with a very competent code generator) will loose in performance to C# (which compiles to bytecode and then JITs that code at runtime using a much weaker code generator).

igouy 6y ago
> I wrote a lot of C# and a lot of Go. C# has so much more ceremony that it is more verbose and it shows even in the code we're discussing. You just have to be willing to look. The Go mandelbrot program you looked at is a little larger than one of the C# mandlebrot programs. 816 C# .NET #9 program 894 Go #3 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-csharpcore-9.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-go-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
HereBeBeasties 6y ago
I also write both Go code and C#, amongst other things. I find your assertion that C# has lots of ceremony and ends up with more code than Go frankly pretty strange. Go is well known for having laborious error handling (prompted by a lack of exceptions) and masses of boilerplate and verbosity precipitated by the lack of various other features, the most glaring of which is an absence of generics. This means implementing custom data structures is generally an exercise in copy paste, or ignoring type safety. Things like the lack of extension methods, JSON and YAML serialisers that require explicit annotations everywhere instead of conventions, the lack of OO/polymorphism, no ternary operators, null chaining operators, etc. etc. also contribute to the verbosity. Simplicity is good, but the lack of expressivity and the need for such boilerplate is bad. A pretty poor type system makes it worse. Go has many strengths, but I massively prefer C# for the majority of non-trivial situations. Regarding performance, it depends heavily on what you're doing. For example, Go's allocator and GC is designed to optimise for low pause latency, whereas dotnet is optimised more for high throughput and good cache coherency. Given the extent to which most apps are stalled waiting for memory, the lack of good cache coherence in Go allocations, and the lack of a generational GC can absolutely decimate performance. DotNet is capable of allocating at 25x the speed of Go, for example. Go read https://medium.com/servicetitan-engineering/go-vs-c-part-3-compiler-runtime-type-system-modules-and-everything-else-faa423dddb34 https://medium.com/servicetitan-engineering/go-vs-c-part-3-c...

by kjksf 6y ago

igouy 6y ago

> I wrote a lot of C# and a lot of Go. C# has so much more ceremony that it is more verbose and it shows even in the code we're discussing. You just have to be willing to look. The Go mandelbrot program you looked at is a little larger than one of the C# mandlebrot programs. 816 C# .NET #9 program 894 Go #3 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-csharpcore-9.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-go-3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

HereBeBeasties 6y ago

I also write both Go code and C#, amongst other things. I find your assertion that C# has lots of ceremony and ends up with more code than Go frankly pretty strange. Go is well known for having laborious error handling (prompted by a lack of exceptions) and masses of boilerplate and verbosity precipitated by the lack of various other features, the most glaring of which is an absence of generics. This means implementing custom data structures is generally an exercise in copy paste, or ignoring type safety. Things like the lack of extension methods, JSON and YAML serialisers that require explicit annotations everywhere instead of conventions, the lack of OO/polymorphism, no ternary operators, null chaining operators, etc. etc. also contribute to the verbosity. Simplicity is good, but the lack of expressivity and the need for such boilerplate is bad. A pretty poor type system makes it worse. Go has many strengths, but I massively prefer C# for the majority of non-trivial situations. Regarding performance, it depends heavily on what you're doing. For example, Go's allocator and GC is designed to optimise for low pause latency, whereas dotnet is optimised more for high throughput and good cache coherency. Given the extent to which most apps are stalled waiting for memory, the lack of good cache coherence in Go allocations, and the lack of a generational GC can absolutely decimate performance. DotNet is capable of allocating at 25x the speed of Go, for example. Go read https://medium.com/servicetitan-engineering/go-vs-c-part-3-compiler-runtime-type-system-modules-and-everything-else-faa423dddb34 https://medium.com/servicetitan-engineering/go-vs-c-part-3-c...