Live data from Hacker News

Why I love OCaml (2023)

mccd.space

231–240 of 313 posts

Re: Why I love OCaml (2023)

#231
post #200

Earlier quoted context omitted.

> has an edge on some domains due to having unboxed types If a language makes "unboxed types" a feature, a specific distinction, and has to sell "removing global lock" as something that is a massive breakthrough and not table stakes from 1.0, it can't possibly be compared to F# in favourable light.

Where can I read more on F# unboxed types? My searches are only turning up examples of unboxed primitives. Where's the equivalent to https://hackage-content.haskell.org/package/vector-0.13.2.0/... ?

F# uses the CLR term "value types" instead, or sometimes "struct" types as in the C# keyword.

These are usually defined with the [] attribute over a regular type definition, or using the struct keyword before tuple/anonymous record types. Also, the original 'T option type now has a value-type successor 'T voption.

Re: Why I love OCaml (2023)

#232

Earlier quoted context omitted.

The reason why functional languages like linked lists so much is because they are very easy to make immutable without a lot of pain all around. If you implement an immutable vector in a straightforward way, though, you basically need to do a lot of copying for any operation that needs to construct one (the rigmarole with immutable strings, and existence of hacks such as StringBuilder, is a good illustration of the pr…

That makes sense. But LinkedIn lists are horrible for cache efficient things no? I think there was an article on HN from a Golang perspective padding structs or something such that they are efficient wrt to cache hits.

> But LinkedIn lists are horrible for cache efficient things no?

LinkedIn Lists you say? (Sorry. (But not that sorry.))

Edit meta sidenote: in this modern meme world, it's virtually impossible to know if a typo is a typo or just a meme you haven't heard of yet.

Re: Why I love OCaml (2023)

#233

Earlier quoted context omitted.

> * Like all FP languages it has a weird obsession with singly linked lists, which are actually a pretty awful data structure This made me chuckle. I've had that thought before, shouldn't the default be a vector on modern devices? Of course other collection types are available.

The reason why functional languages like linked lists so much is because they are very easy to make immutable without a lot of pain all around. If you implement an immutable vector in a straightforward way, though, you basically need to do a lot of copying for any operation that needs to construct one (the rigmarole with immutable strings, and existence of hacks such as StringBuilder, is a good illustration of the pr…

Which is a pity, you can fit entire small arrays in a cache line to end up with no pointer chasing at all.

Re: Why I love OCaml (2023)

#234

For something a bit more modern but still related to OCaml, one can try F#.

F# is a practical choice but the language features are quite far behind OCaml now. {Ecosystem, Functors} - choose 1

What about a strict subset of C#. The use case for F# seems to be shrinking because MS is putting all its energy in language.

Re: Why I love OCaml (2023)

#235
post #5

Earlier quoted context omitted.

What is this alleged friction? Because plenty of people have been shipping great projects in Ocaml since it was released so it doesn’t seem to be much of an issue to many. I doubt Ocaml will be surpassed soon. They just added an effect system to the multicore rewrite so all things being considered, they seem to be pulling even more ahead.

Alleged? Come now. Beginners face the following problems: there's multiple standard libraries, many documents are barely more than type signatures, and data structures aren't printable by default. Experts also face the problem of a very tiny library ecosystem, and tooling that's often a decade behind more mainstream languages (proper gdb support when?). OCaml added multicore support recently, but now there is the who…

You probably know it, but Common Lisp May be a bit dated but it’s extremely modern in terms of features since you can add almost any feature to the language in libraries! I use it exactly because it’s old and battle tested and I don’t need to wait years for a language designer to give me a feature , I can just add it myself, though these days it has everything done already!

Re: Why I love OCaml (2023)

#236
post #157

Earlier quoted context omitted.

I wish I could make a list like this about rust in this place and not be flagged.

I don't think you would be flagged. Rust definitely has flaws: * Compile time is only ok. On par with C++. * Async has a surprisingly number of footguns and ergonomic issues. * There's no good solution to self-borrowing or partial borrows. * While using macros is fine, writing them is pretty awful. Fortunately you rarely need to do that. Relatedly it is missing introspection support. * Sometimes the types and lifetim…

The problem for me is that instead of focusing on the problem at hand and the business logic, I have to focus on the Rust memory model and the borrow checker. And seems very verbose.

Thing is, if I sketch something in pseudocode, I should be able to translate it to any mainstream programming languages. With Rust I can't just do that, I have to bend the problem to fit the way the language works.

Re: Why I love OCaml (2023)

#237

Earlier quoted context omitted.

I would suggest that people interested in using OCaml on Windows (or indeed, OCaml at all) try F# instead. It is still an ML-family language. Incidentally, by targeting the CLR, F# is considerably more deployable (both to users and to developers) than OCaml is. Plus, any old NuGet library written in C# or VB.NET can be used almost trivially in F#. This also solves the problem OP listed about a tiny ecosystem, because…

To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutations on n letters? Use all cores in parallel. C++ 100 19.57s Rust 96 20.40s F# 95 20.52s Nim 75 26.04s Julia 64 30.40s Ocaml 48 41.07s Haskell 41 47.64s Chez 39 49.53s Swift 33 58.46s Lean 7 278.88s Tarjan, n = 10 Nyx - Apple M4 Max - 12 performance and 4 effi…

I would really like to read more about this!

Re: Why I love OCaml (2023)

#238
post #96

> why isn’t OCaml more popular I've used OCaml a bit and found various issues with it: * Terrible Windows support. With OCaml 5 it's upgraded to "pretty bad". * The syntax is hard to parse for humans. Often it turns into a word soup, without any helpful punctuation to tell you what things are. It's like reading a book with no paragraphs, capitalisation or punctuation. * The syntax isn't recoverable. Sometimes you can…

> The syntax is hard to parse for humans This was my problem as well, the object oriented related syntax is just too much. ML of which caml is a version of, has really tight syntax. The “o” in ocaml ruins it imo.

No offense but the only time I have encountered objects in Ocaml was while using LablGTK a long time ago and the object syntax was pretty clean and not far from the module one. They are also structurally typed which is very handy.

Considering it only impacts a fairly small subset of the language, could you explain how it supposedly ruins everything?

Re: Why I love OCaml (2023)

#239
The problem I see for the adoption is that the landscape is very fragmented.

ML is a family of languages and we have StandardML with different implementations, OCaml with official path and JS path, F# and whatnot.

This is the problem for Lisp, too as there are many Lisps.

Re: Why I love OCaml (2023)

#240
post #150
post #72

Earlier quoted context omitted.

Having loops is not the defining feature that separates functional from imperative. Where did this idea come from? I'm suddenly seeing it in a lot of places.

It is not the defining feature but loss of the loop is one of the most obvious differences for people who look at a functional language Rust has immutability, pattern matching, etc, but it remains an imperative language with "some functional features". Or this is my subjective analysis.

So is Haskell not functional? Or an imperative language with some functional features?

    -- ghci> example
    -- Triangular number 1 is 0
    -- Triangular number 2 is 1
    -- Triangular number 3 is 3
    -- Triangular number 4 is 6
    -- Triangular number 5 is 10
    example = runEff $ \io -> evalState 0 $ \st -> do
      for_ [1..5] $ \i -> do
        n  show i  " is "  show n
        effIO io (putStrLn msg)
        st += i
    
      where
        st += n = modify st (+ n)
(This is not a trick question. Simon Peyton Jones described Haskell as "the world's finest imperative language" [1], and I agree. This code is written using https://hackage.haskell.org/package/bluefin)

[1] Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell

Post reply on HN