←back to thread

.NET 10

(devblogs.microsoft.com)
489 points runesoerensen | 5 comments | | HN request time: 0s | source
Show context
jitbit ◴[] No.45888669[source]
For us, every .NET upgrade since .NET 5 has gone surprisingly smoothly and reduced CPU/RAM usage by 10–15%.

We were even able to downgrade our cloud servers to smaller instances, literally.

I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

replies(26): >>45888799 #>>45888804 #>>45889332 #>>45891939 #>>45896032 #>>45898279 #>>45898305 #>>45898358 #>>45898503 #>>45898877 #>>45899062 #>>45899235 #>>45899246 #>>45899326 #>>45899445 #>>45899481 #>>45899858 #>>45900544 #>>45900791 #>>45900829 #>>45903218 #>>45904345 #>>45904435 #>>45905041 #>>45906073 #>>45907122 #
nicoburns ◴[] No.45900544[source]
> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.

replies(12): >>45900964 #>>45901284 #>>45901414 #>>45903677 #>>45904049 #>>45904177 #>>45904488 #>>45907685 #>>45907873 #>>45908268 #>>45908319 #>>45908388 #
DarkNova6 ◴[] No.45903677[source]
Silly question. If you want the C# experience but more community/OSS driven… why not Java?
replies(5): >>45903923 #>>45904096 #>>45904106 #>>45906499 #>>45906598 #
Kwpolska ◴[] No.45906499[source]
C# 1.0 was pretty much Microsoft Java, but since then, C# has evolved into its own, more powerful thing, while Java has stayed much more conservative over the years.
replies(1): >>45907035 #
1. osigurdson ◴[] No.45907035{3}[source]
I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.
replies(2): >>45907289 #>>45908603 #
2. Kwpolska ◴[] No.45907289[source]
What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.
replies(1): >>45907939 #
3. osigurdson ◴[] No.45907939[source]
I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.
replies(1): >>45908222 #
4. kbolino ◴[] No.45908222{3}[source]
> I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today.

Have you never written a plugin or a mod?

Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features.

As soon as you AOT compile CLR or JVM languages, you lose access to the stable, feature-complete ABI that bytecode provides. Heck, many languages built from the ground up for static compilation like Go and Rust still have dismal ABI stories. The only exception I can think of is Swift, and it didn't come by it easily. AOT also imposes limits on reflection and runtime codegen (often, to the point of totally removing them).

If your software exists only in a walled garden, only gets deployed to infrastructure you 100% control, can't be extended at all, and/or can only be extended by full recompilation, then bytecode may seem useless. But that isn't the whole world of software.

5. naasking ◴[] No.45908603[source]
.NET needs runtime code generation for some of its core features, like generics. Bytecode makes this much easier.