71–80 of 215 posts
I love it, but I see a downside, though: unions are currently implemented as structs that box value types into a Value property of type object. So there can be performance implications for hot paths.
I haven't read this in detail but I expect it to be the same kind of sealed type that many other languages have. It doesn't cover ad-hoc unions (on the fly from existing types) that are possible in F# (and not many non-FP languages with TypeScript being the most notable that does).
Earlier quoted context omitted.
> Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years If they actually put effort in F#, it would have reached "unteachable" state already :)
Haha, yeah, maybe :) I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes. Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never…
So is it a F# issue or inherent to functional programming?
It's trying to generalize - we might have exactly one T, fine, or a collection of T, and that's more T... except no, the collection might be zero of them, not at least one and so our type is really "OneOrMoreOrNone" and wow, that's just maybe some T.
Earlier quoted context omitted.
Haha, yeah, maybe :) I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes. Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never…
My knowledge on functional languages is limited, but as I understand it, it’s possible to formulate expressions that are basically NP problems? And hence impossible to speed up? So is it a F# issue or inherent to functional programming?
Looking at it, the MS docs contain something about this exact topic, so maybe it's better nowadays: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Sadly, I haven't used F# for years at this point so I can't speak to the current state.
Earlier quoted context omitted.
In isolation, yes, I agree with you. But in the context of the cornucopia of other "carefully evaluated" features mixed into the melting pot, C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language. No thanks.
If it’s not for you I guess that is ok. But from your comment I would also deduct that you never professionally used it. After so many different languages it’s the only one I always comeback to. The only things that I wish for are: rusts borrow-checker and memory management. And the AOT story would be more natural. Besides that, for me, it is the general purpose language.
Earlier quoted context omitted.
It is a strongly-typed query generator?
I meant code generators like sqlc
> Is it good at the wrong thing?
Earlier quoted context omitted.
Yup, the commercial libraries. That's pretty big. It's nice the standard library has lots of goodies, but I doubt many projects in reality are zero-dependency (The amount of times I hear "the standard lib is great!" seems more to attempt to defend the plethora of commercial libraries, more than anything) The community feels rather insular too? The 9-5 dayjob types with employers who don't understand or embrace open s…
> And is Postgresql a 2nd-class citizen? No, it is not. Microsoft maintains the Npgsql project[0] and I say that it is a very capable, feature rich adapter. I have not used C# with SQL Server in almost a decade. [0] https://www.npgsql.org/
Earlier quoted context omitted.
I meant code generators like sqlc
Then this goes back to your question: > Is it good at the wrong thing? No, it's good at the right thing which is allowing developers to write type-safe SQL queries using C# at the application layer versus writing SQL that gets translated into C#.