What is OCaml used for? https://www.quora.com/What-is-OCaml-used-for?share=1
Further infos:
awesome-ocaml - A curated collection of awesome OCaml tools, frameworks, libraries and articles: https://github.com/ocaml-community/awesome-ocaml
OCamlPro Research and Development: https://www.ocamlpro.com/research-and-development/
OCaml Weekly News (RSS): http://alan.petitepomme.net/cwn/cwn.rss
- A package manager like NPM, but for native code: https://github.com/esy/esy
- A fast Node version manager: https://github.com/Schniz/fnm
- A fast replacement for dotenv-cli: https://github.com/ulrikstrid/reenv
- A fast JS bundler: https://github.com/fastpack/fastpack
- A native language server: https://github.com/jaredly/reason-language-server
The OCaml language and toolchain is very powerful... and I do believe ReasonML makes it more approachable, at least for a wider audience of developers comfortable with JavaScript-style syntax.
- A native GUI: https://github.com/revery-ui/revery
My other post in this thread proves the opposite.
Further than that, there are no more programs written in it for the same reason than there are no more programs written in any interesting languages, I guess; ie largely accidental.
What does this mean? I was under the impression the OCaml compiler did a decent number of floating point specific optimizations, like unboxed arrays and what not.
It never bothered me in Caml Light, let alone when Objective Caml was introduced.
x *. y +. z
let open Float in
x * y + z
Float.(x * y + z) let open Quaternion in
x * y + x module Quaternion = struct
let (+) =
...
let ( * ) =
...
end
let open Quaternion in
x * y + zI’ll also +1 the comments about ReasonML which is very promising.
Though I suppose these are both ”language” related — just not strictly the OCaml language.
Facebook Messenger is built using Reason. A few other smaller companies are using it too: https://reasonml.github.io/en/users-of-reason
Wow Air were using it though one probably can't blame that for their collapse.
I guess that list doesn't include straight Bucklescript users either. There are definitely companies out there who use it outside of Reason so the OCaml, in general, is getting some use in industry which is nice.
https://github.com/LiveAsynchronousVisualizedArchitecture/si...
process crashes are of course a problem in terms of bringing down the whole process, but that generally isn’t a problem for me.
Whereas in interprocess, each thread can do everything that the whole process is allowed to do, so a security exploit in e.g. file parser, opens the door for doing other stuff that a file parser shouldn't be allowed to start with.
An easy to use IPC is to use pipes, mailboxes, message queues, just like channels.
Yes it might be slower, but for a large set of problems it is fast enough.
in other instances, when programming concurrent programs, i have no worry of performance losses because, again, multicore support comes for free. that is more qualitative, but it is important. and it means my concurrent programs are actually concurrent.
The problem with 'no worry of performance losses' with multicore is that using multiple cores itself has a cost. You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety. So again, there's no such thing as a free lunch in multicore.
who said it was? (it isn’t.) you asked for examples, and i gave the most recent one.
> You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety.
you’re making a huge amount of assumptions and supposed “costs” here based upon the rather limiting nature of most programming languages when it comes to concurrency. most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it.
OK, but then, outside of that kind of use case, most applications are not trivially parallelizable like that.
> most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it.
Maybe I miscommunicated, but I don't mean that you literally are doing all these things, but that something is–some combination of the language, the runtime, and the developer. My point is that no matter who is doing it, these things have costs–runtime performance, memory use, limits on the usable data structures and programming techniques.
Coq proof assistant (https://coq.inria.fr). Well, you can say it is language-related, but it’s a lot more than that.
https://rwmj.wordpress.com/2017/06/04/new-in-libguestfs-rewr...
It’s definitely great for things like compilers, though. But I wouldn’t necessarily use it for a Web server.
Besides, there are also multiple processes as possible solution.
- the syntax is not great. I've heard it's one of the reasons why F# was born
- not many people use Ocaml, which makes it hard to find help
- not many good resources. The official documentation is really hard to parse and there isn't much besides it and the reference book (which reads more like a book than a reference).
- no good ways to debug, print objects, test, etc.
- no one seems to agree on what is the standard library or the correct packages to import (for example there are several Option package)