6 ms·
Why OCaml?
- JaggerJo 4y agoOCaml is cool, but have you tried F#?
- substation13 4y agoI think both langs have their strengths, neither is clearly superior. If F# added a few more language features though...
- JaggerJo 4y agoYeah, I admit that as a daily F# user I jealously look at some OCaml features. For us the tooling + library ecosystem are more important to get sh* done.
- xupybd 4y agoI'm a big fan of F# as it has a huge company and ecosystem behind it. That said OCaml is where most of the language ideas came from. Much of what makes F# is owed to OCaml.
- germandiago 4y agoF# seems to be to OCaml what Clojure is to Lisp
- sidkshatriya 4y ago> F# as it has a huge company and ecosystem behind it Indeed, F# has the might of Microsoft behind it. Yet, to me, that carries some risk in itself. In the future, Microsoft might decide for some reason that F# is not aligned to its goals and say, it wants to invest in C# exclusively or decrease emphasis on F#. Then what happens? OCaml is more resilient in a sense it is more "community" owned and run. Companies (contributing to OCaml) keep coming to (or leaving) OCaml. F# has all its eggs with Microsoft.
- pjmlp 4y agoIf only DevDiv actually could make up their mind about what they want F# for. Latest pivot is to try go heads up against Julia into Python's domain. You already know which one data scientists will pick up.
- JaggerJo 4y agoTrue. I really appreciate Don Syme for not adding too much to F#. It's a beautiful precise language as it is. I really don't like what has happened to C# is the past few years where features are just added blindly it seems. Current C# looks nothing like C# code from a few years ago and that's bad IMO.
- wizofaus 4y agoExample? The biggest addition to C# recently is non-nullable references, which was long overdue even though I haven't had a proper opportunity to use yet, but they don't even change the syntax of the language.
- pjmlp 4y agoYou missed the pattern matching, default interface methods, records (class and struct based), and all the low level features to be able to write C++ like code in C#, code generators, global usings, implicit main class, static lambdas, abstract interface methods for operators,.... On the horizon, discriminated unions are still being talked about, and more C++ performance like features.
- deleted 4y ago[deleted]
- JaggerJo 4y agoI bunch of stuff was added in the recent years. Just a few examples: Pattern Matching https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#more-patterns-in-more-places https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Non destructive mutation https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9#nondestructive-mutation https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Null-coalescing assignment https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-8#null-coalescing-assignment https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
- yodsanklai 4y agoLet suppose someone wants to port a OCaml project to F# in a linux environment. How much work would it take in term of code rewriting? can it compile to native code? how good is the language support experience in vscode? any reason not to do it?
- carlmr 4y agoThey are very close. I think a rewrite wouldn't be too crazy. But there might be libraries available only in one or the other. Also F# is .NET based, which has the clear benefit of adding a huge standard library, but at the same time the OOP-based design of .NET makes for uglier than necessary code in F#.
- JaggerJo 4y agoThe DarkLang project was originally written in OCaml and was recently ported to F# (https://blog.darklang.com/new-backend-fsharp/ https://blog.darklang.com/new-backend-fsharp/) > How much work would it take in term of code rewriting? There are definitely code changes required, but I think those are quite manageable as concepts mostly map 1:1 from OCaml to F#. > can it compile to native code? Yup, https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... > how good is the language support experience in vscode? Pretty good, https://ionide.io https://ionide.io (but I personally prefer JetBrains Rider) > any reason not to do it? Compilation speed, some OCaml language features?
- xpressvideoz 4y agoOh so they're finally releasing a "true" AOT. It was advertised to have been released several years ago but they have continuously pushed back the date. Good to see they're finally delivering it. Also great to see a fellow HNer who uses the `service-name@personal-domain` email scheme, as per your profile!
- debugnik 4y ago> Pretty good, https://ionide.io https://ionide.io It pains me to admit it because I really like F# but, with due respect to the developers, Ionide and its related projects are the most unstable toolchain I've ever used. Spend half a day reloading the editor because the extension keeps hanging on non-trivial MSBuild only to discover that the formatter has truncated in half one of the files you worked on due to a soundness bug. (OCaml's editor support, in contrast, is quite stable.) Rider is the best editing experience I've had with F#, by far.
- tromp 4y agoOCaml and F# are cool, but have you tried Haskell?
- exebook 4y agoOCaml is one of those languages that has it's own compiler backend. I might have forgotten but I think it even uses it's own linker. It is also backed by organisations, for example people from INRIA university and Jane Street company constantly improve it. I remember it also compiled small programs in a few milliseconds, something LLVM based languages cannot do.
- orlp 4y agoLLVM needs a competitor in the generic compiler backend space. There is no pressure, nothing fanning the heat to drive improvement.
- pjmlp 4y agoGCC and Graal come to mind. However LLVM contribution level is at the same range as Linux kernel contributions, so it will be quite hard to change course.
- JonChesterfield 4y agoMLIR?
- xavxav 4y ago> INRIA university tiny nit, but INRIA is not a university but rather a national network of labs.
- rmanolis 4y agoDoes it have concurrency or/and asynchronous programming?
- octachron 4y agoYes, it does. And the new major upcoming version, OCaml 5, even supports parallelism and algebraic effects.
- talex5 4y agoHere's an example using OCaml 5 to run multiple fibers concurrently (look - no monads!): https://github.com/ocaml-multicore/eio#fibers https://github.com/ocaml-multicore/eio#fibers
- xavxav 4y agoOCaml is an impressive language on many fronts: compile time, speed, memory usage, but then is almost crippled beyond usage by a few unfortunate decisions / (lack of) features: - Dependency management, despite progress `opam` is hopeless brittle because no one uses lock files, good luck building a project that's more than 3 months old. Additionally, by default everything is installed into a global 'switch' and only one version of each package can exist in it. - Build tooling: things are finally improving with `dune`, but the amount of packages that are running hyper-complex Makefile based build systems is incredibly frustrating. It can be very difficult to add a dependency or change the layout of these projects if you aren't an expert in arcane Make sigils. - Error messages: again, finally improving, but the number of times I've gotten errors like "line 78 Syntax Error"... I know that parser generators are appealing academically / intellectually but there's a reason major industrial compilers use recursive descent. - Documentation: Seemingly non-existent for most packages and the tooling is quite poor compared to peer languages (Haskell, Rust). - More controversially, I think that modules are a worse solution in practice than typeclasses / traits. The automatic instance resolution coherence brings is a huge ergonomics win, and it also allows for more ecosystem wide collaboration in practice. I know that modular implicits are supposed to bring the 'best of both' but that doesn't even exist yet. None of the problems above are unfixable but they collaborate to make working in OCaml a very frustrating experience for me, even worse because through them I can see what is actually a quite nice language.
- steinuil 4y agoRe: dependency management and build tooling: these days I'm using opam-monorepo (https://github.com/tarides/opam-monorepo https://github.com/tarides/opam-monorepo, previously known as duniverse) to manage dependencies and it's working out pretty well for me. It vendors all dependencies into a node_modules-like directory inside the projects and writes an opam-compatible lockfile, and it builds all the dependencies using dune. For the most widely used packages that don't already use dune it uses an overlay containing dune ports at https://github.com/dune-universe/opam-overlays https://github.com/dune-universe/opam-overlays.
- sausagefeet 4y agoI have been an Ocaml user for a decade at this point and using Ocaml in the tech stack for the business I'm building. In my opinion: - Dependency management is not great in opam. I find it especially frustrating that the tried to be really clever with a SAT solver and it rarely does what I want it to do. That being said, I rarely run into issues with old builds of something failing. I only have a few projects on opam and I will get PRs for fixing my project to support later builds. The bigger issue, IMO, is there is no great way to mirror all the deps your project needs locally so you don't have to worry about them disappearing. - I have never run into the issue you've described here. In general, a package on opam just builds. I rarely have to modify an existing package, but when I do it has not been an issue. - Error messages aren't great, but I have never really hit this Syntax Error problem you run into (maybe you are one of those people that uses ";;"?). Error messages have also improved a lot over the last few versions, even around polymorphic variants, which has been a much welcomed improvement. - Documentation of third party libraries is unequally distributed. I find the language and std lib well documented, but for a library it depends. There is lots of room for improvement here. But on the flip side: I've run into plenty of libraries in Rust with bad documentation as well. - I think this comment on modules is a big unfair. Modules were never designed to solve the problem of typeclasses or traits. As you mentioned, module implicits might allow modules to be used as a solution, though. But on the flip side, type classes and traits struggle to express what modules can express, and I dearly miss modules when I work in any other language. I agree: Ocaml is a very nice language.