Live data from Hacker News

Reflections on my first completed application in OCaml

discuss.ocaml.org

21–30 of 42 posts

Re: Reflections on my first completed application in OCaml

#21
post #15
post #4

My biggest frustration with the Ocaml is with third-party libraries documentation. The majority of the docs are just function signatures without explanation, let alone usage examples. The language however is quite nice and the stdlib is fairly complete. Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.

It's funny that I could say the opposite about Rust if you asked what I enjoy most about the ecosystem - many third party libraries have outstanding documentation. Wonder why is that - in the end, it's just some folks like you and me spending their free time writing those. Why is it different for different languages then, is it the tooling like rustdoc and docs.rs or just the standards set by the community? Not sure.

I've not been deeply involved in either so take my hunch for what it is:

OCaml is an academic language like Haskell. Academics tend to neglect documentation in general, be it because what they're working on is mostly self-serving, lack of time/enthusiasm or a tinge of elitism on that "this should be obvious and if not just read the code".

Rust adherents seem to really want to take over the world and they realize that great documentation is an enabler for that.

Also the standard libraries and compiler set a pretty strong precedent.

Re: Reflections on my first completed application in OCaml

#22

Earlier quoted context omitted.

Actual ocaml user here. User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. There are many perfectly good languages out there that address that need, so if ocaml doesn’t, so be it. Maybe I’m just in the minority - I like the fact that there are lots of languages out there, some of which choose not to cater to every possible development scenario. This i…

The ML family is really good at (safe!) string processing, e.g. the meme that they're only good for writing compilers. Lots of Web stuff is just that (DB queries, GET/POST parameters, HTML, templating, URLs, JSON, XML, etc.). Whilst lots of that can be done via bytes, there are certainly cases where Unicode is needed (e.g. finding word boundaries, case-insensitive comparison, etc.). Ocaml (and SML) have the enviable…

Even if you need, for example, word boundaries, you might be better off pretending that no non-ASCII non-word chars exist than pretending that everything is valid UTF-8 or whatever. Depends on your inputs and requirements.

Re: Reflections on my first completed application in OCaml

#23
post #4

My biggest frustration with the Ocaml is with third-party libraries documentation. The majority of the docs are just function signatures without explanation, let alone usage examples. The language however is quite nice and the stdlib is fairly complete. Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.

I wholeheartedly agree with everything you said! What’s making the PPX situation even worse is that they seem to break with every new release of the compiler.

I second this. I dislike the liberal usage of metaprogramming, especially in the context of a code base that you have to work on with multiple people. It adds another layer of concepts/complexity/magic that everyone in the team has to learn.

With PPX, the barrier to use metaprogramming has become lower (especially compared to camlp4), resulting in most modern Ocaml codebases depending on it. But the ergonomics of the end-to-end software delivery have not really followed: the fact that PPX's break between compiler versions means that in practice, a compiler upgrade becomes a very costly thing to do. It is difficult to make the case for this in an industrial setting, where languages with almost religious backwards compatibility are common (Java, C++, even Go). For Ocaml, it is especially sad, because the core language is already quite powerful and expressive, lowering the need for metaprogramming (imo).

For scenarios where code generation is needed, I prefer a separate code generation step, which produces explicit "standard" code (e.g. like protoc)

Re: Reflections on my first completed application in OCaml

#24
post #6

Earlier quoted context omitted.

Yes, it does. However a lot of it is driven by long-time ecosystem contributors and they generally work somewhat behind the scenes, presenting on the progress ~annually at conferences like ICFP. Here's the latest progress report, in case you're interested: https://www.youtube.com/watch?v=E8T_4zqWmq8 Now this is not the same language/community improvement system that many popular projects nowadays use, but OCaml has b…

> many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings I can't speak for actual Ocaml users, but I've personally rejected Ocaml for my user-facing webapps because of things like this. Treating unicode as something optional was fine for early 2000s, but it's really not fine today. Most user facing applications need…

> Treating unicode as something optional was fine for early 2000s, but it's really not fine today. Most user facing applications need first class support for internationalized strings much more than other stuff like Big_int that's actually implemented in Ocaml stdlib.

This is certainly a valid argument, but honestly most languages handling of Unicode is really poor to the point where I actually prefer OCaml's not handling it since then I can use dbunzli libraries and get stuff to work correctly. Just try reversing a Unicode string and you'll see all kind of languages "with Unicode support" fail miserably, e.g reversing 🇺🇦 into 🇦🇺.

Go outside the BMP and see how nearly nobody has bothered to implement proper support for Unicode glyphs, let alone word boundaries etc. Swift might be one of the exceptions but outside of that? Bummer. Bonus points to Python 3 for breaking compatibility because of Unicode and then doing it wrong anyway.

Re: Reflections on my first completed application in OCaml

#25

Earlier quoted context omitted.

Actual ocaml user here. User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. There are many perfectly good languages out there that address that need, so if ocaml doesn’t, so be it. Maybe I’m just in the minority - I like the fact that there are lots of languages out there, some of which choose not to cater to every possible development scenario. This i…

are there any advantages to using OCaml for making web apps?

ReScript (formerly called ReasonML), is an interesting option for web apps (especially the front-end part), if you are interested in Ocaml-like languages.

Language-wise, it is Ocaml with a different syntax layer, so all of the nice things about the language are still available.

Re: Reflections on my first completed application in OCaml

#26
post #14

Earlier quoted context omitted.

I am not american and use a european alphabet with more characters. So if I need to handle user input or parse files with data I need unicode handling, so even for non web apps it can be needed.

I am not american and use a european alphabet with more characters. So if I need to handle user input or parse files with data I need unicode handling, so even for non web apps it can be needed. And yet OCaml is French and its French authors do not feel constrained by the lack of unicode or they would have "scratched their own itch".

In all fairness, OCaml is somewhat historically centered on Latin1 encoding which does include French characters.

Re: Reflections on my first completed application in OCaml

#27
post #15
post #4

My biggest frustration with the Ocaml is with third-party libraries documentation. The majority of the docs are just function signatures without explanation, let alone usage examples. The language however is quite nice and the stdlib is fairly complete. Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.

It's funny that I could say the opposite about Rust if you asked what I enjoy most about the ecosystem - many third party libraries have outstanding documentation. Wonder why is that - in the end, it's just some folks like you and me spending their free time writing those. Why is it different for different languages then, is it the tooling like rustdoc and docs.rs or just the standards set by the community? Not sure.

Some of it is probably accident of history.

Some of it can be driven by external factors: javascript was the only choice for an important domain for a long time.

Some if it I think is due to attractive syntax, or tooling. Python for example, horrible runtime performance, but people were drawn to it for probably syntax and tooling reasons.

Comparing Rust and OCaml:

The OCaml syntax is a bit odd. I was quite taken by F#, which is a very similar language to OCaml, but with some of the cumbersome syntax removed. F# seemed quite nice, looking at OCaml it just felt horrible and I didn't want to deal with it. In practice I know it would be fine, just like you get used to Lisp and it's parens, but there is a real psychology there that turns people away.

OCaml has good runtime performance, but its not the kind of language that will draw in C/C++ programmers or work for domains where you need C or C++ currently. Lack of multi-core is a huge turn off for a lot of people. This is the era where multi-core is our only path to more performance!

Rust syntax is a little more familiar to people, the runtime performance is top notch, very good at leveraging more cores, and maybe most importantly the community has made a concerted effort to make the language as approachable as possible. With good/friendly documentation and community. Easy install process, decent editor support, etc. Go ask a question about "Which way is faster" in a C# forum, you get a lecture about how you shouldn't worry about that. On a Rust forum you get an deep dive into performance concerns and language design. This seems to have drawn in people from communities you wouldn't expect. A low level, complicated language that Ruby and Javascript developers are drawn to? An interesting result!

Re: Reflections on my first completed application in OCaml

#28
post #15

Earlier quoted context omitted.

It's funny that I could say the opposite about Rust if you asked what I enjoy most about the ecosystem - many third party libraries have outstanding documentation. Wonder why is that - in the end, it's just some folks like you and me spending their free time writing those. Why is it different for different languages then, is it the tooling like rustdoc and docs.rs or just the standards set by the community? Not sure.

Some of it is probably accident of history. Some of it can be driven by external factors: javascript was the only choice for an important domain for a long time. Some if it I think is due to attractive syntax, or tooling. Python for example, horrible runtime performance, but people were drawn to it for probably syntax and tooling reasons. Comparing Rust and OCaml: The OCaml syntax is a bit odd. I was quite taken by F…

> Python for example, horrible runtime performance, but people were drawn to it for probably syntax and tooling reasons.

Tooling? How so? Like the REPL? Because when I think of tooling, I think of things like IDEs, dependency management, and distribution. Python has one of those things now (IDEs/notebooks), but even that took a while, IMO.

Python is a weird case study for me. I'm not trying to flame war or anything- just pointing out my own blind spots and/or biases. But I just don't see much of anything redeeming about the language. It can be pretty easy to read, but I don't think most code I've seen actually is easy to read/follow.

Re: Reflections on my first completed application in OCaml

#29
post #3

Ocaml is rock solid as a foundation, yet the ecosystem appears to be very fragmented. For example, not only does Ocaml not support unicode strings natively, there are several competing libraries offering this functionality. This is just bizarre. Why is it like this? Not unicode specifically but like, in general. Doesn't Ocaml have some kind of language improvement process?

I get the distinct feeling that Ocaml’s leadership isn’t very interested in making a practical language, but rather playing with abstract type system ideas. Which is too bad because it clearly has a lot of potential. At this point, I think Rust will end up eating a lot of Ocaml’s potential market—Rust’s weakness is that memory management is harder than OCaml, but even that has become significantly easier between non-lexical lifetimes and rust-analyzer, and the pace of development of the Rust language is very fast while Ocaml moves like a glacier (still waiting on multicore!).

Re: Reflections on my first completed application in OCaml

#30
post #3

Ocaml is rock solid as a foundation, yet the ecosystem appears to be very fragmented. For example, not only does Ocaml not support unicode strings natively, there are several competing libraries offering this functionality. This is just bizarre. Why is it like this? Not unicode specifically but like, in general. Doesn't Ocaml have some kind of language improvement process?

I get the distinct feeling that Ocaml’s leadership isn’t very interested in making a practical language, but rather playing with abstract type system ideas. Which is too bad because it clearly has a lot of potential. At this point, I think Rust will end up eating a lot of Ocaml’s potential market—Rust’s weakness is that memory management is harder than OCaml, but even that has become significantly easier between non-…

Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes related to multicore).
Post reply on HN