111–120 of 151 posts
Hot take but I wish they’d start a new lang in the spirit of what’s happening in swift/Kotlin instead of evolving C#. I use it everyday. I love the new pattern matching, it simplifies a lot of gnarly reflective type checks and feels good. Records are nice too. I see discriminant unions are coming soon. But they’re painting themselves into the corner in terms of syntax and overcoming OOP defaults. A fresh start would…
Earlier quoted context omitted.
.Net itself is fundamentally OOP. Lambdas are implemented as classes with an Invoke method, F# enums are implemented as classes with variants as subclasses, etc. So if "overcoming OOP defaults" is the goal then making a new .Net lang that isn't OOP doesn't achieve much. So it would have to be either be a new native language, or a new managed language that also comes with a whole new managed runtime. For the former, R…
You know we used to call it Microsoft Java, right? I mean, going beyond the sarcasm, ultimately C# copied most (if not all) the Java design decisions: * OOP baked in (more like hardcoded into the execution model) * Heavyweight VM that needs to be installed apart, that tries to achieve better performance by using way more resources (runtime/VM that needs to recompile the code multiple times instead of ahead of time co…
VM doesnt have to be installed, you can deploy the single file app with it + there is AOT too
Btw. C# has reified generics
Earlier quoted context omitted.
> I wish people would embrace it like Elixir has been embraced. F# is a lot more popular than Elixir.
I'm not sure about that given the amount of jobs I have had and found in Elixir, which also has a more vibrant ecosystem. I have strong confidence that I could get another Elixir job. I would be surprised if I could even locate an F# job.
I’m sure some false positives, but I doubt enough that brings the F# count lower than that for Elixir.
ymmv
To everyone not closely following .NET and think it’s some enterprise thing focused on Windows: It’s fully cross platform now and works flawlessly on Mac/Linux for backend work. Entity Framework Core has become a great ORM that’s getting better every year. It’s in a great place to develop your next startup/project in. I’ve switched from Python to C# last year and couldn’t be happier.
You get consistent ecosystem with top tooling, strong standard base class libs and good UX.
Earlier quoted context omitted.
.Net itself is fundamentally OOP. Lambdas are implemented as classes with an Invoke method, F# enums are implemented as classes with variants as subclasses, etc. So if "overcoming OOP defaults" is the goal then making a new .Net lang that isn't OOP doesn't achieve much. So it would have to be either be a new native language, or a new managed language that also comes with a whole new managed runtime. For the former, R…
Yeah I argree, making a new lang for a vm runtime doesn’t make as much sense when rust is right there, because the vm itself has a lot of baggage and limitations (OOP baked in, start up time,etc). The dotnet team seems to be moving mountains to squeeze more performance out of the VM, which is awesome, but how much further can it go?
How well are F# and C# supported on the Linux platform?
At work our C# codebase never touches Windows (all developers except me use MacOS, I am testing Linux). Production is Linux. We all use Rider, which pretty good (but extremely crashy when debugging). Probably in the region of 500Kloc.
Earlier quoted context omitted.
Last time I talked to them, the entire f# team at Microsoft was still fewer than 10 people. Language features, lsp modules, visual studio support, etc. They do technically exist but it's far from a focus at ms.
I hope that changes. F# is a very nice language to use. I hope that it survives and grows. It's my favorite functional first language.
Earlier quoted context omitted.
You know we used to call it Microsoft Java, right? I mean, going beyond the sarcasm, ultimately C# copied most (if not all) the Java design decisions: * OOP baked in (more like hardcoded into the execution model) * Heavyweight VM that needs to be installed apart, that tries to achieve better performance by using way more resources (runtime/VM that needs to recompile the code multiple times instead of ahead of time co…
Boring comparison tbh. VM doesnt have to be installed, you can deploy the single file app with it + there is AOT too Btw. C# has reified generics
Ocaml has a VM which is included by default (70kb), and can also compile to native (skip the VM altogether). It has been like that since at least 2002 (the first time I checked it, probably before that).
Haskell has HKT, which generalize generics.
Java and C# share 95% ideas in comparison to stuff outside Java/C#. That's why the comparison is boring: there is very little to compare.
Earlier quoted context omitted.
Boring comparison tbh. VM doesnt have to be installed, you can deploy the single file app with it + there is AOT too Btw. C# has reified generics
Wow! Big differences! Ocaml has a VM which is included by default (70kb), and can also compile to native (skip the VM altogether). It has been like that since at least 2002 (the first time I checked it, probably before that). Haskell has HKT, which generalize generics. Java and C# share 95% ideas in comparison to stuff outside Java/C#. That's why the comparison is boring: there is very little to compare.
Another differences
Approach to async
Approach to ecosystem fragmentation
Approach to GCs
In general people would argue that C# > Java, but JVM > CLR
Earlier quoted context omitted.
First class. I would wager that most new .NET projects are primarily targetting Linux for deployment.
Not really, plenty of VS tooling doesn't exist on VS4Mac nor VSCode. GUI frameworks don't consider Linux a deployment target, not even MAUI with its Xamarin heritage. Due to its Windows original focus, lots of libraries still rely on Win32, COM and other Windows specific issues. This also inhibits most big name CMSs, which still rely on .NET Framework, e.g. Sitecore, SharePoint, Dynamics,.... Targeting Linux containe…
The Rider licensing cost is negligible when compared to a developer's compensation.