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

Why We Use OCaml

tech.esper.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Why We Use OCaml

#91

Post by knz42 »

JamesBarney wrote: post #42
jonsterling wrote: post #32

Earlier quoted context omitted.

F# is an ML without any of the things which make ML good (modularity). It's a breath of fresh air if you're on a Microsoft platform, but if you can use OCaml, it is superior.

Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.

Hey James, I know that most .NET/Windows programming has ALL-CAPS names but you should still write "OCaml" with small letters a-m-l.

Re: Why We Use OCaml

#92

Post by Dn_Ab »

JamesBarney wrote: post #42
jonsterling wrote: post #32

Earlier quoted context omitted.

F# is an ML without any of the things which make ML good (modularity). It's a breath of fresh air if you're on a Microsoft platform, but if you can use OCaml, it is superior.

Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.

Where Ocaml is better:

- Single Core Speed (Ocaml is fast)

- native compilation without requiring some installed runtime

- Polymorphic Variants (Last I read, to be used only when regular variants are not sufficient)

- Modules and Functors (there's a proof of principle for F# supporting these)

- GADTs (allow for richer more expressive types, much more flexibility than regular algebraic data types)

- camlp4

- more pervasive structural typing, higher kinded types...type system is not weighted down by a foreign runtime

Where F# is better:

- better support for not-sequential programming in all its forms: actors with lightweight threads, parallel, async, gpu (many production ready choices), reducers (and Go style channels if they accept joinads)

- Active Patterns are a dark horse

- Type Providers are curious. They seem like dumbed down metaprogramming at first but it's one of those cases where constraints benefit creativity. Although you could certainly do what they provide (and more easily at times) with metaprogramming, I've never seen metaprogramming used that way before. And especially with the proliferation of APIs, stuff like json inference makes going to a language without them like going from 3 monitors to one.

- Units of Measure

- More libraries and Better cross platform support via Xamarin and unity3d

- #light. F# syntax is a tiny bit cleaner and surprisingly close to Python at times.

- Computation expressions/do notation are not quite monads and can be more flexible. Tomas Petricek argues the case here: http://tomasp.net/blog/2013/computation-zoo-padl/

Why the above do not matter: The MLs tend to be more pragmatically focused than other functional languages and espouse using as little fancy code as possible. The core of both languages are the same, so much of the time and ignoring library choices, you won't be seeing many differences between F# and OCaml. It's more like Portuguese vs Spanish than English vs German.

Re: Why We Use OCaml

#93

Post by avsm »

quacker wrote: post #87
avsm wrote: post #69

Earlier quoted context omitted.

While your mileage will vary depending on the nature of your startup, I can point you to a paper we wrote summarising our experiences using OCaml to build the XenServer toolstack in a startup environment [1]. You should bear in mind that OCaml represents almost twenty years of continuous development (see the history chapter in Real World OCaml [2]), with a community steeped in some of the most cutting edge technology…

by joining the Caml Consortium (very cheap), we got access to the core developers and a yearly face-to-face. We're talking about Xavier Leroy and Damien Doligez here. Do you get that with Java? What do you find most useful about talking to core OCaml devs? If you were developing in Java, do you think you would see a similar benefit from talking to core Java devs? How do you find the OCaml standard library compares to…

> What do you find most useful about talking to core OCaml devs? If you were developing in Java, do you think you would see a similar benefit from talking to core Java devs?

OCaml (and Java, and Python, and any other "old" language) evolves in small steps to avoid breaking existing code. A forum like this allows language developers making those design decisions to check them with big users, as well as to gather the qualitative feedback that only comes from trying to use a feature in a production system.

For example, OCaml's recent move in 4.02 towards immutable strings has generated a lot of debate [1] about the right tradeoffs to make with respect to backwards compatibility, and a number of the module system improvements such as module aliases have been driven by big libraries such as Core (to reduce compilation time and binary sizes).

> How do you find the OCaml standard library compares to standard libraries from other languages? Is it expansive?

I consider the OCaml "standard library" to actually mean the compiler standard library, since it really exists for the core toolchain to use. There are several alternatives that are one "open" statement away -- I've co-written a book about the Core library (see https://realworldocaml.org) for instance, which is extremely expansive. The OPAM package manager makes it trivial to use third-party packages now (http://opam.ocaml.org), so the distinction between standard library or not is pretty moot now.

> Do you find yourself reaching for 3rd party libraries frequently (or writing your own)?

I've written my own operating system in OCaml, so I'm possibly the wrong person to ask about that...

[1] http://blog.camlcity.org/blog/bytes1.html

Re: Why We Use OCaml

#94

Post by fleitz »

avsm wrote: post #69
claudiusd wrote: post #25

> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefit…

While your mileage will vary depending on the nature of your startup, I can point you to a paper we wrote summarising our experiences using OCaml to build the XenServer toolstack in a startup environment [1]. You should bear in mind that OCaml represents almost twenty years of continuous development (see the history chapter in Real World OCaml [2]), with a community steeped in some of the most cutting edge technology…

Fully agree, doing what everyone else is doing is not managing risk, it's just taking on the same risk as everyone else.

Re: Why We Use OCaml

#95

Post by talder »

ALee wrote: post #63

Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large a…

How do you feel about the fact that OCaml has no capacity for "real" multithreading? It seems that such capability will only become more important in the future.

Re: Why We Use OCaml

#96

Post by [deleted] »

advocaat23 wrote: post #76

Cool tech, but ... I went to the About-Page and I got the following message out of it: "We all want to spend our time dooing meaningful things so we ... bla bla ... have to make an app for that". Come on, I think this is just bullshit. Yes, the premise is correct, people are working too much on stuff they don't like (and we have to fix that), but solving this problem via some time-managment-assistant-whatever-app (oh…

[deleted]

Re: Why We Use OCaml

#97

Post by kazagistar »

gcv wrote: post #79
tikhonj wrote: post #56

Earlier quoted context omitted.

People say functional programming is hard, but it feels just like a knee-jerk reaction. In practice, it doesn't seem to be much of an issue. For example, IMVU gave an experience report at BayHac about switching from PHP to Haskell; they found that onboarding a new employee (without significant Haskell experience) took about as much time as it did for their particular flavor of PHP (conventions, frameworks... etc)[1].…

I've always been curious about Jane Street. It seems like a too-good-to-be-true story. Picking an obscure but powerful alternative to C++ and Java for a highly-competent core team makes sense, and has been done by several banks. But hacking OCaml does not fit the personality profile of (m)any traders I've met — most will happily whip up a spreadsheet to help their work, but writing extensive software and learning Hin…

You don't have to write extensive software or have a deep interest in type systems to use ML languages. You just have to know enough of the syntax to understand the API and write some functions to work with provided DSLs.

Re: Why We Use OCaml

#98

Post by wcummings »

claudiusd wrote: post #25

> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefit…

>There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages.

For a project of moderate-to-high complexity, the advantage I gain as a developer by using a more powerful, if more esoteric language, hugely outweighs the time I spend building tooling/libraries etc..

RoR et al might win out for low-complexity projects, but as the project grows the power of the language quickly eclipses the advantages of pre-existing libraries and easy-to-find "talent".

>You will always need exceptionally talented developers to work on your code base

You should strive to hire these people anyway!

This is another non-issue, if you're hiring The Right Way: hiring smart people. I just started a job writing Java having never written Java before in my life (coming from a background in Perl, JS & Erlang), and in a previous position picked up Erlang on-the-job. It's pretty much a non-issue if you hire talented engineers.

Basho's experience with Erlang illustrates these points well: http://basho.com/erlang-at-basho-five-years-later/

> Will OCaml help you get to market faster? I don't know.

They know, this article is basically them explaining that they feel ocaml gives them a competitive advantage. PG said the same thing about viaweb using Lisp vs. Perl/C+CGI

Re: Why We Use OCaml

#99

Post by eridius »

Dewie wrote: post #61
eridius wrote: post #28

Interesting list. I'm curious if the author has looked at Rust and how they think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an identical feature list, but it seems to me to perhaps be a lot more practical for a lot of work than OCaml (largely because Rust can basically be used anywhere C++ can be, and it has good support for C FFI).

Why do you think Rust is applicable, here? It isn't obvious to me that these people would benefit from a language that can be used anywhere that C++ can be .

Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that.

And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching.

It also has benefits that OCaml doesn't, such as full memory safety, no required garbage collector, and good C FFI (I'm no OCaml programmer but glancing at the beginning of the Real World OCaml's chapter on FFI, it appears OCaml uses dlsym() to look up functions at runtime, whereas Rust can outright link to them like any C program would). I'm sure there are others too, but I'm not familiar enough with OCaml to list them. I'm also not sure what the performance of OCaml is like (a glance at the Computer Language Benchmarks Game suggests it's often slower than C++), but Rust aims to have C++-equivalent performance.

Re: Why We Use OCaml

#100

Post by eridius »

dbpatterson wrote: post #39
eridius wrote: post #28

Interesting list. I'm curious if the author has looked at Rust and how they think it stacks up. Rust is obviously still pre-1.0, and it doesn't have an identical feature list, but it seems to me to perhaps be a lot more practical for a lot of work than OCaml (largely because Rust can basically be used anywhere C++ can be, and it has good support for C FFI).

I think that, having used both of them, Rust is going to feel a lot lower level than OCaml. The single biggest thing is that it's pretty hard (slash near impossible) to write Rust code without thinking about memory allocation, which adds non-trivial mental overhead to the work. That isn't to put down Rust - I think they are the first language that actually has a static, type-checkable story about memory allocation, a…

Eh, I don't see that as a downside. And actually, I'm not sure that's even true. It's already apparent that a lot of people are using a lot of completely unnecessary allocation in Rust, precisely because they aren't thinking about what they're doing (and so are doing things like using heap-allocated String objects when they really just need &str slices, or using Box unnecessarily; this was one of the reason cited for moving away from the ~ sigil, as it was considered to "hide" allocation too much).

And speaking personally, I almost never have to consciously think about allocation, unless I'm doing really performance-sensitive work. The straightforward approach is usually correct.

Post reply on HN