8 ms·

Best Programming languages today F# - ML + .Net Clojure - Java + jvm + lisp Rust/OCaml - System Programming Both F# and Clojure give you access to probably

Best Programming languages today F# - ML + .Net Clojure - Java + jvm + lisp Rust/OCaml - System Programming Both F# and Clojure give you access to probably the two biggest ecosystems, but they are obviously put them at opposite ends of the programming paradigms spectrum, but this makes learning both less redundant Rust and OCaml, are probably what you should use if you want a compiled system language Honorable mention PureScript, because haskell + Javascript (but F# will take you close and is more practical)

kaliszad 5y ago
Well, Clojure and its dialect ClojureScript (and ClojureCLR, if Microsoft stepped up and did at least something for it) are so close, you really kind of have to consider the first two as a single group in my point of view. Many projects have a frontend written for a web browser - using ClojureScript there is very natural. You can share most utility functions between frontend and backend (in Clojure) just as we do at OrgPad. GraalVM, Babashka (based on GraalVM), libpython-clj and the Python interop and other more or less Clojure related projects (its a stretch, but Hylang?) just show the breadth of the ecosystem. F# seems nice and if I had to pick C# or F#, I would pick F# but I see Clojure as conceptually stronger, easier to explain and teach, to finish projects quickly and run them reliably. Immutable datastructures, the REPL and somewhat related hot-code reloading on the backend and frontend also really is something. (I know, F# has a "REPL" but is it more a Shell or a REPL e.g. running even in production?) Perhaps I should update my views about F# sometime. With my current knowledge I see it as somewhat inferior to the Clojure/ ClojureScript duo and the related ecosystem.
- dimitrios1 5y ago
  The obvious answer why F# wins over Clojure in many people's books is static typing.
  - bmitc 5y ago
    I also get the impression that that F# sits on top of its host VM better than Clojure, although I haven't used Clojure to any great degree. F#'s error messages are actually pretty good, and integrates with .NET so well, you really don't even need to know the existence of C# when using it. I really wish .NET Core came earlier and would have enticed Clojure to stay as a .NET language.
    - kaliszad 5y ago
      ClojureCLR does support .NET (Core) but there isn't any support by Microsoft and a .NET language really need at least some support by Microsoft, to be viable at all. Clojure work great with JVM, it is very tightly integrated. Similarly ClojureScript and JavaScript, even though that is actually transpiling. With shadow-cljs, it really is quite integrated into the ecosystem.
  - kaliszad 5y ago
    I haven't felt the need for static typing in Clojure at all. I don't understand, why people are so dogmatic about static typing. In my experience and other on the team share it too, static types really haven't (or wouldn't have) prevented any bugs. What is more important are good names for variables/ references/ functions, code that just speaks to you or is at least sufficiently clear, up-to-date and clear documentation with examples and links if needed and efficient testing/ sensible test coverage. If I really need to know the type of something, I can always use (type <something>) or more concrete e.g (string? <something>) if I want to use that information for something. If I don't know, how to use the function, I have to improve the name, the documentation and my understanding of the code perhaps. If I pass garbage to a clearly named function, I get garbage out as with the static type system. In both cases, I have to investigate and ask myself tough questions about how I understand code or whether our code-base is well maintained. I can see static typing helping e.g. with compilers, low level software where every clock cycle and byte matter and some specialized stuff. I don't see much point in static typing in a language like Clojure.
    - grayrest 5y ago
      If you're on a project every day and familiar with all the pieces, there's not a large advantage to static typing. Static typing allows people unfamiliar with the program to make changes and have a reasonably high degree of confidence that they got them right. This can be junior devs, people new to the project, you after 5 years away, or a project that's grown to the point where nobody knows all the pieces. I'm not saying this as a die-hard static typing fan. I wrote Python for years, have written JS professionally most of my career, and spent 2 years writing Clojure professionally. I'm comfortable with dynamic languages. The Clojure codebase was the most stable I've been on (including typed languages) largely due to the senior team and excellent QA. The only problem I had with it was when business shifted from a subscription model to an a-la-carte model, which required manually reworking a LOT of maps to match the new requirements. This is considerably more painful in a dynamic language than it is in a static one. There IS a downside to static typing in terms of verbosity. I've seen Java codebases where half the code was there basically because of the static typing. More advanced type systems do not suffer from that problem. I'm fine with OCaml / F# / Rust / Typescript.
  - Barrin92 5y ago
    I think that needs the qualifier 'many (vocal) people's'. Dynamic languages continue to be exceedingly popular. The preference for static typing is I think over-represented in online discourse. I would be very surprised if the amount of Clojure/Clojurescript out there in production isn't several times larger than the amount of F#. Not trying to start a language war but with the exception of Jet which I don't think is around any more I can't recall a single large company using F#.
    - kaliszad 5y ago
      That is a good point about the vocal minority and this is a valid argument. On the other hand, I wouldn't consider the amount of code that was written in a language to be an indicator of good design (that usually saves work/ lines of code) or other qualities. I find, I solve the same class of problems better with Clojure instead of e.g. C# or Java or even Python (when not some SysAdmin stuff written for and with Python in mind - basically a DSL for the specific task).
    - Zababa 5y ago
      > Dynamic languages continue to be exceedingly popular. The preference for static typing is I think over-represented in online discourse. The most popular dynamic languages are all adding static typing though. Typescript became extremely popular very quickly, Python has been adding types annotations for a long time now, Ruby is adding them too, some team at Facebook is working on the same for Erlang. I've seen a few times Clojure users saying they don't need them, and considering Clojure has immutability, a strong REP and spec, I can understand that they don't feel the need. But Python, JavaScript, Ruby and even some Erlang/Elixir users think the opposite. > I would be very surprised if the amount of Clojure/Clojurescript out there in production isn't several times larger than the amount of F#. I think the same, but the thing is that I think the amount of Java for web apps is already several times larger than the amount of C# for web apps, which can skew things.
      - kaliszad 5y ago
        Annotations/ hints you can use optionally to convey extra metadata are a very different thing compared to types you have to use else nothing will really work. There were some optional type systems for Clojure but I cannot say how successful they are or were. I think the critical parts, e.g. APIs or code boundaries are specced out and that seems to be the recommended solution. Btw. just that people are adding something doesn't mean that it is good or helping in general. It is great, Python has the optional type annotations precisely because they are optional - you can use them when you think you are better off doing the extra work.
- throw868788 5y ago
  > I see Clojure as conceptually stronger, easier to explain and teach, to finish projects quickly and run them reliably. First hand unfortunately I find the opposite is true - I have personally seen Clojure abandoned in a company and F# adopted instead in the same company albeit different parts. A rare case considering the nature of both langs. F#, to me really is like a statically typed Python that's got better performance, has better portable package management, and reads easier than OcAML/Haskell to newcomers with its "light" mode syntax. Having used Scala, Clojure F# feels like a simplification - it only takes in more expressiveness if it can stay simple. It also reads quite similar to most new breed lang's (e.g. for me when I look at Rust - if I squint many of the constructs look similar). In a month I've seen dynamic language only devs (e.g. JS, Ruby) with no static typing experience be productive in F# contributing advanced code - I've also seen Clojure abandoned in the same company with dev's perplexed with all the brackets, lost as the code scales, etc. Because it is simpler than Scala, Haskell, etc but does pretty much most of what these langs do (80%/20% rule) its a good gateway into functional programming IMO. With some of the new features in .NET 5 it can also be faster since it tends to run closer to the metal than Scala (i.e. no implicit wrapper types, rather use compile time polymorphism, stack allocation support, value types, etc when needed) F# also has a REPL, and yes its simple but it does the job I argue with a lower learning curve. With one single script file you can load all dependent packages, and write your quick script straight from a naked .NET installation. Just `dotnet fsi script.fsx` or if you want to shebang the script that works too. May not be as pretty as Clojure but it has most of the bells and whistles and arguably much easier for a newbie to understand. There's also a ClojureScript like facility in Fable, heard good things but haven't used it personally. Being able to cut and paste a script in text (e.g. via Slack) to a colleague and it just works on their machine, libraries/packages restored whether they are on a Mac, Windows, Linux machine is pretty cool. All they need is .NET 5 installed. On the teaching aspect using a JS dev (could be any lang) as an example - a module in F# is the same as a module in JS approximately - they contain functions that refer to other modules. Async blocks are similar to async/await and promises (! instead of await keyword). After that they get the hang of it pretty quickly. They even start to want to move away from their previous language as they realise things just work first time more often. They don't need to learn classes, OO, or all the frameworks typical of a C# project and all the "patterns". In other words it still feels concise like JS/Go/Ruby/etc to them. Functions chained to other functions in a readable syntax - that's it. I've also seen F# dev's present F# code on slide decks to non technical people and it be well received - they didn't realize it was actual code. There's Twitter threads over the years on this exact scenario and it's what initially made me curious about the language. I can't imagine that happening with Clojure and its syntax of brackets, :require, classpath setup, etc etc.
hitpointdrew 5y ago
F# doesn't even make the list. Here are the top 5. 1. Python 2. Python 3. Python 4. Python 5. Python If you REALLY can't use Python, then Rust or Go. If you are programing a game, the GDscript.
- hallway_monitor 5y ago
  Found the person who's never worked on an enterprise system
  - hitpointdrew 5y ago
    >Found the person who's never worked on an enterprise system Pfft give me break. I manage the damn things for a living. I work on enterprise systems all day, everyday, just not as an application coder. I'm SysAdmin so I am in Terraform/Ansible/Jenkins/Kubernetes and, you guessed it, Python, all day. I am the one that makes sure your shitty-ass F# application gets into production.
    - kaliszad 5y ago
      If you have interest, have a look at https://github.com/babashka/babashka https://github.com/babashka/babashka and https://github.com/clj-python/libpython-clj https://github.com/clj-python/libpython-clj I am a System Engineer/ Administrator by heart and found the Clojure threading macro to be really close to the Bash pipeline conceptually but just way more powerful. I really wasn't enjoying programming much before - I have coded in several languages, Python being quite at the top for me and being on the ok to fun side at times even, but I really wouldn't change Clojure/ ClojureScript for any other language unless I had to. Btw. I have written my fare share of Ansible as well and lost quite a bit of hair understanding the mess that is Jinja. I wrapped some GoDaddy REST APIs using Ansible + Jinja and that really was stretching the capabilities of those tools (it works and is even quite clean, but it was much more work than it needed be). I would probably be able to implement an alternative to Ansible/ Jinja for the specific task and finish the task in the same amount of time I wrangled Ansible + Jinja which are supposed to make this kind of work easier/ save time. And Ansible really is much better than some other stuff. I think, Babashka or https://epiccastle.io/spire/ https://epiccastle.io/spire/ or something similar will eventually break through and hopefully improve the situation considerably but there is still much work to do.
throwaway894345 5y ago
Obviously this is subjective, but for my money I use Go for everything where development velocity matters and Rust for everything where performance and/or safety are paramount. I steer clear of VM and interpreted languages because true first-class support for statically linked native code is really hard to beat (and all of the "but you can AOT/statically-link Java/C#/etc!" promises seem to come with significant hidden caveats that you only run into after considerable investment). Yeah, I know everyone hates on Go for its type system and because Rob Pike called it a systems language once (although the idea that OCaml is a systems language while Go isn't boggles the mind), but it's honestly so much more productive than any other language I've used. I also tried hard to like OCaml but the tooling was crumby and integrating libraries which used different standard libraries or async libraries or etc was painful. The ecosystem was also quite a lot smaller and important libraries were missing or low quality. While the Go community has its own problems, the OCaml community was positively toxic (if you have a problem for which there isn't a pat solution, then what you're trying to do is stupid and if it wasn't stupid then Jane Street would have solved it already). While an ML type system is certainly nice to have, it turns out there are a lot of factors that matter more for practical software development, and if you're missing out on these fundamentals, the best type system in the world won't save you (and I posit that Go excels in these fundamentals even if it lacks an ML type system). I understand that this will not be a popular sentiment in a thread about F#.
- Zababa 5y ago
  I really like ML-likes, but I feel the same way about Go. I hoped for some time that a equivalent of F# would appear for Go and gain a bit of traction, as I really like algebraic data types, immutability by default and a few map/filter/reduce from time to time, but sadly that didn't happen. It's really frustrating because sum types and pattern matching would have been a good alternative to if err != nil that could be cheked by the compiler, and the language already has a more powerful switch. On the other hand, the language is nice to use, the tooling is good, and popular enough to usually have what you need.
  - throwaway894345 5y ago
    Yep, fully agree. Unlike many MLs, Go nails syntax, tooling, runtime, ecosystem, standard library, etc but the type system could be better. In my opinion there's space for a "Rust with GC", but every time I say this the OCaml and F# people come out of the woodwork to evangelize their languages but those languages miss the mark in many important respects.
chalst 5y ago
F# isn't really ML + .NET: the module system in F# is much less capable than that of Ocaml, but has the advantage that it is compatible with C# classes. There's some nice stuff in F# that is entirely novel: my favourite feature is that if you omit passing ref values in a function call, they are added as multiple return values, a kind of dual to Currying.
- pjmlp 5y ago
  Not so much different from SML though.
  - momentoftop 5y ago
    The F# module system is just as incapable compared to SML. The SML and Ocaml module systems provide higher-kinding which isn't present in F#. And if you don't have functors, you're not SML/Ocaml.
    - pjmlp 5y ago
      You can approach it with generics.
paavohtl 5y ago
Depending on your definition of systems programming (there are many!) OCaml might or might not be completely unsuitable for it. Mandatory garbage collection, no real multithreading and higher than zero-cost FFI are at least reasons why it shouldn't count as a systems language.
- pjmlp 5y ago
  Mirage OS seems to fit the bill. Then there is the whole point if writing compilers should be considered systems programming.

kaliszad 5y ago

Well, Clojure and its dialect ClojureScript (and ClojureCLR, if Microsoft stepped up and did at least something for it) are so close, you really kind of have to consider the first two as a single group in my point of view. Many projects have a frontend written for a web browser - using ClojureScript there is very natural. You can share most utility functions between frontend and backend (in Clojure) just as we do at OrgPad. GraalVM, Babashka (based on GraalVM), libpython-clj and the Python interop and other more or less Clojure related projects (its a stretch, but Hylang?) just show the breadth of the ecosystem. F# seems nice and if I had to pick C# or F#, I would pick F# but I see Clojure as conceptually stronger, easier to explain and teach, to finish projects quickly and run them reliably. Immutable datastructures, the REPL and somewhat related hot-code reloading on the backend and frontend also really is something. (I know, F# has a "REPL" but is it more a Shell or a REPL e.g. running even in production?) Perhaps I should update my views about F# sometime. With my current knowledge I see it as somewhat inferior to the Clojure/ ClojureScript duo and the related ecosystem.

dimitrios1 5y ago
The obvious answer why F# wins over Clojure in many people's books is static typing.
- bmitc 5y ago
  I also get the impression that that F# sits on top of its host VM better than Clojure, although I haven't used Clojure to any great degree. F#'s error messages are actually pretty good, and integrates with .NET so well, you really don't even need to know the existence of C# when using it. I really wish .NET Core came earlier and would have enticed Clojure to stay as a .NET language.
  - kaliszad 5y ago
    ClojureCLR does support .NET (Core) but there isn't any support by Microsoft and a .NET language really need at least some support by Microsoft, to be viable at all. Clojure work great with JVM, it is very tightly integrated. Similarly ClojureScript and JavaScript, even though that is actually transpiling. With shadow-cljs, it really is quite integrated into the ecosystem.
- kaliszad 5y ago
  I haven't felt the need for static typing in Clojure at all. I don't understand, why people are so dogmatic about static typing. In my experience and other on the team share it too, static types really haven't (or wouldn't have) prevented any bugs. What is more important are good names for variables/ references/ functions, code that just speaks to you or is at least sufficiently clear, up-to-date and clear documentation with examples and links if needed and efficient testing/ sensible test coverage. If I really need to know the type of something, I can always use (type <something>) or more concrete e.g (string? <something>) if I want to use that information for something. If I don't know, how to use the function, I have to improve the name, the documentation and my understanding of the code perhaps. If I pass garbage to a clearly named function, I get garbage out as with the static type system. In both cases, I have to investigate and ask myself tough questions about how I understand code or whether our code-base is well maintained. I can see static typing helping e.g. with compilers, low level software where every clock cycle and byte matter and some specialized stuff. I don't see much point in static typing in a language like Clojure.
  - grayrest 5y ago
    If you're on a project every day and familiar with all the pieces, there's not a large advantage to static typing. Static typing allows people unfamiliar with the program to make changes and have a reasonably high degree of confidence that they got them right. This can be junior devs, people new to the project, you after 5 years away, or a project that's grown to the point where nobody knows all the pieces. I'm not saying this as a die-hard static typing fan. I wrote Python for years, have written JS professionally most of my career, and spent 2 years writing Clojure professionally. I'm comfortable with dynamic languages. The Clojure codebase was the most stable I've been on (including typed languages) largely due to the senior team and excellent QA. The only problem I had with it was when business shifted from a subscription model to an a-la-carte model, which required manually reworking a LOT of maps to match the new requirements. This is considerably more painful in a dynamic language than it is in a static one. There IS a downside to static typing in terms of verbosity. I've seen Java codebases where half the code was there basically because of the static typing. More advanced type systems do not suffer from that problem. I'm fine with OCaml / F# / Rust / Typescript.
- Barrin92 5y ago
  I think that needs the qualifier 'many (vocal) people's'. Dynamic languages continue to be exceedingly popular. The preference for static typing is I think over-represented in online discourse. I would be very surprised if the amount of Clojure/Clojurescript out there in production isn't several times larger than the amount of F#. Not trying to start a language war but with the exception of Jet which I don't think is around any more I can't recall a single large company using F#.
  - kaliszad 5y ago
    That is a good point about the vocal minority and this is a valid argument. On the other hand, I wouldn't consider the amount of code that was written in a language to be an indicator of good design (that usually saves work/ lines of code) or other qualities. I find, I solve the same class of problems better with Clojure instead of e.g. C# or Java or even Python (when not some SysAdmin stuff written for and with Python in mind - basically a DSL for the specific task).
  - Zababa 5y ago
    > Dynamic languages continue to be exceedingly popular. The preference for static typing is I think over-represented in online discourse. The most popular dynamic languages are all adding static typing though. Typescript became extremely popular very quickly, Python has been adding types annotations for a long time now, Ruby is adding them too, some team at Facebook is working on the same for Erlang. I've seen a few times Clojure users saying they don't need them, and considering Clojure has immutability, a strong REP and spec, I can understand that they don't feel the need. But Python, JavaScript, Ruby and even some Erlang/Elixir users think the opposite. > I would be very surprised if the amount of Clojure/Clojurescript out there in production isn't several times larger than the amount of F#. I think the same, but the thing is that I think the amount of Java for web apps is already several times larger than the amount of C# for web apps, which can skew things.
    - kaliszad 5y ago
      Annotations/ hints you can use optionally to convey extra metadata are a very different thing compared to types you have to use else nothing will really work. There were some optional type systems for Clojure but I cannot say how successful they are or were. I think the critical parts, e.g. APIs or code boundaries are specced out and that seems to be the recommended solution. Btw. just that people are adding something doesn't mean that it is good or helping in general. It is great, Python has the optional type annotations precisely because they are optional - you can use them when you think you are better off doing the extra work.
throw868788 5y ago
> I see Clojure as conceptually stronger, easier to explain and teach, to finish projects quickly and run them reliably. First hand unfortunately I find the opposite is true - I have personally seen Clojure abandoned in a company and F# adopted instead in the same company albeit different parts. A rare case considering the nature of both langs. F#, to me really is like a statically typed Python that's got better performance, has better portable package management, and reads easier than OcAML/Haskell to newcomers with its "light" mode syntax. Having used Scala, Clojure F# feels like a simplification - it only takes in more expressiveness if it can stay simple. It also reads quite similar to most new breed lang's (e.g. for me when I look at Rust - if I squint many of the constructs look similar). In a month I've seen dynamic language only devs (e.g. JS, Ruby) with no static typing experience be productive in F# contributing advanced code - I've also seen Clojure abandoned in the same company with dev's perplexed with all the brackets, lost as the code scales, etc. Because it is simpler than Scala, Haskell, etc but does pretty much most of what these langs do (80%/20% rule) its a good gateway into functional programming IMO. With some of the new features in .NET 5 it can also be faster since it tends to run closer to the metal than Scala (i.e. no implicit wrapper types, rather use compile time polymorphism, stack allocation support, value types, etc when needed) F# also has a REPL, and yes its simple but it does the job I argue with a lower learning curve. With one single script file you can load all dependent packages, and write your quick script straight from a naked .NET installation. Just `dotnet fsi script.fsx` or if you want to shebang the script that works too. May not be as pretty as Clojure but it has most of the bells and whistles and arguably much easier for a newbie to understand. There's also a ClojureScript like facility in Fable, heard good things but haven't used it personally. Being able to cut and paste a script in text (e.g. via Slack) to a colleague and it just works on their machine, libraries/packages restored whether they are on a Mac, Windows, Linux machine is pretty cool. All they need is .NET 5 installed. On the teaching aspect using a JS dev (could be any lang) as an example - a module in F# is the same as a module in JS approximately - they contain functions that refer to other modules. Async blocks are similar to async/await and promises (! instead of await keyword). After that they get the hang of it pretty quickly. They even start to want to move away from their previous language as they realise things just work first time more often. They don't need to learn classes, OO, or all the frameworks typical of a C# project and all the "patterns". In other words it still feels concise like JS/Go/Ruby/etc to them. Functions chained to other functions in a readable syntax - that's it. I've also seen F# dev's present F# code on slide decks to non technical people and it be well received - they didn't realize it was actual code. There's Twitter threads over the years on this exact scenario and it's what initially made me curious about the language. I can't imagine that happening with Clojure and its syntax of brackets, :require, classpath setup, etc etc.

hitpointdrew 5y ago

F# doesn't even make the list. Here are the top 5. 1. Python 2. Python 3. Python 4. Python 5. Python If you REALLY can't use Python, then Rust or Go. If you are programing a game, the GDscript.

hallway_monitor 5y ago
Found the person who's never worked on an enterprise system
- hitpointdrew 5y ago
  >Found the person who's never worked on an enterprise system Pfft give me break. I manage the damn things for a living. I work on enterprise systems all day, everyday, just not as an application coder. I'm SysAdmin so I am in Terraform/Ansible/Jenkins/Kubernetes and, you guessed it, Python, all day. I am the one that makes sure your shitty-ass F# application gets into production.
  - kaliszad 5y ago
    If you have interest, have a look at https://github.com/babashka/babashka https://github.com/babashka/babashka and https://github.com/clj-python/libpython-clj https://github.com/clj-python/libpython-clj I am a System Engineer/ Administrator by heart and found the Clojure threading macro to be really close to the Bash pipeline conceptually but just way more powerful. I really wasn't enjoying programming much before - I have coded in several languages, Python being quite at the top for me and being on the ok to fun side at times even, but I really wouldn't change Clojure/ ClojureScript for any other language unless I had to. Btw. I have written my fare share of Ansible as well and lost quite a bit of hair understanding the mess that is Jinja. I wrapped some GoDaddy REST APIs using Ansible + Jinja and that really was stretching the capabilities of those tools (it works and is even quite clean, but it was much more work than it needed be). I would probably be able to implement an alternative to Ansible/ Jinja for the specific task and finish the task in the same amount of time I wrangled Ansible + Jinja which are supposed to make this kind of work easier/ save time. And Ansible really is much better than some other stuff. I think, Babashka or https://epiccastle.io/spire/ https://epiccastle.io/spire/ or something similar will eventually break through and hopefully improve the situation considerably but there is still much work to do.

throwaway894345 5y ago

Obviously this is subjective, but for my money I use Go for everything where development velocity matters and Rust for everything where performance and/or safety are paramount. I steer clear of VM and interpreted languages because true first-class support for statically linked native code is really hard to beat (and all of the "but you can AOT/statically-link Java/C#/etc!" promises seem to come with significant hidden caveats that you only run into after considerable investment). Yeah, I know everyone hates on Go for its type system and because Rob Pike called it a systems language once (although the idea that OCaml is a systems language while Go isn't boggles the mind), but it's honestly so much more productive than any other language I've used. I also tried hard to like OCaml but the tooling was crumby and integrating libraries which used different standard libraries or async libraries or etc was painful. The ecosystem was also quite a lot smaller and important libraries were missing or low quality. While the Go community has its own problems, the OCaml community was positively toxic (if you have a problem for which there isn't a pat solution, then what you're trying to do is stupid and if it wasn't stupid then Jane Street would have solved it already). While an ML type system is certainly nice to have, it turns out there are a lot of factors that matter more for practical software development, and if you're missing out on these fundamentals, the best type system in the world won't save you (and I posit that Go excels in these fundamentals even if it lacks an ML type system). I understand that this will not be a popular sentiment in a thread about F#.

Zababa 5y ago
I really like ML-likes, but I feel the same way about Go. I hoped for some time that a equivalent of F# would appear for Go and gain a bit of traction, as I really like algebraic data types, immutability by default and a few map/filter/reduce from time to time, but sadly that didn't happen. It's really frustrating because sum types and pattern matching would have been a good alternative to if err != nil that could be cheked by the compiler, and the language already has a more powerful switch. On the other hand, the language is nice to use, the tooling is good, and popular enough to usually have what you need.
- throwaway894345 5y ago
  Yep, fully agree. Unlike many MLs, Go nails syntax, tooling, runtime, ecosystem, standard library, etc but the type system could be better. In my opinion there's space for a "Rust with GC", but every time I say this the OCaml and F# people come out of the woodwork to evangelize their languages but those languages miss the mark in many important respects.

chalst 5y ago

F# isn't really ML + .NET: the module system in F# is much less capable than that of Ocaml, but has the advantage that it is compatible with C# classes. There's some nice stuff in F# that is entirely novel: my favourite feature is that if you omit passing ref values in a function call, they are added as multiple return values, a kind of dual to Currying.

pjmlp 5y ago
Not so much different from SML though.
- momentoftop 5y ago
  The F# module system is just as incapable compared to SML. The SML and Ocaml module systems provide higher-kinding which isn't present in F#. And if you don't have functors, you're not SML/Ocaml.
  - pjmlp 5y ago
    You can approach it with generics.

paavohtl 5y ago

Depending on your definition of systems programming (there are many!) OCaml might or might not be completely unsuitable for it. Mandatory garbage collection, no real multithreading and higher than zero-cost FFI are at least reasons why it shouldn't count as a systems language.

pjmlp 5y ago
Mirage OS seems to fit the bill. Then there is the whole point if writing compilers should be considered systems programming.