Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Official proposal for Type Unions in C#

github.com

Post reply on HN
Print view View original

251–260 of 315 posts

Re: Official proposal for Type Unions in C#

#251

Post by darby_nine »

JamesBarney wrote: post #184
tkubacki wrote: post #174

Earlier quoted context omitted.

I went from C# to JVM/gradle and have the opposite experience. 1) default C# IDE is junk compared to IntelliJ 2) Gradle give you insane level of control over project you can even build dynamic template tasks shown in IntelliJ UI using Kotlin/Groovy 3) JVM ecosystem is much bigger and default framework SpringBoot is ready to use with houndreds of integrations which are either non existent or hards to use in .NET as op…

What makes intellij so much better than visual studio or vscode?

vscode is basically a bunch of different tools duct taped together and, as a result, constantly breaks. It's a lot closer to being emacs than it is to being an IDE (and I say this as a fervent emacs user outside of large projects). Even with the language servers, IDE functionality is going to be playing catch-up for the next decade. Intellij definitely has a leg up there.

I've never used visual studio before so I assume the comparison is going to turn up a different set of issues. However, being tied to windows is probably not a good thing in the long term.

Re: Official proposal for Type Unions in C#

#252

Post by giancarlostoro »

lmm wrote: post #195
giancarlostoro wrote: post #178

Earlier quoted context omitted.

You really should google before you make remarks... I'm also going to ignore the widely distributed remark because it is ridiculous. > No-one's writing a database server RavenDB, which can be run in a cluster, and uses less CPU (and I've read memory) than MongoDB itself. There's also a recent C# based redis drop-in replacement that outperforms redis. See more: https://github.com/quozd/awesome-dotnet?tab=readme-ov-fil…

> RavenDB Ok, that actually sounds interesting. Still haven't heard of anyone using it, and closed-source makes it a non-starter, but I'm vaguely interested. Even then though, sounds like their client libraries are only .NET? > As for identity, you sound really silly when you consider it is literally built-in to ASP .NET itself, and can be expanded upon to your hearts desire, plus there's no shortage of available ide…

> And look how that worked out for them.

Worked out pretty well to be fair, their old UI actually worked perfectly on Linux via Moonlight. Moonlight was more usable than Flash on Linux which was an unstable mess.

> There are plenty of linters for C#, sure. But no-one would write a general linter in it. It was an example that came to mind because that was how Facebook first started adopting OCaml - a linter is a small standalone tool, so it's an ok place to experiment with a new technology stack.

Except ReSharper lints for other things too.

> I mean the equivalent of Bitbucket Server or GitLab, the thing you'd run to host your own source repos internally.

That was CodePlex, there's also Azure DevOps? Which does all the things BitBucket and GitLab do and probably more? It is arguably poorly named in my view, since I've heard managers confuse "DevOps" and "Azure DevOps" by using the term interchangeably.

Re: Official proposal for Type Unions in C#

#253

Post by conor- »

arnath wrote: post #206

As a long time C# dev, I feel like I’m missing something about this proposal. The use case for this doesn’t seem well defined to me. Could someone give me a real world example? I’m pretty sure you can implement the example in this proposal by declaring an empty interface and having some record classes that “implement” it. Does that lose something that I’m not seeing?

This[0] lib implements F#-style discriminated unions. The way I've used it is to make my outer layers return "Result" types that wrap the DTO, error, etc. under one umbrella. It allows for pattern matching your results which makes error handling easier and also allows your models to evolve over time without changing your function signatures at the edge.

[0] https://github.com/mcintyre321/OneOf

Re: Official proposal for Type Unions in C#

#254

Post by radicalbyte »

giancarlostoro wrote: post #92
radicalbyte wrote: post #78

Earlier quoted context omitted.

C# for real work, Python for scripting or specific use-cases where it has excellent library support & Golang if I need something closer to C or very lightweight or easy for people to understand. Rust is interesting but the compile times aren't great.

I use Python for real work too, but my current employer does not use it as much.

It's too dynamic/slow for me and the dependency system is a mess to the point where the entire Javascript world is better. Actually I forgot TypeScript, been using that for more than a decade now. So much better than the dark old days of JavaScript :)

Re: Official proposal for Type Unions in C#

#255

Post by darby_nine »

sanex wrote: post #199
vips7L wrote: post #172

Earlier quoted context omitted.

This is definitely all just a learning curve on how to do this. None of this is accurate at all. - IntelliJ knows exactly what version of Java you want to run and develop against. - Async is also trivial. Just fire off a virtual thread. - it sounds like your company just picked a bad orm. Any good one is going to escape sql injection when binding variables. You are using binding right? If you to “write it in Java” th…

I'm not worried about SQL invitation so much as I'd rather just query my C# objects instead of writing raw SQL. Yuck.

Pretty much every language has some kind of monad-based query builder. The standardized syntax is nice though.

Re: Official proposal for Type Unions in C#

#256

Post by Bognar »

freedomben wrote: post #164
Buttons840 wrote: post #157

Earlier quoted context omitted.

I'm a Linux user who prefers open-source tools. I not a fan of Microsoft's programs, tools, editors, etc. What would you suggest I do to be productive with C#?

It's remarkably disappointing to see this question downvoted. I had the same thought, but this makes me wonder if it's just a bad culture fit from the start. I've been Linux-only now for 15 years and haven't used an IDE in well over 10. I use vim (neovim now) exclusively. Given my characteristics, should I just squash my curiosity and do a pass on C#? Do C# people not see value in open source? Is there low tolerance…

C# has an official language server and an unofficial one (that unfortunately seems less maintained now). It works just fine with neovim.

Funny enough, it's the efforts of Omnisharp and the VSCode team that has so significantly improved the experience of using various other languages in open source editors due to the creation of LSP.

Re: Official proposal for Type Unions in C#

#257

Post by tombert »

sideeffffect wrote: post #243
tombert wrote: post #3

Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would b…

> Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines This is a weird take, given that Java has had ADTs for years Records https://en.wikipedia.org/wiki/Java_version_history#Java_16 Sealed classes https://en.wikipedia.org/wiki/Java_version_history#Java_17 And pattern matching for almost a year https://en…

Most of my jobs until recently have been using Java 11, so I didn’t get to use these things.

Re: Official proposal for Type Unions in C#

#258

Post by jerf »

arwhatever wrote: post #132
jerf wrote: post #90

Earlier quoted context omitted.

The reason why it matters less than people intuitively think is precisely that it matters a lot less when you're in full control of both the operations and the types anyhow, and that's actually the most common case. Generally you are "composing" in library code, that is, just using it, not extending the library itself. When you are extending, you actually want to choose the correct thing depending on what you need. G…

Sum types are not a new discovery for me, personally.

And I've known about them for, let's see, at least fifteen years, and I've definitely gotten over my "oh my gosh I must use these for everything" phase.

Though I do wonder as well how many people encountered them in their "spread their wings" phase and happened to be learning about sum types just as their general programming skill was leveling up in general, and conflate the two. When you learn how to use both skillfully, I really feel like the differences collapse quite a bit. I see so, so much bad code with type-based extension, but it's not because they're using type-based extension, but just that it's bad code, regardless. Of course bad type-extension code is worse than good sum types code, but there's still times and places for both approaches when you know what you're doing with both.

Re: Official proposal for Type Unions in C#

#259

Post by consteval »

LAC-Tech wrote: post #136
lyu07282 wrote: post #120

Earlier quoted context omitted.

> What would it take for C# and/or others to "do OO well"? Multiple inheritance. (j/k)

Unironically this. Having "interfaces" and "abstract classes" is just a kludge, multiple inheritance covers all of this with one language construct. The "diamond problem" is a C++ issue, every other language solved it.

The "diamond problem" isn't a C++ problem. C++ solved it with virtual inheritance.

Also C++ has exactly what you want. No interfaces, multiple inheritance. People don't utilize it unless it's a GUI lib.

Re: Official proposal for Type Unions in C#

#260

Post by jaredpar »

jasomill wrote: post #250
zamalek wrote: post #2

> The interior layout of the union struct is chosen to allow for efficient storage of the data found within the different possible member types with tradeoffs between speed and size chosen by the compiler. Having _attempted_ (and being bitten by) far too much black magic with C# unions in the past (using FieldOffset), there is an unfortunate situation here: aliasing a pointer/ref value and value is UB. This means tha…

Not UB, illegal. Per ECMA 335, II.10.7: It is possible to overlap fields in this way, though offsets occupied by an object reference shall not overlap with offsets occupied by a built-in value type or a part of another object reference. Per .NET 8.0: using System.Runtime.InteropServices; var s = new S { Bar = "Baz" }; [StructLayout(LayoutKind.Explicit)] public struct S { [FieldOffset(0)] public UInt64 Foo; [FieldOffs…

> from the AOT compiler, but none from the C# compiler.

The C# compiler has very little knowledge of `[FieldOffset]`. It's expected that developers understand the runtime implications of this.

Post reply on HN