51–60 of 300 posts
I mean yes, but also: uh-oh. I'm looking forward to reading some code that is even more confusing than the code I'm already reading. Not entirely convinced that I see the usecase that makes up for the potential madness.
Earlier quoted context omitted.
I think "what problems do they solve that I can't already solve" is the wrong way to look at it. After all, ultimately most language features are just syntactic sugar - you could implement for loops with goto, but it would be a lot less pleasant. I think that unions aren't strictly necessary, but they are a very pleasant to use way of differentiating between different, but related, types of value.
Ok. I'm just trying to understand what code I'm replacing with them. Like I wanna see the before and after in order to gain the same level of excitment as other people seem to have for them. Often the explanations just seem rather abstract which makes it harder to appreciate the win, versus the hideous sort of code that might appear when they're misused.
"Make invalid states unrepresentable."
I mean yes, but also: uh-oh. I'm looking forward to reading some code that is even more confusing than the code I'm already reading. Not entirely convinced that I see the usecase that makes up for the potential madness.
2001: "Beating the Averages" (Paul Graham) [1]
2006: "Can Your Programming Language Do This?" (Joel Spolsky) [2]
Both of these articles argue for the thesis that programmers that have been deprived of certain language features often argue that they don't need those features since they are already comfortable working around the lack of said features.
It's a fancy way of arguing: you don't know what you're missing because you've never had it. Or, don't knock it until you try it.
Consider, is your argument a) I've never used it and don't see a need for it, or b) I've used it before and didn't get any benefit?
1. https://paulgraham.com/avg.html?viewfullsite=1
2. https://www.joelonsoftware.com/2006/08/01/can-your-programmi...
F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.
Haskell, OCaml, Erlang lead the way and Rust, Zig and Go get all the mindshare. I feel like its a common pattern for more experimental languages to pioneer features and other languages to copy the features and bring them to a C style syntax that the majority of devs are familiar with.
Earlier quoted context omitted.
An enterprise shop I co-op'd at was porting one of their apps from Xamarin to MAUI when I worked there, but certainly it doesn't have much mindshare (if any) amongst SE undergrads at my university.
Someone I know who works with .net says that there is still no replacement for full Visual Studio for development, which is Windows only.
I used to see some excitement around .net core several years ago. I haven’t heard or seen much in the wild. Is anyone using .net on systems other than windows nowadays?
It’s huge in the game dev world, with Unity and Godot. .net also had a reasonable community on mobile for a while thanks to Xamarin, but I cannot imagine that many people using it for new mobile projects in 2026 (outside of game dev I mean). It’s a very decent language (I mean C#) and runtime, I wish it had more market share in the startup world.
Godot was using Mono too but has since switched to .NET in version 4.
Still a great language and I hope Unity can hit their target to switch to .NET soon!
Earlier quoted context omitted.
ok, so what problems do they help me solve that I can't already solve? Is it just that we can make code more concise or am I missing a trick somewhere?
Simple example that I use often when writing API clients: In current C# I usually do something like public class ApiResponse { public T? Response { get; set; } public bool IsSuccessful { get; set; } public ErrorResponse Error { get; set; } } This means I have to check that IsSuccessful is true (and/or that Response is not null). But more importantly, it means my imbecile coworkers who never read my documentation need…
F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.
Is having a combination of F# and C# in a single codebase possible? Is it recommended?
I mean yes, but also: uh-oh. I'm looking forward to reading some code that is even more confusing than the code I'm already reading. Not entirely convinced that I see the usecase that makes up for the potential madness.
This is a classic debate in programming, literally: 2001: "Beating the Averages" (Paul Graham) [1] 2006: "Can Your Programming Language Do This?" (Joel Spolsky) [2] Both of these articles argue for the thesis that programmers that have been deprived of certain language features often argue that they don't need those features since they are already comfortable working around the lack of said features. It's a fancy way…
F# leads the way and C# slowly catches up, as always. Yet for some reason, C# still gets all the mindshare.
What types of problems are better solved in F# than C#? Is having a combination of F# and C# in a single codebase possible? Is it recommended?