271–280 of 300 posts
Earlier quoted context omitted.
Winforms is better than ever. You can use it with .NET10 and WebView2 is a thing now.
Responsive UI, fluent styling, are they straightforward now, or do you still need to jump hoops?
Earlier quoted context omitted.
> I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else. Operator overloading increases consistency. Instead of having int a = b + c; CustomNumberType x = y.add(z); you have int a = b + c; CustomNumberType x = y + z;
The problem with operator overloading is it makes things confusing when mixing types and let's programmers write confusing code. Person x; Job y; CustomType z = x + y; WTF is Z? Is the argument, anyway, I support operator overloading.
Take a person, add a job, you get an Employee or EmployedPerson. Person.add(job).
I agree overloading can create footguns, but domain concepts should make a lot of sense in context when basic arithmetic operations are performed on them. Party = Meeting + Booze.
Custom operators are a big assistance for DSLs, and overloading can also aide their creation and elegance. Part of the “awesome but don’t be a jerk about it” toolbox.
Earlier quoted context omitted.
Do you think by now C# has left Java behind in features and performance?
Speaking as somebody that spent 2yrs as a full-time Java dev before returning to the Microsoft stack: yes. Java’s Optional sucks compared to how C# (and Kotlin) implement support for nullable types. C#’s async/await syntax is better than… however the hell Java says to implement asynchronous calls now (Thread? CompletableFuture? idk, I never figured it out). ffs, Java doesn’t even have support for string templates yet…
Earlier quoted context omitted.
I see this reason a lot but what are some actual examples of what is lacking in the .NET ecosystem vs. Java?
Lots of implementations and industry standards, many mix Java with OpenJDK. It is not, Java is like C, C++, JavaScript and co. There are many implementations, the language and runtime are evolving by industry partners, you get bare metal implementations with real time GC like PTC and Aicas (doing AOT for decades), JIT caches, cloud based JIT compilers (OpenJ9 and Azul), pauseless GC, an LLVM like compiler development…
I know it's not a popular opinion but I don't see why they should bother. There are already multiple implementations that serve different use cases, but they are slowly converging into one. There are more languages+runtimes which do not have formal specifications than those that do, and that's okay! Fragmentation is not a good thing.
Earlier quoted context omitted.
> I think operator overloading would be a very bad feature for an enterprise language like Java which needs to be consistent above all else. Operator overloading increases consistency. Instead of having int a = b + c; CustomNumberType x = y.add(z); you have int a = b + c; CustomNumberType x = y + z;
The problem with operator overloading is it makes things confusing when mixing types and let's programmers write confusing code. Person x; Job y; CustomType z = x + y; WTF is Z? Is the argument, anyway, I support operator overloading.
Earlier quoted context omitted.
You have at least two options: 1. Argue from ignorance. Never try unions in any other programming languages and completely disallow their use in C# codebases that you participate in. 2. Try them out and adopt an informed opinion. You may even choose to remain in ignorance until someone wastes their own time trying to convince you. But it isn't my job or desire to teach someone who won't put in the effort to learn for…
its not your job to comment spitty replies either but yet you volunteer that time, when you could have been productive instead of whatever the fuck this shit is. My primary concern with this pattern versus exceptions is calling code can simply discard the resulting problem.
Except with a Result type the fact that an exception can occur and should be handled in the first place is explicit.
The problem if anything is that you MUST say something about the error case, despite the common scenario being “pass it forward” — the same reason exception do this by default. Which is also why rust for example special cases Result with the ? operator to do exactly that
Earlier quoted context omitted.
Hi there! C# language designer here, and one of the people working on unions. Boxing is not something inherently to be avoided. It actually can work better in many (most?) use cases, and avoids a lot of problems that non-boxing approaches often cause (like tearing and copy costs). It's try that the non boxing pattern could be implemented by us. And it's very reasonable that that is something we may do post this relea…
Can we expect that the C# development team works with the F# crowd, to make this copied feature work on both?
Earlier quoted context omitted.
Do you mean the implicit nullable types? Now that you can make nullable explicit instead I really don’t have much issues with it. It is part of the type system, as it should, and you have null coalescing operators. Is it still problematic or are you dealing with older codebases where you cannot set the nullable pragma?
Yes, all that stuff. I try to stick to F# where no special syntax is required for missing values (via Option ).
Earlier quoted context omitted.
Yes, all that stuff. I try to stick to F# where no special syntax is required for missing values (via Option ).
Given that they already made the billion dollar mistake, I find their handling for nulls the best possible thing they could do at this point. I’d hardly call it crazy — rather, it’s exceedingly pragmatic.