It also gives you more control over memory allocations than Java
Cool! I didn't know about this. Can you share an example? It might foster some good discussion. I haven't written any serious C# in about 10 years now. I still love that language. To me, it's like Java with all the rough edges sanded down. In that era, Visual Studio was the only choice for dev and needed the IntelliJ plug-in. I always thought that was a bit goofy, but nothing against the language itself. And, the COM+ integration is legendary if you need to run on Win32.
Value types have gained more functionality in recent versions.
You can quickly create record structs or value tuples (that auto-implement Equals(obj) & GetHashCode()) and pass them around by reference instead of copying.
record struct RGBA(byte R, byte G, byte B, byte A);
// allocate a small collection on the stack
Span<RGBA> colors = stackalloc RGBA[3]
{
new RGBA(255, 0, 0, 255),
new RGBA(0, 255, 0, 255),
new RGBA(0, 0, 255, 255)
};
// get value by reference
ref var c = ref colors[2];
c = new RGBA(127, 127, 127, 255);
// prints: RGBA { R = 127, G = 127, B = 127, A = 255 }
Console.WriteLine(colors[2]);
// value tuple
(byte R, byte G, byte B, byte A) white = (255,255,255,255);
Heap allocated generic collections of value types have better data locality than collections of reference types.
Ref struct is a type of struct that is always stack allocated and cannot be promoted to the managed heap or boxed. `Span<T>` is ref struct.
Spans allow you to create views over contiguous regions of memory that is located on the stack or on the heap or over native memory. You can pass spans to methods that then read/modify the data in the view.
And many other features that help you manage memory or avoid allocations.
For example. When working with interfaces you can avoid boxing allocation of value types by using a generic type constrained to the interface instead of the interface.
c# has structs and span, which makes memore allocation more easy. in java the thing gets easier as well (soon) but java still has no value types and than there is sun.misc.Unsafe which is still a special case and a really really old api, in jdk 19 some new apis were introduced which lifts some of these stuff like panama preview and a new vector api.
When it comes to languages you can draw up a loose hierarchy of potential performance where languages like C# and Java are vastly equivalent. Attempting to refine it any further descends into a bikeshedding farce.
Why is this being downvoted? Sure the opening line isn't the most gentle, but these are some crazy benchmarks. I never saw this website before.
First link: How is it possible that Java can achieve same perf as C??? I write a lot of Java, and none of my stuff is close to C. I guess about 50% the speed -- which fine for my needs.
One reason (totally unscientific, of course) I think Java is faster: The virtual machine has been open source for longer. So more academics have looked at, run experiments, written papers... that are then read by the core Java team and sometimes implemented. C# is a bit behind, but should catch-up one day.
> The virtual machine has been open source for longer. So more academics have looked at, run experiments, written papers... that are then read by the core Java team and sometimes implemented. C# is a bit behind, but should catch-up one day.
That's what it is indeed, more R&D went into Java
C# will catch up eventually, specially now that they invest massively on PGO/AOT and ways to minimize heap allocations (stackallock and struct reference for example)
Techempower benchmarks are web framework benchmarks, not language benchmarks. It's hard to compare language performance from these benchmarks as there are so many other factors here that affect performance.
C'mon, this benchmark properly benchmark how fast languages are at certain tasks, the library used doesn't matter, the task however matter
A framework is not representative of a language performance, it is representative of the framework's performance, they might not use newest language features, they might use outdated dependencies, developer might have wrote poor code, they might have bugs
because you should really look into these frameworks if you really think its a good comparsion. if you exclude all the unserious java frameworks you will be stuck with vertx, after that there is a huge list of c# and than there is the rest of java. I mean yes, these frameworks might be the next big thing in the java world, but once they are there, they will at least loose 20% of performance. (p.s. you can also remove the first c# entry, because no sane person will write everything as a middleware)