Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I love OCaml (2023)

mccd.space

Post reply on HN
Print view View original

221–230 of 313 posts

Re: Why I love OCaml (2023)

#221

Post by tempodox »

mbac32768 wrote: post #140
delta_p_delta_x wrote: post #135

Earlier quoted context omitted.

> nowhere near as good as OCaml I'd really like to hear more about this. From what I've used of F# and OCaml, both languages are around 95% the same.

I'll give you my top 3. F# is worse because the type inferencing isn't as good. You need to type annotate in more places. It's a drag, because it feels like a missed opportunity to let the machine do work for you. Additionally, one of the most pleasant and unique features of OCaml, strong named arguments, doesn't exist in F# (except in methods or whatever). Most programming languages don't have this (or it's hamfiste…

And you cannot have default arguments for function parameters in F#. They are only allowed with methods.

Re: Why I love OCaml (2023)

#222

Post by kragen »

MrJohz wrote: post #219
kragen wrote: post #217

Earlier quoted context omitted.

In Haskell, yes, because laziness permits deforestation. ML, including OCaml, is eager and consequently cannot do this.

I believe it's possible in theory - Koka has a whole "functional but in-place" set of compiler optimisations that essentially translate functional algorithms into imperative ones. But I think that's also possible in Koka in part because of its ownership rules that track where objects are created and freed, so might also not be feasible for OCaml.

I mean, the set of valid deforestation transformations you could do to an OCaml program is not literally the empty set, but OCaml functions can do I/O, update refs, and throw exceptions, as well as failing to terminate, so you would have to be sure that none of the code you were running in the wrong order did any of those things. I don't think the garbage collection issues you mention are a problem, though maybe I don't understand them?

Re: Why I love OCaml (2023)

#223

Post by tempodox »

timhh wrote: 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.

Funny how tastes differ. I'm glad it has a syntax that eschews all the noise that the blub languages add.

Re: Why I love OCaml (2023)

#224

Post by yujzgzc »

abathologist wrote: post #178
yujzgzc wrote: post #58

I loved Ocaml but now I love TypeScript more. It's got about the same amount of type safety, the ergonomics are better to me, and the packaging and ecosystem tooling are leaps and bounds above anything else.

> It's got about the same amount of type safety What?

Both languages have robust and expressive type systems. My experience is that TypeScript's is also more flexible. In Ocaml everything is cool as long as you stick with the functional programming style. But every "interesting" program also has imperative, non-functional-programming parts, and TypeScript has really good automatic "type narrowing" features that make that part much safer in my experience. In Ocaml however, type narrowing isn't automatic at all.

Re: Why I love OCaml (2023)

#225

Post by deredede »

olivia-banks wrote: post #203
spooky_deep wrote: post #183

Earlier quoted context omitted.

A good compiler will make the lists disappear in many cases. No runtime overhead. I actually love single linked lists as a way to break down sequences of problem steps.

I’m curious what you mean. Surely there’s the overhead of unpredictable memory access?

Not GP but bump allocation (OCaml's GC uses a bump allocator into the young heap) mitigates this somewhat, list nodes tend to be allocated near each other. It is worse than the guaranteed contiguous access patterns of a vector, but it's not completely scattered either.

Re: Why I love OCaml (2023)

#226

Post by abathologist »

yujzgzc wrote: post #224
abathologist wrote: post #178

Earlier quoted context omitted.

> It's got about the same amount of type safety What?

Both languages have robust and expressive type systems. My experience is that TypeScript's is also more flexible. In Ocaml everything is cool as long as you stick with the functional programming style. But every "interesting" program also has imperative, non-functional-programming parts, and TypeScript has really good automatic "type narrowing" features that make that part much safer in my experience. In Ocaml howeve…

TypeScript certainly has a more complicated and flexible type systems in many respects, but it is not the same w/r/t safety. It is quite common to run across `any`s all over the place in TypeScript code, and there is no such thing in OCaml. TypeScript's systems is explicitly unsound (i.e., not fully type safe) by design: https://www.typescriptlang.org/docs/handbook/type-compatibil...

Re: Why I love OCaml (2023)

#227

Post by throwa567543 »

mikaeluman wrote: post #143

I like the ML languages, and as many others I spent a lot of time with F#. I would love to spend more time but even though Microsoft gives it plenty of support (nowhere near as much as C#), the community is just too small (and seems to have gotten smaller). Looking at https://www.tiobe.com/tiobe-index/ numbers fall off pretty quickly from the top 5-7. Guessing this is the same for OCaml, even if the language as such…

Anecdotally we are using F# more than ever before, and it works for us for a large sized organisation. Fast code, it is keeping up with the .NET features that matter for that (e.g. spans), and tbh has still been getting better over the years. In fact I find some of the new features like Span, SIMD/intrinsics somewhat synergise with existing F# features (e.g. inline). C# IMO still hasn't quite caught up but is getting there. Comparing to Go/Java/etc I can usually get faster code out of the .NET runtime as well especially in our domain which requires large scale computation. If I was to move to something else for our domain it would be C++ or Rust. F# piggy backing of the .NET platform in general, has a decent ecosystem and easy onboarding cross platform and gets a lot "for free" (e.g. CLI, GC improvements).

Community is an interesting thing, and for some people I guess it is important. For me language is just a tool having coded for quite some time and seen communities come and go; don't care about being known or showing an example per se. If the tool on the balance allows me to write faster code, with less errors quicker and can be given to generic teams (e.g. ex Python, JS devs) with some in house training its a win. For me personally I just keep building large scale interesting systems with F#; its a tool and once you get a hang of its quirks (it does have some small ones) quite a good one that hits that sweet spot IMO.

My feeling however is with AI/LLM's communities and syntax in general is in decline and less important especially for niche languages. Language matters less than the platform, ecosystem, etc. Its easier to learn a language then ever before for example, and get help from it. Any zero cost abstraction can be emulated with more code generation as well as much as I would hate reviewing it. More important is can you read the review the code easily, and does the platform offer you the things you need to deliver software to your requirements or not and can people pick it up.

Re: Why I love OCaml (2023)

#228

Post by hyperhopper »

olivia-banks wrote: post #204
VirusNewbie wrote: post #177

Earlier quoted context omitted.

You would be surprised how many Googlers think the Go team is making bad decision after bad decision.

How so? I’m not that familiar with Go anymore.

Search any Go codebase for err != nil, for starters.

Re: Why I love OCaml (2023)

#229

Post by MrJohz »

kragen wrote: post #222
MrJohz wrote: post #219

Earlier quoted context omitted.

I believe it's possible in theory - Koka has a whole "functional but in-place" set of compiler optimisations that essentially translate functional algorithms into imperative ones. But I think that's also possible in Koka in part because of its ownership rules that track where objects are created and freed, so might also not be feasible for OCaml.

I mean, the set of valid deforestation transformations you could do to an OCaml program is not literally the empty set, but OCaml functions can do I/O, update refs, and throw exceptions, as well as failing to terminate, so you would have to be sure that none of the code you were running in the wrong order did any of those things. I don't think the garbage collection issues you mention are a problem, though maybe I do…

Part of what Koka's functional-but-in-place system relies on is the Perceus program analysis, which, as I understand it, is kind of like a limited Rust-like lifetime analysis which can determine statically the lifetime of different objects and whether they can be reused or discarded or whatever. That way, if you're, say, mapping over a linked list, rather than construct a whole new list for the new entries, the Koka compiler simply mutates the old list with the new values. You write a pure, functional algorithm, and Koka converts it to the imperative equivalent.

That said, I think this is somewhat unrelated to the idea of making linked lists disappear - Koka is still using linked lists, but optimising their allocation and deallocation, whereas Haskell can convert a linked list to an array and do a different set of optimisations there.

See: https://koka-lang.github.io/koka/doc/book.html#sec-fbip

Re: Why I love OCaml (2023)

#230

Post by gigatexal »

int_19h wrote: post #185
kristianp wrote: post #149

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…

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.
Post reply on HN