I disagree about performance not being important. Once you start scaling, using a language that makes writing performant code can save you a lot on hardware costs.
I’m also amused to see that Ada is not being considered, despite ticking almost all boxes:
Strong type system (in fact stronger than f#!)
No need to manually allocate memory, unless you really want to
Entreprise-friendly (assuming that means “supported by a company”?)
Has higher-order functions ('access)
Making side effects explicit (you can declare packages as “pure”, ensuring they don’t have any state)
Sum types (variant records)
Lets you write performant code if you need to.
I’m not sure I would say Ada is the best entreprise language though. I doubt such a language exists.
A project manager is not just choosing a programming language, they’re also committing to the ecosystem around the language
First sentence in the “entreprise friendly” section. I think it’s safe to say that Ada is not remotely comparable to F# in this domain. I think it’s also clear that F# is more productive than Ada (not safer, just, you can do more in fewer lines); that echoes the paragraph about GC instead of manual memory management, and the one on FP.
they’re also committing to the ecosystem around the language
AFAIK the F# ecosystem isn’t that big, what’s really big is the C# ecosystem, which is made available through easy interop. But if interop is considered part of the ecosystem, the C ecosystem (and anything available through FFI, really) can be considered available to Ada as importing functions through ffi is as easy as function X (Y: Integer) return Z with Import, External_Name => X (yes, this supports gnarly stuff like C++ exceptions).
There’s one key difference: Both F# and C# rely on the underlying .NET type system. Nothing that you do in C# can violate the language guarantees of C#: it’s often unidiomatic (F# favours immutability, C# favours mutability) but anything in C# could also be done in safe F#. In contrast, Ada provides some strong type safety guarantees that C code will not respect. As soon as you link a C library, you have to contend with the fact that memory safety violations in C are all-bets-are-off scenarios and the type system provides very few tools for avoiding them (unlike Ada).
interop on a VM is generally a lot better than between native languages and C (unless the language looks a lot like C, like Zig. Maybe that applies to Ada, idk.) The impedance mismatch is lower, and C# is a lot higher level than C.
C libraries aren’t exactly the apex of ergonomy. You’ll get the fundamentals this way (just like we do in OCaml), and a lot of core infrastructure (curl, sqlite, etc.). But you’ll still miss a lot of what people expect from a language in 2021, like a good datetime library, bindings to $network_service, convenient unicode, serialization that doesn’t suck, webserver frameworks, database bindings (again, ideally, with a less horrible interface than C), etc.
Not to mention the fact that services don’t put out SDKs in C (most of the time?). E.g., you are more likely to find a Java or C# SDK for a service in AWS than you would a C SDK.
That’s a snarky response and I’m disappointed. Of course it’s not the raw amount of characters, but the ability to combine well behaved abstractions. F# has iterators with all the classic map/flat_map/filter stuff, async, result-based error handling, and nice higher-order functions. It’s not necessarily as rock-solid as carefully crafted Ada, but that’s also not what entreprise software is about; there, having a good type system is already more than what the other languages offer.
And please stop rejecting every single criticism of Ada. It’s worse than the so called rust evangelism task force.
I was trying to be funny, but I can see how it could be taken as being in bad taste and I appreciate you calling me out on it.
My point was that I’ve seen a lot of FP code (Haskell and Clojure in particular) which is incredibly terse, but it can take a long time to get something boiled down into that essence, which are often super elegant. Part of this is that you’re using immutable computational state of function composition in place of mutable state and imperative style.
That’s the gist of what I was trying to point out. Ada is notorious for being verbose for good reason, and when you go through that process of “boiling something down”, what you start with before you get to that point can be ludicrous.
And please stop rejecting every single criticism of Ada. It’s worse than the so called rust evangelism task force.
The only criticism I see here or in my comment history is my attempt at a joke about terseness, which is a very valid. I realized I was coming on a bit strong with the evangelism a few comments ago, which is why I had tried to back off with the comments and held off on submitting a few stories. I guess I need to do that and be more careful as well.
I was a bit cranky. I do agree that terseness is not all. F# is not as concise as Haskell (on the typed side) so I think the code should still be quite straightforward to read in general, and it’s impure, so you can still write straightforward imperative code.
I think there’s many places where Ada could be used more now that it has better, hum, marketing. It’d be excellent in many places C is used (say, to implement things like sqlite, curl, etc.) I appreciate you and /u/glacambre talking about Ada in general. I’d love to read more about uses of Ada/Spark in particular, because it is a strong point of the language that is already there, whereas the package management and open source community are only getting started, as far as I can tell. (plus I have friends who work on why3 :-))
It’s sad to see what has happened with F# and OCaml, I really wish Microsoft had just jumped on the same bus rather than going their own way, since I feel like it was a huge missed opportunity and has hurt both languages.
It seems like there’s a lot of angst and frustration within the Ada community because the modern language isn’t the crazy bureaucratic DoD language that people assume, and many people don’t know anything about it. There’s a lot of passionate people, and we’re all trying to figure out the best way of doing outreach without coming on too strong, which I’m very guilty of on multiple occasions.
Honestly, F# is doing its own thing and it’s fine. It made sense for Microsoft to do something that runs on their pervasive runtime environment, which is quite different than OCaml’s native runtime. For a start, they’ve had multicore for a long time… but also null. I think it served them well, and with dotnet core it might become more popular, who knows.
About Ada: I can imagine, indeed. It’s hard for a smallish, not hype community, to get a second chance in the popularity contest. Alire is a good step, but I think having a robust LSP server and a build system that is friendly (i.e. cargo-like) are table stakes nowadays. People won’t settle for less than that. Non conventional syntaxes are also problematic. I feel you because OCaml has many of the same issues wrt adoption, with similar causes.
OTOH, C# is an enterprise-friendly language, and since F# has effortless interop with .NET, it is quite enterprise-friendly since you only have to learn the language while leveraging an existing code base and libraries. I have seen this (at a distance) at more than one organisation.
Honest question, how much of a community is there around F#? I have trouble finding active communities or standout projects written in the language. Many of the git repos for what look like core projects only have mild activity. We can compare F# to something like Clojure or Scala but those all have thriving communities that are distinct and really help propel the language forward. Where are those communities for F#?
I disagree about performance not being important. Once you start scaling, using a language that makes writing performant code can save you a lot on hardware costs.
I’m also amused to see that Ada is not being considered, despite ticking almost all boxes:
'access)I’m not sure I would say Ada is the best entreprise language though. I doubt such a language exists.
First sentence in the “entreprise friendly” section. I think it’s safe to say that Ada is not remotely comparable to F# in this domain. I think it’s also clear that F# is more productive than Ada (not safer, just, you can do more in fewer lines); that echoes the paragraph about GC instead of manual memory management, and the one on FP.
AFAIK the F# ecosystem isn’t that big, what’s really big is the C# ecosystem, which is made available through easy interop. But if interop is considered part of the ecosystem, the C ecosystem (and anything available through FFI, really) can be considered available to Ada as importing functions through ffi is as easy as
function X (Y: Integer) return Z with Import, External_Name => X(yes, this supports gnarly stuff like C++ exceptions).There’s one key difference: Both F# and C# rely on the underlying .NET type system. Nothing that you do in C# can violate the language guarantees of C#: it’s often unidiomatic (F# favours immutability, C# favours mutability) but anything in C# could also be done in safe F#. In contrast, Ada provides some strong type safety guarantees that C code will not respect. As soon as you link a C library, you have to contend with the fact that memory safety violations in C are all-bets-are-off scenarios and the type system provides very few tools for avoiding them (unlike Ada).
That’s an extremely good point that I hadn’t considered. Thank you for raising it :).
Of course, a lot of the things in the C# ecosystem are P/invoke or COM wrappers around C/C++ codebases, so it’s not quite as clear cut.
There’s some truth to that, I think. However:
Not to mention the fact that services don’t put out SDKs in C (most of the time?). E.g., you are more likely to find a Java or C# SDK for a service in AWS than you would a C SDK.
If terseness is equated with productivity, we should all be writing APL.
That’s a snarky response and I’m disappointed. Of course it’s not the raw amount of characters, but the ability to combine well behaved abstractions. F# has iterators with all the classic map/flat_map/filter stuff, async, result-based error handling, and nice higher-order functions. It’s not necessarily as rock-solid as carefully crafted Ada, but that’s also not what entreprise software is about; there, having a good type system is already more than what the other languages offer.
And please stop rejecting every single criticism of Ada. It’s worse than the so called rust evangelism task force.
I was trying to be funny, but I can see how it could be taken as being in bad taste and I appreciate you calling me out on it.
My point was that I’ve seen a lot of FP code (Haskell and Clojure in particular) which is incredibly terse, but it can take a long time to get something boiled down into that essence, which are often super elegant. Part of this is that you’re using immutable computational state of function composition in place of mutable state and imperative style.
That’s the gist of what I was trying to point out. Ada is notorious for being verbose for good reason, and when you go through that process of “boiling something down”, what you start with before you get to that point can be ludicrous.
The only criticism I see here or in my comment history is my attempt at a joke about terseness, which is a very valid. I realized I was coming on a bit strong with the evangelism a few comments ago, which is why I had tried to back off with the comments and held off on submitting a few stories. I guess I need to do that and be more careful as well.
Thank you for this thoughtful response :-).
I was a bit cranky. I do agree that terseness is not all. F# is not as concise as Haskell (on the typed side) so I think the code should still be quite straightforward to read in general, and it’s impure, so you can still write straightforward imperative code.
I think there’s many places where Ada could be used more now that it has better, hum, marketing. It’d be excellent in many places C is used (say, to implement things like sqlite, curl, etc.) I appreciate you and /u/glacambre talking about Ada in general. I’d love to read more about uses of Ada/Spark in particular, because it is a strong point of the language that is already there, whereas the package management and open source community are only getting started, as far as I can tell. (plus I have friends who work on why3 :-))
It’s sad to see what has happened with F# and OCaml, I really wish Microsoft had just jumped on the same bus rather than going their own way, since I feel like it was a huge missed opportunity and has hurt both languages.
It seems like there’s a lot of angst and frustration within the Ada community because the modern language isn’t the crazy bureaucratic DoD language that people assume, and many people don’t know anything about it. There’s a lot of passionate people, and we’re all trying to figure out the best way of doing outreach without coming on too strong, which I’m very guilty of on multiple occasions.
Honestly, F# is doing its own thing and it’s fine. It made sense for Microsoft to do something that runs on their pervasive runtime environment, which is quite different than OCaml’s native runtime. For a start, they’ve had multicore for a long time… but also null. I think it served them well, and with dotnet core it might become more popular, who knows.
About Ada: I can imagine, indeed. It’s hard for a smallish, not hype community, to get a second chance in the popularity contest. Alire is a good step, but I think having a robust LSP server and a build system that is friendly (i.e. cargo-like) are table stakes nowadays. People won’t settle for less than that. Non conventional syntaxes are also problematic. I feel you because OCaml has many of the same issues wrt adoption, with similar causes.
“Enterprise friendly” also means easy to hire for… Java has been in this category for the last 20 years or so.
OTOH, C# is an enterprise-friendly language, and since F# has effortless interop with .NET, it is quite enterprise-friendly since you only have to learn the language while leveraging an existing code base and libraries. I have seen this (at a distance) at more than one organisation.
Honest question, how much of a community is there around F#? I have trouble finding active communities or standout projects written in the language. Many of the git repos for what look like core projects only have mild activity. We can compare F# to something like Clojure or Scala but those all have thriving communities that are distinct and really help propel the language forward. Where are those communities for F#?
/^Why \S+ is the best \S+ language$/d