Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: David Brown <davidb@davidb.org>
To: Yawar Amin <yawar.amin@gmail.com>
Cc: Sven SAULEAU <sven.sauleau@xtuc.fr>, caml-list@inria.fr
Subject: Re: [Caml-list] ReasonML concrete syntax
Date: Mon, 11 Dec 2017 10:11:18 -0700	[thread overview]
Message-ID: <20171211171118.GA24847@davidb.org> (raw)
In-Reply-To: <CAJbYVJKC18D-LBS1CU+H6OS0JnMLG_e5vN0dyN+ZwH87o+wqSw@mail.gmail.com>

On Mon, Dec 11, 2017 at 10:51:57AM -0500, Yawar Amin wrote:

>By the way, to the people calling the syntax ugly and its users idiots, please
>tone yourselves down and think about why OCaml has been around in a niche for
>20 years but Rust took off in less than five.

I think this is deeper than just syntax.  Rust has had the advantage
of being able to learn from everything that happened with languages in
the interim (both good and bad).

Although, I do think I'm a lot less bothered by syntax differences
than many other programmers are, I do remember a distinct learning
period with Ocaml that was essentially how to write various constructs
in its syntax.  I know of several other developers that came away from
an Ocaml experience with a bad taste, just because of the syntax.

But, I do think there are a few things Rust has gotten right that have
contributed to its taking off:

  - The cargo "culture".  Somehow, they managed to get the development
    of properly-versioned, well-encapsulated packages (crates) to be
    part of the culture of the language.  Starting with the "cargo"
    tool really helped this a lot.

  - Tied to this, management of the namespace of packages.  Every
    crate lives in its own namespace, and the imports between the
    crates are explicit (and don't have to be the same for a given
    dependency).  This allows conflicting dependencies to be resolved
    by just bringing in both versions.  (The language's strong
    distaste of global mutables helps this as well).

The first is kind of a hard thing to bring to an existing language
culture, although I think Ocaml is doing a pretty good job with this.
The second is a problem I've run into with Ocaml.  The ML basis system
handles this quite well, so this is clearly something that can easily
be handled in a language like Ocaml, but it would be challenging to
change the way modules and namespaces work without significantly
breaking existing code.

Personally, I've been doing a lot of Rust programming recently,
because it is a reasonable language, and there are likely crates.  I
do wish I had something, though, with garbage collection, and a strong
type system, and would really love to see Ocaml (or something derived
from it) fit this.  A vast majority of the code I write does not need
the complexity of the memory management and borrow checker from Rust,
but I want the rest of the infrastructure around the language.

David

  parent reply	other threads:[~2017-12-11 17:11 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-10 18:12 Robert Muller
2017-12-11  0:09 ` Yawar Amin
2017-12-11  5:50   ` Viet Le
2017-12-11  6:45     ` Ian Zimmerman
2017-12-11  6:53       ` Sven SAULEAU
2017-12-11  6:50     ` Sven SAULEAU
2017-12-11  6:54       ` Evgeny Khramtsov
2017-12-11  7:22         ` =?gb18030?B?Qm9i?=
2017-12-11  7:16           ` Evgeny Khramtsov
2017-12-17 15:02         ` Paolo Donadeo
2017-12-17 16:01           ` Guillaume Huysmans
2017-12-17 16:55             ` Paolo Donadeo
2017-12-17 20:13               ` Ian Zimmerman
2017-12-17 20:49                 ` Robert Muller
2017-12-18  1:34                   ` Yawar Amin
2017-12-18 16:36                     ` Evgeny Khramtsov
2017-12-18 17:00                       ` Jesper Louis Andersen
2017-12-18 17:27                         ` Gary Trakhman
2017-12-18 17:53                         ` Evgeny Khramtsov
2017-12-18  2:14                   ` Yawar Amin
2017-12-11 15:51       ` Yawar Amin
2017-12-11 16:07         ` Sven SAULEAU
2017-12-11 17:11         ` David Brown [this message]
2017-12-12  3:49         ` Louis Roché
2017-12-12  4:18           ` Yawar Amin
2017-12-12  5:52           ` Oliver Bandel
2017-12-11 14:40 ` Gerd Stolpmann
2017-12-11 16:10   ` Ian Zimmerman
2017-12-11 16:47     ` Viet Le
2017-12-11 17:10       ` Yotam Barnoy
2017-12-11 18:56         ` Robert Muller
2017-12-11 19:23           ` Yawar Amin
2017-12-11 21:10         ` Marshall
2017-12-11 17:29       ` Yawar Amin
2017-12-11 17:59       ` Ian Zimmerman
2017-12-11 18:30     ` Gerd Stolpmann
2017-12-13  8:22       ` Sebastien Ferre
2017-12-13  9:26         ` Evgeny Khramtsov
2017-12-13 10:37           ` David Allsopp
2017-12-13 16:38             ` Marshall
2017-12-13 16:44               ` Yawar Amin
2017-12-13 17:20                 ` David Allsopp
2017-12-13 17:51                   ` Yawar Amin
2017-12-13 17:39         ` Hendrik Boom
2017-12-13 17:55           ` Robert Muller
2017-12-13 18:19             ` Viet Le
2017-12-13 19:29             ` Yawar Amin
2017-12-13  8:55 ` Nicolas Boulay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171211171118.GA24847@davidb.org \
    --to=davidb@davidb.org \
    --cc=caml-list@inria.fr \
    --cc=sven.sauleau@xtuc.fr \
    --cc=yawar.amin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox