[cccbbbaaa]

It replaced Python for everything longer than a couple hundred of lines long for me. Fast language, fast compile times, clean(-ish) syntax, strong typing system, good ecosystem, and now multicore support? Yes please!

I must be more nuanced, though: existing libraries in opam are generally very, very good (I really like cmdliner), but many things may be missing. There is no alternative to Django, for instance. No serious IDE, except emacs. The standard library was so lacking that there is at least an alternative. The situation improved, but there's still missing stuff compared to Python.

[mattpallissard]

> There is no alternative to Django, for instance.

https://aantron.github.io/dream/, which is new and used by ocaml.org as well as OP

> No serious IDE, except emacs

and vim, and visual studio, and whatever else supports the LSP protocol via https://github.com/ocaml/ocaml-lsp

> The standard library was so lacking that there is at least an alternative.

While janestreet does have an publish their own stdlib, I personally try to stick to the stdlib whenever possible. Not to knock janestreet. I'm glad they're around and have contributed a bunch.

But overall I agree with you. It's been my favorite language to write in for years now. You can't just reach for off-the-shelf libraries for every little thing. Although the ones that do exist tend to be written halfway decently.

[winrid]

Dream is not a Django alternative. Django's powers come from probably one of (the best?) best ORMs in the industry, along with generated database schema migrations, and generated admin panels, to name a few. There's also the Django Rest Framework which makes putting together REST apis generated from your models super easy.

[mst]

Quite possibly the best for everything up to moderately complex.

You'd want to enter sqlalchemy (python), DBIx::Class (perl) and arguably Sequel (ruby) into the competition for 'best' though (I'm sticking to dynamic languages here) - exposed power and ability to drop to SQL for only parts of a query vary substantially between options.

[winrid]

On a related note I've been keeping an eye out for a really good ORM in a typed language that is good with relationships without tons of boilerplate, I guess it's hard to do. Hibernate has way too many annotations for my liking, and I'm not into the code generation of JOOQ. I bet you could build it in Nim pretty easily with its compile time stuff.

Diesel might get there in a few years... :)

I know people are gonna judge the whole ORM thing, but writing raw SQL is nice for performance but not for getting something out quickly, or prototyping, when you have lots of relationships.

[mst]

I stand by "an ORM should work as just a query generator and let you skip any object layer when you want to", "an ORM should be able to let you feed the object layer data from your own query" and "an ORM should let you mix and match programmatic query generation and literals to as granular an extent as possible" being table stakes if you have developers who actually like SQL.

There are a bunch of things I hate about the DBIx::Class stack (most of which were my poor decisions to begin with) but it gets those right. Example:

    $schema->resultset('Foo')
           ->where({ bar => $bar })
           ->update({
             baz => \'CASE quux WHEN 0 THEN baz - 1 ELSE baz + 1 END'
           });

would generate (the \'..' means 'reference to a scalar' in perl)

    UPDATE foo
    SET baz = CASE quux WHEN 0 THEN baz - 1 ELSE baz + 1 END
    WHERE bar => ?

and duplicate the relevant SQL generation guts across to a statically typed language wouldn't be horrible ... but every time I start trying to figure out how to get useful per-select-list types for query returns I end up tying myself in knots (easy enough for a simple-CRUD oriented ORM but once you're looking at expressions in SELECT that are query-specific it starts getting gnarly).

I think you may be right about Nim though and thank you for reminding me that I really need to get back to playing with that :)

(obligatory perl disclaimer - if you don't like perl, that's entirely fair, but in that case please steal the good parts of my/the rest of the DBIx::Class/SQL::Abstract team's ideas into your language of choice because developers who don't like perl deserve nice things too)

[winrid]

Oh, for sure on the SQL part. I do like being able to auto generate join tables and such, though!

[mdaniel]

> No serious IDE, except emacs.

https://plugins.jetbrains.com/plugin/9440-reasonml (72k downloads)

https://plugins.jetbrains.com/plugin/18531-ocaml (2k downloads)

I'm not in the ocaml ecosystem enough to evaluate their quality, but anything on top of IJ is for sure a serious IDE

[amelius]

Do you make GUIs in OCaml, and which libraries do or would you use?

And how about scientific computing (SciPy), deep learning (PyTorch etc.), or computational geometry (Shapely etc.)?

[yw3410]

GUIs are a PITA like in most languages.

I think most people use something which binds to gtk (such as lablgtk) or Qt.

For scientific computing there is Owl, but I haven't used it personally.

[amelius]

Hmm, I'll stick with Python for now.

The ecosystem of libraries is just too good.

Perhaps if OCaml made it very easy to interoperate with Python, I could give it a chance.

[yw3410]

There is pyml for interopt but I've never used it.

[xvilka]

Lablgtk[1][2] for GUI, Owl[3][4] for scientific computing.

[1] https://garrigue.github.io/lablgtk/

[2] https://github.com/garrigue/lablgtk

[3] https://ocaml.xyz/

[4] https://github.com/owlbarn/owl

[still_grokking]

I've heard good things about OCaml in general.

But "no serious IDE, except emacs" is a non-starter imho, if it's true.

They should really invest in this. Otherwise the language won't attract any professional developers in the large.

[yw3410]

Vscode works since there is an LSP server.

[trenchgun]

It is not true, as other commenters have said.