
New implementation of Git in OCaml - tosh
https://github.com/mirage/ocaml-git/pull/227
======
yen223
I've been using OCaml for a couple of side projects, and I have been
absolutely blown away by the amount of power this language provides. It
strikes a nice balance between high-level expressiveness, while not
sacrificing on performance.

I feel like OCaml is one of the programming world's best kept secret - if it
had better tooling and better marketing, it could have taken over the world.
I'm cautiously optimistic about ReasonML for this reason.

~~~
thesmallestcat
Version incompatibility is a big problem for OCaml. Every time I try to use it
seriously, the recommended tools never seem to work together on anything but
the latest version. It's like Rust, but without the "young language" excuse.
My impression is that INRIA is too eager to add features and tweak the
language.

Next, everything builds so slowly, and just trying to set up Core, utop, and
ocp_indent is a trial in patience, watching the same dep build again and
again, confusion about OPAM switches.... nope nope. OCaml/OPAMs's got a
distribution problem. They've pushed the complexity off to the end user and
the experience is terrible. Jane Street planting their flag on the language
and encouraging massive dependencies like Core, or shit like "corebuild" is
even worse. I would never depend on anything OCaml-based on it unless it could
be installed by my OS' package manager (Arch/AUR doesn't count, because it
builds). That rules out most popular OCaml tooling, and ruins the development
experience.

I'd prefer OCaml to Haskell, I find it more practical, but I feel much better
depending on Haskell-based software, which generally "just works." As much as
they're a wart, Haskell syntax extensions are a real benefit. You can build
new fancy Haskell software with older GHC versions.

~~~
talex5
> the recommended tools never seem to work together on anything but the latest
> version

Whenever a package is added to the repository, the CI tests (the latest
compatible version of) every package that depends on it to check everything
still works. However, non-current packages may break if they're missing upper
bounds (it doesn't check all previous releases).

However, since opam-repository is just a Git repo, you can clone a known
snapshot of it at some point in time and keep using that. That allows you to
continue using old versions of packages without the risk of new software
causing unwanted upgrades.

> My impression is that INRIA is too eager to add features and tweak the
> language.

That's strange. I've always had the opposite impression - that they maintain
compatibility at all costs, including leaving sub-optimal APIs in the standard
library.

> Next, everything builds so slowly, and just trying to set up Core, utop, and
> ocp_indent is a trial in patience, watching the same dep build again and
> again

The Core alternative standard library is pretty huge, indeed (I don't use it).
I just tried installing all the tools you mention in a fresh container:

$ time docker run ocaml/opam:debian-9_ocaml-4.05.0 opam install core utop ocp-
indent

6:03.75elapsed

So, 6 min to set up a dev environment with those tools. That installed 67
packages, so compilation took about 5 seconds/package on average. I'm not sure
why it would build the same dep twice - I haven't seen it do that.

~~~
mcguire
" _> My impression is that INRIA is too eager to add features and tweak the
language._

" _That 's strange. I've always had the opposite impression - that they
maintain compatibility at all costs, including leaving sub-optimal APIs in the
standard library._"

When I started using OCaml, many standard library functions weren't tail
recursive---you couldn't get the length of a list with more than ~10,000
elements, for example. The library definitely seems like an afterthought
compared with the language. (And that would be why there are so many of them.)

~~~
zoren
Why would you hold 10,000 elements in a linked list?

~~~
fsloth
That's just - for example - every point in 100×100 R^2 cartesian grid. 10k
elements is not by any measure a 'large number of elements'.

Just pick your algorithmic use case for a good excuse to use list and not an
array from here:

[http://bigocheatsheet.com](http://bigocheatsheet.com)

------
avar
This implementation is freely licenced enough that the BSDs and others that
don't use Git for license reasons could use it.

It would be interesting to see an alternative implementation like this get
enough feature parity that projects like the BSDs could migrate and still be
protocol and worktree compatible so most users could continue using the GPL2
implementation.

Edit: Seems people here are unaware that the BSDs treat GPL software like
cooties, see e.g. [1]. They wouldn't start using source control that gave them
less freedom than SVN, an with CVS there's the expectation that OpenCVS might
get finished.

1\. [https://wiki.freebsd.org/GPLinBase](https://wiki.freebsd.org/GPLinBase)

~~~
k__
What's the problem with using GPL software if you don't want to change it?

~~~
yorwba
AFAIK, software for the BSDs is usually maintained in-tree, and patched to
integrate with the rest of the distribution. I don't think including GPL-
licensed software would be compatible with the BSD license of the overall
project. That doesn't mean you can't use anything GPL, just that it can't
become part of the system.

~~~
_delirium
All the BSDs have traditionally included GPL'd software in the base system, so
I don't think many people share this view (it's a possible interpretation of
the GPL, but not a common one). As one major example: every BSD until recently
included gcc in-tree, and OpenBSD and NetBSD still do.

~~~
loeg
FreeBSD sees this as a necessary evil and aims to move to zero GPL code in
base, eventually (when ports GCC works well enough for 2nd tier architectures
and Clang/ias / elftoolchain works well enough for 1st tier architectures).

~~~
int_19h
Doesn't FreeBSD use Clang exclusively in the base system these days, and gcc
from ports?

~~~
loeg
On x86 and arm64, yeah. MIPS and Sparc still build with base GCC (4.2, last
GPL2 version). I'm not sure what arm32 or ppc uses by default these days.

------
joshmarlow
If OP interests you, then this may too:
[https://pijul.org/](https://pijul.org/)

IIRC, when I last looked at this, they were doing dual implementations in
OCaml and Scala, but now it looks like it's being done in Rust.

~~~
gragas
I'm unconvinced.

>Means no more downtime, no possibilities of censorship, be it from states or
from companies.

Wrong.

>historically, patch-based systems have been very simple to learn and use, but
slow, whereas snapshot-based systems can be extremely fast, but are usually
hard to use for more than simple operations. As an example, cherry-picking is
not intuitive in git/mercurial

How is cherry-picking not intuitive?

>Category theory has certainly been an inspiration for Pijul, but categories
are neither algorithms nor data structures in themselves. In order to get the
semantics we wanted, especially the handling of multiple files, rollbacks and
unrecords, designing and implementing new algorithms and data structures was
at least as useful as learning theoretical stuff.

Yet another thing with relatively little practically use, but hey, it uses
_category theory_! It must be good! Oh look, it's also _functional_!

All of that said, props to Pierre-Étienne for putting in the time and effort
to make this. He probably learned a lot.

------
altotrees
This is fantastic. I have played around with Clojure and Haskell a bit, but
really want to get into functional programming more. Not to hijack the thread,
but I guess I am having trouble getting started. Any good resources for
novices out there?

Edit: for the record I have Googled the topic and am overwhelmed by how much
is out there. Looking for personal recommendations.

~~~
gilmi
If you want to learn Haskell the most recommended book nowdays is Haskell
Programming From First Principles[0].

[0]: [http://haskellbook.com](http://haskellbook.com)

~~~
eru
The consensus on the Haskell subreddit was that the Haskell Wikibook
([https://en.wikibooks.org/wiki/Haskell](https://en.wikibooks.org/wiki/Haskell))
has gotten even better than "Haskell Programming From First Principles".

In any case, that book ain't bad either. It's better than Learn You A Haskell.

I also like "Discrete Mathematics Using a Computer"
([https://github.com/ryukinix/discrete-
mathematics/blob/master...](https://github.com/ryukinix/discrete-
mathematics/blob/master/ebooks/discrete-mathematics-using-computer.pdf)). It
focuses on teaching discrete mathematics and introduces some Haskell as
executable mathematical notation on the side.

~~~
djur
The wikibook has gotten really good, and it's the reference I've started going
to when I need a refresher on a concept, but HPfFP was the book that helped me
actually "get" Haskell -- and I'd read pretty much every other beginner-to-
intermediate resource by that point.

My experience has been that, generally speaking, programmers of language [X]
don't have a particularly good grasp of what makes a good introduction to
language [X], and I think that effect is even stronger with a difficult
language like Haskell.

That said, I was about to read some of the new material in HPfFP, and I should
also read the analogous wikibook content as an experiment. Thanks for linking
it.

~~~
eru
I do agree with your observation:

I remember a particularly vivid example of some of my coworkers at Google
suggesting the Go tutorial, starting at
[https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1), to
someone completely new to programming. They couldn't even understand how it's
not perfectly clear and simple.

That being said the book that I've seen most success with getting someone from
absolutely zero to "can start making progress on their own" is "How to Design
Programs"
([http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html](http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html)).
It helps that the authors regularly teach absolute beginners.

------
sandGorgon
I was in two minds about attending FunctionalConf in Bangalore, India ... but
after seeing this PR, I'm there.

[https://confengine.com/functional-
conf-2017/proposal/4052/gi...](https://confengine.com/functional-
conf-2017/proposal/4052/git-under-the-hood-with-ocaml)

------
sddfd
What is the benefit of having an OCaml implementation of git, besides that
it's written in OCaml?

Edit: I get it now: it's an OCaml library that allows you to interact with git
repositories and provides many (most?) operations.

------
logingone
I thought there might be some comments on darcs in here. I've only just
started learning OCaml so haven't yet used darcs, but am looking forward to
trying it out.

~~~
marmaduke
Darcs is interesting but not same system as Git.

~~~
logingone
Yes, the first two lines of the front page: "Darcs is a free and open source,
cross-platform version control system, like git, mercurial or svn but with a
very different approach"

------
gragas
This is a +19k -8k line pull request. That is dumbest thing I have ever seen.
For having written something that interfaces with git, this person obviously
doesn't know how to use it effectively.

~~~
dr_win
The pull request currently contains 81 commits. It is NOT a single monolithic
commit.

~~~
gragas
I'm probably too harsh, but I can't think of a single developer who would
welcome such a large PR with open arms.

