221–230 of 300 posts
As a big user and fan of c# but this is a miss, as it always boxes value types.
Earlier quoted context omitted.
Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.
Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.
Associating virtual threads with "legacy heavy weight threads" is a fundamental misunderstanding
> That’s why Swift, Rust and Typescript all chose async/await for concurrency.
And Java chose to join Team Go/Erlang. At the end of the day, async/await is just syntactic sugar for futures/promises, which are essentially a way out of callback hell.
Besides, Rust and Typescript aren't good examples here: a green-thread scheduler (a runtime component) contradicts Rust's philosophy, while Typescript is inherently constrained by Javascript.
Earlier quoted context omitted.
Alright. I'm actually fine with WinForms and WPF since my factory floor codes depend on them. But the reality is they aren't expressive enough for modern UIs. XAML is an issue, and WPF is boilerplate hell. But then Blazor is too heavy, MAUI is broken and buggy, Avalonia is underwhelming, and WinUI 3 is an absolute nightmare.
> But the reality is they aren't expressive enough for modern UIs Other than web tech, what actually is expressive enough?
Earlier quoted context omitted.
Pluggable allocators. Allocators are passed to functions as arguments, the caller decides exactly how memory is managed. Maybe not "new" in idea, but "new" in being consistently applied everywhere in language & libraries.
Already Turbo Pascal for MS-DOS had a custom allocator API for its runtime. All modern C++ collection types have allocators as type parameters, and this was already a thing in the compiler frameworks like OWL during the 90's.
var list = std.ArrayList(i32).init(allocator);
fn parseJson(allocator: Allocator, input: []const u8) !JsonValue
Sorry sir, I have a nostalgic fondness for C++ - it was my first language, but it just doesn't compare for flexible allocation convenience compared to Zig.
Earlier quoted context omitted.
Do you think by now C# has left Java behind in features and performance?
Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.
Earlier quoted context omitted.
Notice you point out features that were easy to add during the beginning where there was no concern of backward compatibility? Now that java is porting value classes to mainline and we might have them soon, and planned operator overloading through type class, I believe java approach is making careful design choices that are semantically sound, rather than adding features that create edge cases such as boxing invarian…
So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.
No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.
Earlier quoted context omitted.
I see no evidence the user is confused, they said they wished the syntax were similar to TS. Though they're not the same thing, they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead. > Well, we disagree. Most people here know the set theory definition of unions. It's simply a niche use, compared to the usual CS definition, which is the one used in the original article…
> they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead No this makes no sense at all. Set theoretic types don't use special constructors, there is no way to make them look remotely similar. He is clearly not aware that these are different kinds of unions. > They do. Nope, precisely because they are less common. You yourself also clearly also didn't understand the dif…
You have come into a room full of CS practitioners to announce to them that you alone understand what unions are. Never mind fifty years of industry practices and nomenclature - never mind the fact we all already know set theory and unlike you don't confuse set theoretic unions with tagged unions - all that can now be set aside because you discovered set theory last week and now no one understands unions except for you.
Can't wait for next week when you discover some new band, and you'll be in here telling us how no one gets music except for you. :P
Earlier quoted context omitted.
Do you think by now C# has left Java behind in features and performance?
C# was always better than Java as a language. The strength of Java is the ecosystem, and Java being open source and cross-platform from the beginning.
Finally C# will have a more idiomatic way to represent this classic code example from “The Daily WTF” in 2005 — enum Bool { True, False, FileNotFound }; See https://thedailywtf.com/articles/what_is_truth_0x3f_
What about Microsoft's own "MsoTrioState"? https://learn.microsoft.com/en-us/dotnet/api/microsoft.offic... enom MsoTrioState { Toggle, Mixed, True, False, CTrue };
Earlier quoted context omitted.
Already Turbo Pascal for MS-DOS had a custom allocator API for its runtime. All modern C++ collection types have allocators as type parameters, and this was already a thing in the compiler frameworks like OWL during the 90's.
Zig makes allocation an explicit runtime concern: var list = std.ArrayList(i32).init(allocator); where allocator is a runtime value implementing the allocator interface. fn parseJson(allocator: Allocator, input: []const u8) !JsonValue Zig forces the caller to decide since allocator is part of the function contract. And this is consistent everywhere in Zig. Effectively speaking, this is universal, explicit & mandated…
The irony to argue about manual memory management ergonomic, when code is written by agents.