Live data from Hacker News

Official proposal for Type Unions in C#

github.com

71–80 of 315 posts

Re: Official proposal for Type Unions in C#

#71

Earlier quoted context omitted.

C# is great, likely the best mainstream programming language nowadays, but its in the hands of microsoft and microsoft didn't really care much about building a community or getting it to work natively in other OSes/toolchains. Its a shame, they even had a second change when Oracle bought sun and no one knew what was going to happen with Java, but fumbled that as well.

A very common modern setup is PostgreSQL, C#/.NET, Linux & using JetBrains Rider for the IDE. You don't have to go all in Microsoft to use C#, F# or .NET. Also .NET has been about "run everywhere on any platform" as their tagline for quite a few years now. They have had plenty of community fumbles without question. I can't speak to those though. I've seen lots of vocal high up Microsoft employees try to win those fig…

    A very common modern setup is PostgreSQL, C#/.NET, Linux & using JetBrains Rider for the IDE
You just described the startup I'm at. All devs are on Arm64 MacBooks and we deploy to Arm64 AWS T4g Linux instances. I'm all VS Code, others are primarily Rider.

.NET is a highly underrated platform for backend; it always puzzles me when teams think about moving from TypeScript to Rust or Go instead of C# because it seems a much smaller leap from TypeScript.

Re: Official proposal for Type Unions in C#

#72
post #38

Earlier quoted context omitted.

It's impossible for a .NET library to not work with F#. It's very possible (and even likely) for a .NET library to prevent you from writing idiomatic F#. You're right that it's a second-class citizen.

> It's impossible for a .NET library to not work with F#. This isn't true, C# has been adding new ABI features that didn't interact correctly with F# until the compiler and tooling catched up. For example, the spanification of C# was a huge a pain point and it still is when it comes to tooling.

TIL. Have links to any details about this? I'm very curious!

Re: Official proposal for Type Unions in C#

#73

Earlier quoted context omitted.

F# has it's own warts, tooling isn't as polished, stuff like type providers sound really cool but suck in practice IMO, file ordering being relevant for compilation is bleh... Every time I try to use it I'm left with a feeling it's not worth the hassle over C#. C# has been quite nice for 10 years and they keep improving consistently with every version.

The language itself is nice, the code bases that companies produce with it is not, and sadly that reputation plays into your decision to choose a career stack. You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project. I envy people who only do hobbyist C# so get to work on code bases that have all the…

I definitely dislike most C#/.NET developers/community (every time mediator is mentioned I want to stab myself) and would rather work with people in F#/FP.

But when you have to work on "diverse" development teams having some sort of patterns established (flawed as they are) brings some order to the insanity.

Re: Official proposal for Type Unions in C#

#74

Earlier quoted context omitted.

F# has it's own warts, tooling isn't as polished, stuff like type providers sound really cool but suck in practice IMO, file ordering being relevant for compilation is bleh... Every time I try to use it I'm left with a feeling it's not worth the hassle over C#. C# has been quite nice for 10 years and they keep improving consistently with every version.

The language itself is nice, the code bases that companies produce with it is not, and sadly that reputation plays into your decision to choose a career stack. You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project. I envy people who only do hobbyist C# so get to work on code bases that have all the…

Out of interest, what "patterns from the .NET framework era" do you think don't work well in .Net core?

( I'm someone who deals all day with legacy .Net framework projects, mixed with the kind of mix of .Net core 3, .Net 6, .net standard 2.0, and .Net 8 projects that you'd expect from a 20+ year old company with 260+ projects. And yes, I too envy hobbyists at time. )

Re: Official proposal for Type Unions in C#

#75
post #72

Earlier quoted context omitted.

> It's impossible for a .NET library to not work with F#. This isn't true, C# has been adding new ABI features that didn't interact correctly with F# until the compiler and tooling catched up. For example, the spanification of C# was a huge a pain point and it still is when it comes to tooling.

TIL. Have links to any details about this? I'm very curious!

Stuff like Roslyn analysers, code generators and interceptors, only take C# semantics into account, the first one also works with VB.NET.

Since its introduction that CLR has the notion of CLS, the Common Language Subset, that any language targeting the CLR should be able to understand.

Anything in the MSIL or metadata, that isn't part of that, requires additional effort from the respective language to be able to expose those features, and many of the more recent improvements, are more in the sense of CLR meaning C# Language Runtime, than Common Language Runtime.

Re: Official proposal for Type Unions in C#

#77
post #65

Earlier quoted context omitted.

> I definitely recommend giving F# a try. I think it's an extremely underrated language. Do you have any recommendations for people who do not have C#/.NET experience who want to rip their toes in F#? The last time I tried the language I bumped my head on the .NET parts. :/

Out of curiosity, what confused you about the .NET stuff? I didn't have any .NET experience going into F# either [1] and I didn't find it too hard to pick up the .NET stuff. For the most part I didn't need most of the built in .NET libraries; the F# stuff was fine, but the ones I ended up using a lot were the threadsafe libraries for when I needed mutation across threads. ConcurrentDictionary was one I used an awful…

I was working on a Linux laptop and the installation process wasn't immediately clear. Some of the frameworks I looked at didn't target the most recent .NET version so I had to install multiple versions. Once I had it installed, I had compilation failures with a project that was built on Windows. The team that ran it wasn't sure what was happening.

Also, having the documentation split between the F# parts on one site and the .NET parts on another site was a bit of a pain.

It might have gone better if I was starting with a book instead of picking docs off the web.

Re: Official proposal for Type Unions in C#

#78

Every time the question of preferred programming languages comes up, I'm usually in the extreme minority with my preferences being Rust (for small/fast) and C# (for productive and easy, where GC is acceptable), a combination that doesn't seem to appeal to too many people. But for the projects that fall right about in the middle where it could go either way and I could see either language working, I almost always pick…

For me its C# and Python, though I like Rust, D and lately been getting into Nim. I want to like Lisp, but its just not something I see someone paying me to work in.

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.

Re: Official proposal for Type Unions in C#

#79

Earlier quoted context omitted.

A very common modern setup is PostgreSQL, C#/.NET, Linux & using JetBrains Rider for the IDE. You don't have to go all in Microsoft to use C#, F# or .NET. Also .NET has been about "run everywhere on any platform" as their tagline for quite a few years now. They have had plenty of community fumbles without question. I can't speak to those though. I've seen lots of vocal high up Microsoft employees try to win those fig…

A very common modern setup is PostgreSQL, C#/.NET, Linux & using JetBrains Rider for the IDE You just described the startup I'm at. All devs are on Arm64 MacBooks and we deploy to Arm64 AWS T4g Linux instances. I'm all VS Code, others are primarily Rider. .NET is a highly underrated platform for backend; it always puzzles me when teams think about moving from TypeScript to Rust or Go instead of C# because it seems a…

[dead]

Re: Official proposal for Type Unions in C#

#80
post #65

Earlier quoted context omitted.

Out of curiosity, what confused you about the .NET stuff? I didn't have any .NET experience going into F# either [1] and I didn't find it too hard to pick up the .NET stuff. For the most part I didn't need most of the built in .NET libraries; the F# stuff was fine, but the ones I ended up using a lot were the threadsafe libraries for when I needed mutation across threads. ConcurrentDictionary was one I used an awful…

I was working on a Linux laptop and the installation process wasn't immediately clear. Some of the frameworks I looked at didn't target the most recent .NET version so I had to install multiple versions. Once I had it installed, I had compilation failures with a project that was built on Windows. The team that ran it wasn't sure what was happening. Also, having the documentation split between the F# parts on one site…

Ah, yeah, the non-windows stuff was pretty clunky for awhile, but I do feel like it's gotten a bit better at the command line support.

FWIW I think it works fine with Nix, so if you're not opposed to using that package manager it should pretty trivial to get different versions working with a nix shell and/or flake.

Post reply on HN