
Try OCaml - dna_polymerase
https://try.ocamlpro.com/
======
Labo333
I made those notebooks that can execute OCaml locally in-browser:
[https://louisabraham.github.io/domical/](https://louisabraham.github.io/domical/)

What do you think?

~~~
thangngoc89
Oh hey. I think we should collaborate somehow. I'm building
[https://sketch.sh/ml](https://sketch.sh/ml) which does the same thing
(execute OCaml locally in-browser)

~~~
nikhilsimha
This is the most constructive comment thread on HN in a long time!

------
xvilka
For a different materials and useful libraries for OCaml there is an "Awesome
OCaml" [1] repository.

[1] [https://github.com/rizo/awesome-ocaml](https://github.com/rizo/awesome-
ocaml)

------
kxyvr
What's the current state of OCaml on Windows? I'd love to use OCaml on more of
my projects, but this has been a roadblock for me.

What I'm looking for is the ability to produce native binaries without Cygwin.
I just checked without installing anything and it appeared as though OCPWin
was still the choice, but it's been stuck on OCaml version 4.01.0, which was
released five years ago. I know that OPAM is pushing toward a 2.0 release very
soon and I didn't know if that was going to coincide with a stable OCaml/OPAM
release on Windows, which would fix my problems. Does anyone have an idea?

~~~
nikofeyn
why don't you just use f#?

~~~
krylon
Now that you mention it, can somebody recommend some good starting points for
learning F#? That language has been on my bucket list for far too long.

~~~
markdoubleyou
The "F# for fun and profit" site by Scott Wlaschin is a great jumping-off
point:
[https://fsharpforfunandprofit.com/](https://fsharpforfunandprofit.com/)

I discovered it when I was reading a lot about domain driven design, and I
stumbled upon a talk by the author that kind of blew my mind:

"Domain Modeling Made Functional"
[https://www.youtube.com/watch?v=Up7LcbGZFuo](https://www.youtube.com/watch?v=Up7LcbGZFuo)

------
tlamponi
All nice and dandy, but please, for the sake of everything, can this site just
stop auto advancing on steps?!

I click the last one and advance a step before I can comprehend what this
command did or read any context. Breaks flow completely... And I'm just able
to be fine advancing manually once I feel I'm done with the current step.

Other nits:

* show the ;; in the step code snippets, at least at the beginning - else you may be confused fast if you hack around in the "terminal"

* add a 'run this snippet now' button to the code snippets, a small green triangle or whatever those IDEs are using nowadays, allows to copy of examples either modifying before execution or - like me - paste them in a "real" OCAML REPL I have on my desktop.

don't get me wrong, the site and idea is nice, those things just irritate me,
almost irrationally, from an UX POV.

------
w1nt3rmu4e
I know cryptocurrency is contentious in this community so apologies for
injecting it here:

OCamlPro is heavily involved in the development of Tezos and a big part of the
reason I invested in it. One of the main selling points of Tezos is formal
verification, which OCaml (being a pure-ish functional language) was
instrumental for.

Regardless of the future of crypto (fad or world changing) if it's handling
money or other assets it should be done safely. This is step in that
direction.

OCaml is also used at Bloomberg and Jane Street.

~~~
sshine
That's also why I bought some tezzies, or what they're called.

It's a pity that functional programming and formal verification aren't enough
to overcome selfish and destructive founder behavior.

~~~
dbrgn
It's complicated. Here is a huge Wire story about Tezos:
[https://www.wired.com/story/tezos-blockchain-love-story-
horr...](https://www.wired.com/story/tezos-blockchain-love-story-horror-
story/)

------
garkin
I tried ReasonML an year ago.

It was __very__ amusing to play with Variants, Pattern Matching and Units. If
programm compiles - it almost always just works. It's an indispensable tool to
play around and get more ideas how to write a better programs.

And it was disastrous in __everything__ else. Installation and compiler bugs.
Terrible tooling. Terrible code packaging. Terrible Javascript interop.
Painfully archaic syntax. Sometimes extremely esoteric compiler errors.

After a week i thrown out all the code and rewritten it using Typescript.
Won't ever use new languages on projects with deadlines, no matter how sweet
evangilists talks are.

~~~
chrisseaton
> If programm compiles - it almost always just works.

I can never understand this claim when people make it about languages like
Haskell and ReasonML.

How is the compiler catching your logic bugs? If you write 'a + b' and you
should have written 'a - b' the compiler isn't going to catch that in either
of those languages. It'll compile but it won't work. Do you never make these
kind of logic bugs?

~~~
dmitriid
> How is the compiler catching your logic bugs?

It doesn't, and I agree with your sentiment. IIRC, type-related errors account
for ~10% of bugs.

If (and only if) types are tied into your tooling ecosystem (for example, an
IDEs that uses that info to full extent to aid in code completion,
refactoring, code analysis etc.), they are very useful.

~~~
neillyons
> It doesn't, and I agree with your sentiment. IIRC, type-related errors
> account for ~10% of bugs.

I never thought of that, but that is a really valid point. I guess that is why
Ruby/Python are so popular as most of the problems programmers run into in
production aren't type problems.

~~~
jasone
Type correctness is pure power, or a waste of time, depending on...
perspective! I can't help thinking back to the highly illustrative example of
my first enhancement to Facebook's production website as a "bootcamper" in
2009.

I was tasked with adding proper honorifics for Japanese speakers (it's
complicated in the general case, but I was just getting as far as "San"). I
wrote some straightforward PHP code to implement this feature, but of course
it broke in production for some nontrivial percentage of requests. Why?
Because the string I was adding the honorific to wasn't always a string. WTF?
What is the proper course of action when strings aren't strings? Well, in this
case the answer was a run-time type-check guard on the code I had added.

Keith Adams, my esteemed colleague, likened this to "dogs and cats living
together", perhaps revealing a fondness for simpler days when Ghostbusters
trod the streets. Keith may not have gone as far as lauding OCaml's type
system in those dark early days, but I will do so now (and perhaps he would
too).

------
G4BB3R
Haskell and OCaml try their best to not be popular. Elm is very beginner
friendly, docs, installation, great libs for each purpose and is like 5 years
old. OCaml has more than 20 years old and for a beginner to install everything
and make a REST API is a pain. Why that happens?

~~~
ernst_klim
>OCaml has more than 20 years old and for a beginner to install everything and
make a REST API is a pain. Why that happens?

Nowadays things are quite neat with opam/dune/odig stuff. You can install
packages, generate readable docs for them, just like in rust. For the rest api
you could just take any existing framework, I think, e.g. [1] [2].

You should also consider that OCaml is a language, which for a long time was
intended for a different kind of projects (yeah, webdev is not the only
programming domain, shocking), so the direction was dictated by Coq and
similar project devs rather then webdevs. Now facebook and other companies
change the state of affairs.

[1]
[http://opam.ocaml.org/packages/eliom/](http://opam.ocaml.org/packages/eliom/)

[2]
[http://opam.ocaml.org/packages/webmachine/](http://opam.ocaml.org/packages/webmachine/)

------
jimmy1
I am usually not one for dismissing a language for syntax alone, but, the
syntax for arrays versus lists feels very cumbersome. Can an experienced OCaml
developer tell me how common it is to use lists versus arrays?

I can only imagine how many bugs I would type at this stage of my career after
being used to [] for arrays but forgetting the pipe, and getting a list
instead. It's also very difficult to type.

~~~
jallmann
> I can only imagine how many bugs I would type at this stage of my career
> after being used to [] for arrays but forgetting the pipe, and getting a
> list instead.

Luckily, the compiler would catch this anywhere you tried to use a list where
an array was expected.

> how common it is to use lists versus arrays?

Lists are far more common in day-to-day usage. The language even has native
syntax for list consing and destructuring, which is useful for pattern
matching.

OCaml arrays do have their place though, if you have a fixed number of items
and need random access. Float arrays are also specialized, their elements are
unboxed and contiguous which helps with performance for certain types of
number-crunching applications.

~~~
jimmy1
> need random access.

I was thinking quite the opposite, I admit I don't know much about OCaml yet
but I was very interested in trying ReasonML. Anyways, I would think you would
use an array when you need sequential access and potentially help locality of
reference when doing some number crunching? OCaml arrays are random access?

~~~
xfer
By random-access he means O(1) indexing, unlike lists. Yes, arrays works the
same(but there is bounds-checking).

------
seanhunter
I would highly recommend Jon Harrop's "OCaml for Scientists" if you're
interested in learning OCaml. It's a really awesome book.
[http://www.ffconsultancy.com/products/ocaml_for_scientists/](http://www.ffconsultancy.com/products/ocaml_for_scientists/)

When I was learning OCAML and bought the book, Jon actually found some code I
had posted on my website and sent me some advice about how to make it more
idiomatic. He even rewrote the first one of my functions to show me how.

~~~
3rdAccount
That book is ancient, but probably still pretty relevant. John Harrop himself
posted on reddit awhile back that he hadn't personally used OCaml in a long
time when someone asked about the book on the OCaml sub reddit. His username
starts with jdh I think. Honestly though, scientific computing seems to be
going Julia. Really good numeric, optimization, charting, linear algebra,
parallel & distributed computing...etc. It's all free and open source. Julia
Computing was founded to provide enterprise support and services including
auditing and affordable cloud computing. This is the direction I'm moving
towards. You should check out the case studies on Julia Computing.

~~~
kxyvr
I work professionally as an applied mathematician and I've struggled to
understand where Julia fits into the tools already available.

In terms of prototyping algorithms, MATLAB/Octave still seems to be the best
choice. We have access to an enormous number of builtin routines that help
diagnose what's going on when an algorithm breaks. That's not to say other
language don't, but the ability to set a single dbstop command and then run
some kind of diagnostic like plotting the distribution of eigenvalues with
d=eig(A); plot(real(d),imag(d),'x') is amazing and saves time. There's also a
very straightforward workflow to run the debugger and then drop into gdb in
case the case we need to interact with external libraries.

Now, certainly, MATLAB/Octave is weak, in my opinion, for generating larger
software projects that need to interact with the rest of the world. This
includes things like network connections, GUIs, database access, etc.
Alternatively, sometimes a new low level driver needs to be written, which
needs to be very fast. All that same, that ecosystem seems to be much better
in languages like C++ and Python. Though, I've been experimenting with Rust as
an alternative to C++ for this use case. At this point, if I have trouble with
the algorithms, I can run it in parallel with the MATLAB/Octave to diagnose
how things differ.

Coming back to Julia, where is it supposed to fit in? To me, there's a better
prototyping language, production language, and bare metal fast language.

I will make one last quip and that's the licensing. Frankly, the big advantage
of MATLAB is that it provides license cover. Mathworks has obtained the
appropriate licenses for your expensive factorizations and sparse matrix
methodology. Julia has not and they remain largely under GPL:

[https://github.com/JuliaLang/julia/blob/master/LICENSE.md](https://github.com/JuliaLang/julia/blob/master/LICENSE.md)

Look at things like SUITESPARSE. Practically, what that means is that I can
deliver MATLAB code to my clients and I don't have to disclose the source
externally due to GPL requirements. Now, maybe they choose to run Octave.
That's fine and then they can assume the responsibility for GPL code. However,
for me, I maintain a MATLAB license and that gives me coverage for a whole
host of other licenses in the context of MATLAB code and that makes my life
vastly easier than if I were to develop and deliver code in another language.

~~~
ChrisRackauckas
MATLAB, Python, and R don't have the metaprogramming tools for code
generation. Tools like FFTW relied heavily on code generation, and people who
wrote those kinds of tools are now using Julia for generic programming.
Generic programming is difficult to handle with any AOT compilation system
since you get a combinatoric explosion of possibilities leading to large
compile times. Generic programming works great in Julia so there's a lot of
examples of utilizing types for "free features" that would be difficult to do
(interactively) in any other language.

Of course, most programmers don't know what generic programming even is.
However, a lot of libraries these days utilize it in order to get different
precision and all of that, which is why I think Julia will at least become a
language of libraries since not too many people can invest so much time in
C++.

~~~
setr
>Generic programming is difficult to handle with any AOT compilation system
since you get a combinatoric explosion of possibilities leading to large
compile times.

I thought it was either solved by adding function signatures based on actual
usage, or “boxing” the argument (which I guess is just dynamic at that point)

Why would you ever see the combinatoric explosion in an AOT implementation?

~~~
ChrisRackauckas
If you want to make it as a standard library so it can compile once and others
link to it, then you have this issue. You need to compile on use in order to
only add the function signatures based on use, so if you're doing this from
types the user is giving you (say, a generic differential equation solver
where the state can be any type with the right overloads) then you're out of
luck. If you know of a big set of types the user might want to give you, then
you can compile those ahead of time, but for the diffeq example you can have
different types for the dependent and independent variable, so you'd want each
combination. The solution here of course is just to make people statically
compile against it if you want to use all of these features, but you need to
compile as a shared library if you want to build an easy interface to a high
level scripting language (Julia, Python, R, MATLAB, etc.). So what tends to
happen is that libraries which do make some extra features possible are
constrained when used from a scripting language and they compile a bunch of
choices to mitigate that a bit (see SUNDIALS and its built-in NVector
compilations). The true solution here of course is to compile on demand based
on the new types you see from the user codes, and this is what Julia does
automatically.

As for boxing, boxing works but it's slow. The developer of LightGraphs.jl
tried using Swift for awhile but went back to Julia when he realized that
actually using generics in Swift is really really slow because they do this
boxing (your code is generic! But...). To finish the story, he tried Go a bit
but generics in Go... he went to C++ but templates but they were difficult to
use and the compile times were too long to be anything close to interactive,
and has done extremely well over the last few years in Julia (though it is
admittedly missing some tools for (partial) AOT compilation and building
binaries, but these tools are in development).

~~~
celrod
If you want another example, I saw this a couple days ago:

"Also exciting - we only have 27k signatures right now, and removing all the
ones taking row vectors reduces that substantially to under 10k. That seems
doable pretty easily, and we can convert without performance penalty between
row and column vector seamlessly (I believe)."

[https://discourse.mc-stan.org/t/compiling-the-math-
library-i...](https://discourse.mc-stan.org/t/compiling-the-math-library-into-
a-shared-library-or-object-files/5461/4)

Those sound like big numbers to me! That's a real problem that DynamicHMC.jl
doesn't have to worry about, for example.

I think Stan's autodiff is faster than ForwardDiff.jl/ReverseDiff.jl (other
than Stan models regularly taking several minutes to compile), but I'm betting
on Cassette-powered Capstan/Zygote getting there in the next few years.

------
amelius
Nice. But it should explain float arithmetic, i.e., why can I do 1+1 but not
1.0+1.0.

~~~
djtango
It was a surprising language decision to find out that OCaml didn't do
implement polymorphic behaviour for common operations and opted to stress
static types for things like print_int or 1.0 +. 1.0...

~~~
rwmj
One reason is that promotion from int to float is not free! Therefore maybe it
should be explicit that your code is doing that especially in a language like
OCaml that cares a lot about performance and is used in a few performance-
sensitive areas (notably HFT).

~~~
wyoung2
> promotion from int to float is not free!

Nor is it safe to allow implicit conversion in general, but F# shows that you
don’t need separate operators for floating point. You just need a compiler
that refuses to implicitly convert data types, as F# does, so you must use
explicit conversions and type suffixes if you want to mix data types. If you
manually convert, then on your head be the consequences.

This is not legal F#:

    
    
        let x = 1.0 + 1
    

But both of these are legal:

    
    
        let x = 1.0 + 1.0
        let y = 1.0 + float 1
    

F# doesn’t even let you mix single- and double-precision FP:

    
    
        let x = 1.0f + 1.0         // ILLEGAL
        let x = 1.0f + float32 1   // legal

~~~
ernst_klim
And both F# and sml have a problem with that. What type should this function
have:

    
    
        let add x y = x + y
    

The proper solution for ad-hoc polymorphism is either dynamic dispatching (aka
oop solution) or type-classes or OCaml's modular implicits, not ad-hoc monkey
patches like that. And I find (+.) fine since float addition is not an
arithmetic addition.

~~~
wyoung2
> What type should this function have:

If you don't call it, F# simply guesses "int -> int -> int". If you pass a
float, you get back a curried function taking float and returning float. Now
that the "add" function's type is known, you now can't pass an int: that's now
known to be an error.

Seems sensible to me. No problem.

------
galfarragem
What is the probability of Ocaml/Reason becoming mainstream?

~~~
rezeroed
I don't see why these two are being lumped together. I see ReasonML needs
OCaml, but not that OCaml needs ReasonML. OCaml I expect will become
increasingly mainstream - I've started using it instead of rust on personal
projects. ReasonML would increase exposure to OCaml, but OCaml in no way needs
it to succeed.

~~~
hajile
ReasonML was written in SML then they switched to Ocaml because everyone at
Facebook already knew it and caml4p is a thing.

Because it is "just Ocaml", all the weird parts of Ocaml bleed through the
reason language design. No operator overloading, nominal record typing, 3
competing standard libraries (plus the all-too-small actual standard library).
The list of oddities is rather long.

SML was and is a better choice. SML has structurally typed objects and first-
class constructors. No named arguments, but structurally typed objects do a
better job at this (like JS destructuring, but more efficient). Anonymous
records are possible. A ref type rather than mutable record fields. Only one
`let`. PolyML has shipped a multi-process implementation for years while
Ocaml's is still in an unending beta. SuccessorML (SML 2.0) is adding some
syntactic niceties along with things like module typeclasses (modules should
prevent the typeclass hell of Haskell). Most importantly, SML is a standard
with multiple implementations and isn't completely tied to the success of Jane
Street.

~~~
pjmlp
OCaml has an big presence in European universities, specially in France thanks
to INRIA.

Our university was big in Prolog (SWI) and Caml Light back in the day, and
they still are, just with Caml Light having been replaced by OCaml.

The only reason I known a bit about SML is because I am a language geek, it is
hardly known in this side of the pound.

------
karmakaze
What's the current state of F# on non-MS platforms? How does it compare to
OCaml or F# on Windows? I've always wanted to get into it but for some reason
(jvm ecosystem?) thought a cross-platform, multilang env would have
advantages.

~~~
sergimansilla
It's very good right now, especially with .NET core the new dotnet command,
and VSCode's great support it's easier than ever to develop in F# on any
platform.

~~~
hajile
When is F# getting native compilation? MS has been promising it for years now.
Last I heard, they still had _zero_ progress toward handling tail calls.

~~~
phillipcarter
Note: there's a very big difference between "native compilation" and the
product known as ".NET Native".

.NET Native is a proprietary, Windows-only backend compiler toolchain for
statically linking and tree-shaking compiled IL, used only for UWP apps on
Windows 10 devices. It is this toolchain that does not support F#.

Beyond that, there are no toolchains for compiling to a single, native binary
that are a shipping part of the .NET product.

We are not prioritizing .NET Native for F# at this time (from the F# team
perspective), as we feel that .NET Core gives us more reach for F#.

~~~
atombender
As someone who's interested in F#, but has zero interest in ".NET", I hope for
F# to someday become available as an independent language with native
compilation and minimal runtime -- no Mono, no CLR, native platform support on
Linux and Mac, and so on. But it sounds like that's not the direction things
are going in?

~~~
wtetzner
If you're not interested in .NET or the CLR, what is it about F# that
interests you over OCaml?

~~~
wyoung2
For me, the attractions of F# over OCaml are:

1\. Cleaner syntax. F# shows that we can do away with a lot of the visual
noise in OCaml. I’m no particular fan of white space scoping, but I also don’t
mind it.

2\. Much better thought out standard library. The OCaml standard library was
clearly accreted over long periods, with no strong designer making hard
choices about naming and such. The example that keeps coming back to me is
“big_int” vs all the other integer data types.

I believe #2 is what the OP meant by “minimal runtime.” A minimal F# will
still need a good set of data types, a string library, etc.

------
parabx
Hi, lifelong python developer here. Is OCaml a good fit to do REST application
servers? I've took a look a year ago but couldn't find well maintained
libraries and it seems that the community is not so focused in general
development. Am I wrong? OCaml seems really nice, I've been dabbling with rust
for a while, and it feels great working with it but I'd like to try some purer
functional languages too. My needs are basically a web container, some way to
interface with SQL (ORM or a query builder, with support to PostGIS), some
redis, some elasticsearch, nothing too fancy.

~~~
specializeded
Not particularly imo, no.

A great (albeit maybe not _as_ great as OCaml ;) alternative for web usage
would be F# with .NET Core, which has become a joy to work with over the past
year or so on macos.

------
joelthelion
If you already know Haskell, how useful is it to look at OCaml?

~~~
snaky
It might be quite useful to look at BER MetaOCaml[1] at least. And maybe at
some other ways to deal with some problems - like OCaml DSL instead of Haskell
monad[2].

[1]
[http://okmij.org/ftp/ML/MetaOCaml.html](http://okmij.org/ftp/ML/MetaOCaml.html)

[2] [http://okmij.org/ftp/tagless-final/nondet-
effect.html](http://okmij.org/ftp/tagless-final/nondet-effect.html)

~~~
edwintorok
A nice MetaOCaml example:
[https://strymonas.github.io/](https://strymonas.github.io/)

------
sandGorgon
Could someone from the ocaml world comment on Typescript vs Ocaml ?

Is Typescript as close you get to Ocaml world... without writing a "ml" ?

~~~
k__
Does TS has pattern matching?

~~~
aikah
The goal of typescript is to provide static type analysis at compile time and
mimic Ecmascript spec features. If Typescript starts bundling a runtime with
it to do things completely unrelated to Javascript, then it's not just
javascript with types anymore, it becomes its own language which defeats the
entire purpose of Typescript.

This trade off is good because there is no runtime overhead, only desugaring.
Typescript should never become ML or anything else that Javascript is not. If
you want pattern matching in Typescript you need to convince the Ecma
committee to put pattern matching into Javascript first.

~~~
gmfawcett
Your comment seems like a non-sequitur. What does pattern matching have to do
with runtimes?

~~~
k__
Isn't one part of pattern matching to ask for a type and the other to ask
which values the (instance?) of that type holds?

~~~
gmfawcett
When a language has algebraic data types -- i.e., data types that have
multiple, disjoint constructors -- pattern matching generally means
determining which constructor was used to create the value being matched, and
branching on that. I'm guessing this is the kind of pattern-match that
TypeScript users would be eager to have.

What I don't see is how this requires the addition of a "runtime" on top of
the JS model to make it work. I don't use TypeScript, and don't know how it
implements its data types, so there may be something obvious here that I'm
missing.

------
sshine
Exercism.io has an Ocaml track with mentor feedback!

------
Drup
I'm not sure why this is linked. This online toplevel is very old. People who
want a more modern version, with more exercises should follow the online MOOC
[1] or use this website [2]. People who just want an online OCaml/Reason
interpreter to play with should use
[https://sketch.sh/ml](https://sketch.sh/ml)

1: [https://www.fun-
mooc.fr/courses/course-v1:parisdiderot+56002...](https://www.fun-
mooc.fr/courses/course-v1:parisdiderot+56002+session03/about)

2: [https://try.ocamlpro.com/learn-ocaml-
demo/](https://try.ocamlpro.com/learn-ocaml-demo/)

~~~
rezeroed
There's also an ocaml toplevel for android, not the easiest to use, I keep an
eye out for it arriving on termux.

~~~
shikoba
You can compile OCaml in termux if you want. [https://ygrek.org.ua/p/ocaml-
termux.html](https://ygrek.org.ua/p/ocaml-termux.html)

------
jklein11
Other than satisfying curiosity, why should I learn OCaml?

~~~
fsloth
Programs written in ML dialects tend to have the astounding property that once
they compile, they are correct. And this is only a slight exaggeration.

This property alone is worthwhile to learn one, if for nothing else then to be
able to apply the same succesfull patterns in other languages.

I didn't know how to write proper strongly typed code until I learnt Ocaml - I
_had_ several years of experience in C++ and knew Java, but, they really don't
go out of their way to expose the patterns that allow write the best code
possible. With the lens of Ocaml under my belt I could better discern the
shiny patterns that were buried all that ugly dirt of multiple inheritance and
such bollocks.

Which ML language should you learn? Any of them is good as the next if it's
for education - a modern tooling, support and community is a nice bonus.

ML languages in production nowadays include Ocaml, F# and, to some extent
given it has so much isomorphism with its kin, Scala. Scala can be considered
an ML dialect, although with the weirdest syntax of them all.

Unless you are quite certain Ocaml is the exact language you want to learn, F#
is a good alternative.

~~~
owl57
I'd say Elm is a plausible alternative, though maybe not right now: there are
a lot of small rough edges in the ecosystem after 0.19 release. On the other
hand, a lot of the 0.x breakage comes from the very high priority of the
unusual long-term plan, which I'd formulate as something like following:
distill that essential property of ML while shaving all the bells and whistles
that just happen to be in other dialects.

~~~
fsloth
Are there any plans to bring Elm to any non-javascript runtime?

~~~
owl57
Long term: yes, the controversial banning of "native" code [1] is in part
motivated by the idea that JS should be an interchangeable implementation
detail.

Short term, officially: hell no, Evan declares a sharp focus on one use-case
and discourages experiments with other platforms, even server-side node.js
[2].

Short term, unofficially: I heard of a compiler to Elixir [3]. Elm's stance on
"native code" (see above) seems to make such projects feasible.

[1] [https://discourse.elm-lang.org/t/native-code-
in-0-19/826](https://discourse.elm-lang.org/t/native-code-in-0-19/826)

[2]
[https://github.com/elm/projects/blob/master/roadmap.md#can-i...](https://github.com/elm/projects/blob/master/roadmap.md#can-
i-use-elm-on-servers)

[3] [https://github.com/wende/elchemy](https://github.com/wende/elchemy)

------
village-idiot
No thanks. I’m tired of trying to get shit done in MLs and then giving up and
working in react or rails.

------
7474747
shouldnt ["[test]"] work?

~~~
seanhunter
It should and it does for me (ie it defines a one item string list, containing
"[test]"). What were you expecting it to do?

------
coderchimp
damn, semicolons

damn semicolons

------
zeroname
Walked into OCaml back in the day. Saw floating point operators. Slowly backed
out of the room, never to return.

~~~
dean177
Why was that a dealbreaker for you?

~~~
zeroname
It looks horrible to me. I use a lot of FP math, and I'm not going to pick up
the habit of sprinkling these dots everywhere. The fact that the language
designers would even seriously consider this solution tells me it's not for
me.

YMMV, of course.

~~~
laylomo2
If you use Core, you can use the Float module together with a local open to
get nice operators.

    
    
        open Core
    
        let () =
          let n = Float.(2.0 + 3.0) in
          printf "%f" n

------
mrloop68
I like OCaml, but sorry, I can't take it seriously until it gets proper
support for Unicode.

~~~
laylomo2
Can you provide an example of something you would want to be able to do with
proper unicode support that is not currently possible?

This is an honest question, not trying to troll you.

