91–99 of 99 posts
Earlier quoted context omitted.
(he types from his android phone)
Not a desktop. :) ChromeOS is closer to counting, but while it's technically Linux, that's really just an implementation detail in the same way it would be for a mall kiosk. It's hard to do actually Linuxy things with it that desktop Linux enthusiasts envision.
Could be! Depends if MS starts putting some more money behind it, including marketing. They're pretty deep in an AI-everything spiral right now though. I'm a Clojure guy, but the ML family (specifically OCaml and F#) have always interested me as another branch of functional programming. I started out in the before times as a .NET Programmer (VB6 -> VB.NET -> C#) and have toyed with F# a little since then. It's cool,…
I had a thought today, "when is Microsoft and/or Apple going to earnestly search out their next Steve Jobs?" And I think the answer is that guys like Bill Gates and Tim Cook are too proud, too prideful to admit they are not kickass rockstars of tech, too jealous to find and cultivate their next super-figurehead. Instead they are safe and lame. Microsoft needs a non-lame, non-MBA, engineer to take control and inject s…
F# is a chimera of a language. The functional parts of the language are nicely designed: no nulls, discriminated unions (ADTs), you write simple functions in simple modules and there is nothing that is too clever to understand: it's very pragmatic. Then there is a whole lot of stuff like inheritance, classes, interfaces, nulls mainly there for dotnet interoperability that gets very ugly very fast. There are way too m…
Dotnet does have some minor annoyances (exceptions being one) but gives the ability to deploy everywhere, GUI apps on all platforms, web, backend is fantastic. Lack of native GUI apps would be the main deficiency for me from Gleam, plus the fact that they have decided their community is explicitly politically woke-liberal.
Rust has been a fantastic addition to the language ecosystem, but recursive types, which are the bread and butter of ML-family code, are just too hard to write in Rust.
Speaking as a C# developer, who had in the past wanted to learn F#, but never got very far. What discourages me every time: - C#'s good enough. Nothing's stopping you from writing functionally-oriented code in C# (and I do prefer that over traditional "enterprisey" object-orientation.) - It's relatively difficult to have a codebase that is partly in C# and F# for incrementally trying things out. (I understand this is…
Ordinarily in a mixed codebase, the F# comes nearer the start, with C# depending on F#. That's because C# has lots of glue code to connect to the outside world (xaml, cshtml, EF...) and this is less straightforward to migrate to F#. The only problems with mixing languages is when you want F# in the middle of some project where it depends on some parts of the project and other parts of the project depend on it. But if you can identify something independent in a C# project and extract that out, you have already made the project simpler.
You can ignore async and use task. You can use async in the (very rare) cases when you don't want a hot task. You can also ignore Option and use ValueOption all the time. The struct types are new and have meant that F# does not have a performance deficit.
ValueOption is just better than Nullable since Nullable restricts to value types only. Resulting in Nullable composing terribly and requiring ad-hoc code everywhere.
I recently left a c# shop in finance. My background c/c++. I was very interested to see if c# was less work: easier to write and build. I was not impressed by what I saw - it was junk code. One of the major errors was writing apps as MS services which dragged in tons of MS OS junk. I cannot totally blame c#; i think the staff there were not engineers but more guys doing stuff. The code was complex; replete with async…
C++, const modifier, verbose for more correct code (less mutable state, etc.) Rust, mut modifier, verbose for less correct code
C/C++, bothersome to have tight scopped values, due to split of expression & statement ML languages, nesting of let bound values, everything is tight scoped, even recycling local names non destructively via shadowing.
C#: mostly, all flaws of C/C++/Java F#: mostly all right things of ML, OCaml, Rust
F#: Structural comparison of ML types from day 1 C#: just adding records recently; most of libraries, idioms, and semantics geared towards reference comparison
idioms
C#: mainly OO, noisy syntax, low expressivity (constructing immutable values out of generators or expressions), lots of navigation due to adhoc things needed to be named, poor type inference F#: data & functions, concise end non noisy syntax, high expressivity (list expressions, computation expression values), less scrolling & navigation, object expression rather than defining type used once, great type inference (less noisy diff on refactorings)
etc.
So average F# codebase is by construct, more sound, than average C# codebase, however F# code quality may be poor, and C# great, still, more soundness in F#, IMHO.
I tried F# when we were building out a scraper at a startup. After a bit, I realized that must of the things could also be done in C# and ended up using C# instead because it's just a bit more accessible. F# looks neat, but C# has a lot of parity at this point on some of the core selling points IMO.
average C# codebase looks different depending language version idioms, not so in F# (because initial release already had >80% of things that C# today doesn't even have and won't be able to fix).
But C# is great too, nonetheless.
I would be very reluctant to use it because of the fear that at some point Microsoft just kills it. You have to wonder why they are keeping it alive so long as they are probably getting not much value out of it (some people here say they are using it as a testbed for functional features in C# but I don't believe this - I guess the C# team has enough resources to do their explorations on their own). I guess if Don Sym…
Earlier quoted context omitted.
I'm (basically) aware of the details (String, &str, OsString, OsStr, CString, CStr, "star" c_char, and probably some others ("star" const i8, &[u8], ???), and you and I have had this conversation a while back when I had a stronger interest in Rust. I'm not sure if you're correcting me, but you're basically confirming what I said. As for only needing them when you need them, how could it be otherwise? :-)
One thing I would say is if you're writing a normal Rust application or library and do not care about c interoperability, you could get by without being aware of anything other than the first 2 types. However in Fsharp you are forced to learn about all other ways of doing things, plus how C# does things, because it is almost impossible to do anything useful without interoperating with C# and dotnet
Earlier quoted context omitted.
It’s not so much that you’ve made any mistakes or omissions as much as all of these things do different, similar things, but don’t do the exact same thing. For example, an array and a tuple are both aggregate types, but arrays store multiple value of a single type, and tuples store multiple values of the same type. Some of these do boil down to “named or anonymous” but that’s also two different things.
More power to you for defending or explaining Rust, but the context of the conversation is comparing multiple "record" types in C# as "bad" to the "one way" in Rust. It's hard to argue that Rust has a simpler story than C#. There are a lot of almost orthogonal features one might choose for a record type: Accessor: rec.x, rec.0, rec[0], match Constant vs Mutable Reference vs Value Nominal vs Structural/Anonymous typin…
I’m not trying to pass judgement on C#. I just don’t see a lot of these things as being that similar to each other.