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

What I wish I knew when learning OCaml (2018)

baturin.org

Post reply on HN
Print view View original

61–70 of 88 posts

Re: What I wish I knew when learning OCaml (2018)

#61

Post by kragen »

bmitc wrote: post #55
kragen wrote: post #15

Earlier quoted context omitted.

The syntax is not great, the standard library is very sparse, and the error messages from the compiler and interpreter are terrible (and used to be worse). The OCaml team used to treat the native code compiler (ocamlopt) as a second-class citizen, but it's the implementation that matters for performance. Since the end of Dennard scaling about 15 years ago, OCaml's lack of multithreading has also been a pain point, on…

All those things you mentioned in the first two paragraphs are fixed by F#, however, it is still not popular. The reasons in that case are that .NET was not originally cross-platform, which was a major blunder for Microsoft, C#, and especially F#. The other is that people have some weird stigma against Microsoft, despite it not applying in many cases. Although they should have started off cross-platform, the transiti…

Not being labeled "Haskell" is fixed by F#?

And I don't know that F#'s syntax is better than OCaml's. Arguably it's worse. (I haven't tried using it so I don't know how the error messages are.)

Re: What I wish I knew when learning OCaml (2018)

#62

Post by Serow225 »

throwaway894345 wrote: post #51
bmc7505 wrote: post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

that’s pretty much F# :)

Re: What I wish I knew when learning OCaml (2018)

#63

Post by maficious »

throwaway894345 wrote: post #51
bmc7505 wrote: post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

Gleam

Re: What I wish I knew when learning OCaml (2018)

#64

Post by gpderetta »

throwaway894345 wrote: post #51
bmc7505 wrote: post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

with its shared-nothing-by-default thread model, rust would make for an excellent GC'd language as if it gave the ability of opting into GC on a per-thread basis with thread local heap and GC. Some relaxing of the shared-xor-mutable probably would need to be relaxed though.

I don't know how practical it would be to implement in practice.

Re: What I wish I knew when learning OCaml (2018)

#65

Post by eatonphil »

frou_dh wrote: post #39
eatonphil wrote: post #34

Earlier quoted context omitted.

Did you learn that from some other article? I couldn't find "lambda" in this page. I think it's too much to say that all Standard ML compilers work or one way or another. There are 6 major compilers and a number of minor ones. They don't really follow the same approaches in general.

At a higher level that that, it's cool that even in SML's already sparse surface-level syntax, quite of a bit of it is just sugar for each other: https://i.imgur.com/pkSg4xm.png

That may be the semantics of it and for simple compilers that may be a true transform. But as compilers get more mature they tend to specialize everywhere they can so the actual compiler doing this under the hood may or may not happen.

Re: What I wish I knew when learning OCaml (2018)

#66

Post by kragen »

octachron wrote: post #58
kragen wrote: post #52

Earlier quoted context omitted.

20 and 25 years ago, the attitude (as I remember it) was that the native-code compiler was not very important because the bytecode interpreter was fast enough for most uses. It's true that that is no longer the attitude. But if we want to understand why one language is more popular than another, we usually need to look at things that happened in the past, not just things that are happening right now. Even C's meteori…

Ah yes, it might be possible that during the time of Caml light, the bytecode compiler was for a time considered to be fast enough. I am not sure that a ephemeral stance from 25 years ago on an ancestor language still really matters nowadays.

I'm not talking about Caml Light or even Caml Special Light, which is when the native-code compiler was initially added. 25 years ago was 01997. Objective Caml was released in 01996 (and renamed OCaml in 02011).

Projects like KDE, the GIMP, GNOME, Lucene, Jython, LLVM, Asterisk, Audacity, CMake, and Danger that got started in C, C++, or Java in the 01997–02002 period are still based on those languages today. OCaml would have been a reasonable language for all of these, though a new interpreter for Python in OCaml would have lacked Jython's key feature, the ability to easily script other things written in Java.

(Danger? Well, Danger as such ended in 02011, but Andy Rubin founded Danger in 01999 and left to found Android in 02003, which ended up making a Java-based smartphone much like Danger's Java-based smartphone, but less locked down.)

The fact that Java focused heavily on performance starting in 01997, when Sun bought Animorphic, meant that a lot of things were able to be written in Java in the 02000s, things that were previously just unthinkable. Lucene predates HotSpot by a bit, but the whole Hadoop ecosystem that grew out of it only makes sense in a HotSpot world. Minecraft obviously pushes performance heavily. SPARK is written in Scala, but OCaml would have been a good fit too—if Hadoop had gone that direction.

Re: What I wish I knew when learning OCaml (2018)

#68

Post by kragen »

octachron wrote: post #56
kragen wrote: post #50

Earlier quoted context omitted.

During those 25 years OCaml gained native-code compilers for new architectures, labeled arguments, and polymorphic variants, among other things. How could it be mostly a manpower issue?

Work and time contributed by open source collaborators on their free or academic time cannot be magically converted from one subsystem to another. It is honestly very easy to have progress on the aspects that spark interest while some subsystem are starved from attention when there are no full-time developers working on a project.

That's true, but that doesn't mean there was no manpower to fix that error message; it meant that fixing it wasn't a priority to the people who were working on OCaml at the time. You're just offering an explanation for why it wasn't a priority: fixing it didn't spark their interest.

Re: What I wish I knew when learning OCaml (2018)

#69

Post by mumblemumble »

Serow225 wrote: post #62
throwaway894345 wrote: post #51

Earlier quoted context omitted.

I like Rust for syntax, tooling, and ML ideas but I wish there was a "Rust-lite" that was garbage collected.

that’s pretty much F# :)

As a long-time F# user and current Rust learner, I would say the similarities are mostly cosmetic.

First and foremost, F# is functional-first, while Rust isn't really functional. Rust takes some useful features from functional languages, to be sure, but the overall paradigm is more procedural. A lot of key functional idioms and design patterns don't really fly in Rust because it's difficult-to-impossible to make them play nice with its memory management model.

Rust has traits, but not OOP. F# has OOP but not traits or typeclasses.

F# is immutable by default, and discourages mutability. Rust is immutable by default, but embraces (and tames) mutability.

Re: What I wish I knew when learning OCaml (2018)

#70

Post by lf-non »

bmitc wrote: post #53
bmc7505 wrote: post #40

ML really is a beautiful and under-appreciated family of languages. Haskell is a bit too supernatural for my taste, but ML and its derivatives hit the sweet spot between powerful type systems and natural syntax. As a Kotlin developer, I find reading OCaml code a breeze and the compiler is refreshingly snappy (much faster than Gradle). I just wish it had better developer tools.

I fully agree. F# is my favorite language, and it almost feels like a statically typed Scheme at times, just with built-in pattern matching and pipes thrown in. It's a really great way to program, and it's easy to go imperative or OOP when needed without friction. The only thing missing from F# is an Elixir/Erlang/OTP-like process system (`MailboxProcessor` is pretty good though), but then again, every language excep…

I am not further enough in my F# journey to have tried this, but you could technically pair it with orleans for actor oriented systems ?

Love the language though I have spent only a week working with it. It seems to have a lot of things I liked in Kotlin.

Post reply on HN