Plans for OCaml 4.08
blog.janestreet.com
blog.janestreet.com
Though the core language is the same, some of the language metaprogramming features have been totally switched out for other (better) ones. And it uses the modern versions of the Core (note, that is NOT the standard library) library.
OCaml is pretty old (introduced a year after Java IIUC), and it contains quite a few crusty libraries and programming patterns that come from age. Stick with the latest version you can find through this "modernization" process headed up by JS.
I'm on 4.06, which just made immutable strings a default, and broke a ton of libraries. If you run into a broken lib, this recent version change is almost certainly the reason. I strongly recommend 4.06 as a minimum version (if you're not working with legacy code). If there's a library you want to use that is not compatible yet, bug the maintainer to update it. I've run into problems trying to downgrade/upgrade my compiler version + all the tools. I can't recommend doing that, it kinda ruins the experimentation experience.
What else can I say? Opam, the package maintainer, is great. There's a great build system, nice IDE support with a set of tools called merlin, and the compiler is super fast. The compiler field-level error messages are generally helpful (typo-fix suggestions), but can be fiendishly opaque if you happen to mess up a match boundary (which can happen easily when mixing in if/then/else statements).
Most stuff is google-able, but there's a lot of "line noise" in OCaml function signatures - especially for variant types and labeled arguments. That's harder to search for, so read that section thoroughly in the book.
The Reason team's primary focus appears to be compiling Reason/OCaml to JavaScript. It's a nice language, but I'm not sure why they want to pass through a OCaml "middle end" before emitting JavaScript output. Why not just write a direct Reason->JavaScript compiler similar to TypeScript?
The advantage of having OCaml as the foundation is its excellent type system. It's very mature.
I'm relatively new to OCaml, just getting into it this year, but I've found that it forces me to write correct code first. I've been really impressed by it having come from the world of PHP/JavaScript/Swift and others.
Personally, I greatly prefer OCaml's syntax to Reason's. I find it much simpler, and less busy. But I know a lot of people are more comfortable with Reason's syntax. I definitely wouldn't call it "cleaner", though.
[1]: https://bucklescript.github.io [2]: https://jbuilder.readthedocs.io
http://donut2d.tumblr.com/post/171205516399/my-experiences-b...
But if nothing else, be sure to check out Real World OCaml[1]. It's pretty great and helped me out a lot getting started.
You'll find similar phrasing among major contributors to Postgres.
JS is probably confident in their ability to get their developments merged.
Indeed, one of the great things about the OCaml compiler development process is that the core team is highly skeptical, and does a good job of rejecting marginal changes.
I reeeaaalllly wanted to love Ocaml, but it just seemed like a collection of half baked tools and limited library support. So I learned Julia instead.
I would love to see a little unification and life come into ocaml to get its dev tooling up to par with other modern languages.
I gave up on it when I realized I had been spending more time debuging example code and conflicting versions of 'stdlib' type packages than i had been actually writing any Ocaml code.
My personal issue with OCaml eco-system is that for quality tooling Emacs feels like the only option.
There is also a lot of work going on in making the OCaml native development experience easier. install-ocaml (link above) actually takes you through building and testing a project using Dune (formerly JBuilder) which is fast becoming the standard way to build OCaml projects.
If you are however interested in just the language, you can get wonderful ergonomics by using BuckleScript/ReasonML. You'll be running your code using Node, or in the browser, and you'll get access to the large and wild npm ecosystem. You'll lose out on the native OCaml ecosystem, but there are attempts to meld both together.
If none of this is your cup of tea, then you have a great alternative in F# - it is Microsoft's attempt at OCaml, and has a few great features that are not present in the original language. It comes with great Visual Studio IDE integration and sits in the .net ecosystem like Clojure or Scala does in the JVM ecosystem.
Or you can use Elm or PureScript which are statically typed functional programming languages that run on the browser, or Haskell, or even Idris.
These languages have great differences between them, but all of them are ultimately statically typed functional programming languages. Julia is not. Typed FP gives you ADT, immutability by default, functions as first-class constructs, and lets you model complex software as just pure transformations of data. These things are worth learning just for them, and once you understand the motivations behind them well enough, the occasional jank would be but minor annoyances.
Where does $200 million+ come into it? What is the history there?
If you mean this "Tezos: the self-amending cryptographic ledger" ( https://tezos.com/ ), this look like something done from 4 amateurs in their spare time.
I don't know if it has "$200 million+" warchest, but if it does I pity the fools that gave it that.
I don't have a lot of faith in Tezos, and it's spent most of the time since its (well-known, but apparently not to you) over-funded ICO spent in legal fights over the money, instead of engineering. However, it's only fair to observe that a lot more thought and work did go into Tezos than most of the other Blockchain crap we see every day. Glancing at the marketing splash is hardly enough to assess that.
I'm not so sure. Besides there are lots of way more well known cryptocurrencies that are amateur hour themselves. It comes with the territory.
>well-known, but apparently not to you
Yeah, it's world famous among the people who follow these things...
At this point, if a language doesn't have first class support for multithreading and static typing, I wouldn't start a new project in it. Nullability support is pretty high up there too, but that is a far more tractable problem.
Out of curiosity, what is it about smart contracts that makes multithreading so important? Why isn't multiprocessing enough? [edit: sorry, I mis-read your comment. You said that multithreading probably isn't a big deal for this problem.]
https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june...
It's been a couple of years away for the last 10 years.
https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june...
Nullability? As in null references? The "billion-dollar mistake" (Tony Hoare, referring to Algol), also frequently called the "worst mistake in computer science"?
https://www.tutorialspoint.com/swift/swift_optionals.htm
It's also called nullability support, you can see it in use in this article:
http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...
Option type on wikipedia, cant paste the link somehow.
On any case, as someone else pointed out, OCaml had supper for option types built in, through sum types.
I agree that sum types are indispensable in a modern programming language.
Well, it's not yet ready, but it's incoming
https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june...
What is/was the problem with the current parser?
Helpful error messages have not been my experience.
On the other hand type error messages are simply awesome.
The days of Error: Syntax error. may be numbered
They move from a auto-generated compiler that sucks to another one (whose quality is yet to be seen).
Even if it proves to be great, it would still be an outlier.
I feel like on paper, at least, OCaml ticks all the boxes on my programming language wishlist: non-nullability, ADTs, type inference, compiles to binary. A lot like rust but a little higher level. But I've never really had a go at it. I'm sort of reluctant to sink time in it if there's not a future, but it seems to be kind of chugging along, not really gaining or losing ground, AFAICT.
I think concurrency is fine (threads and async are options) but parallelism still seems to always be just around the corner and never actually here. I understand part of the problem is making their GC able to handle parallel allocations without hurting basic allocation performance more than they're willing to do.
Single-threaded performance is generally good when natively compiled. In a benchmark I did a few years back, which consisted of traversing the filesystem with `opendir`, `readdir` and friends, OCaml was minimally slower than C++ and Nim (when compiled natively) and around Python and Racket when byte-compiled. It probably would be even faster if I used its imperative features. Looking at the code today I also see some unnecessary copying of lists, which could be mitigated. All in all, I think OCaml has a really good performance considering its high-level semantics. You have to be aware of relative costs of operations, but if you do, "as fast as C" is certainly attainable. OCaml code for the benchmark: https://klibert.pl/posts/walkfiles-ocaml.html and the results: https://klibert.pl/statics/images/walkfiled_perf_test1.png
[1] Actually, I just checked and it looks that `fork` is not implemented, so copy-on-write memory sharing is impossible, even on POSIX systems. Docs: http://caml.inria.fr/pub/docs/manual-ocaml/libunix.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html
Unix module docs (with fork!): http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html
type 'a ty = Int : int ty | Bool : bool ty | String : string ty;; data Ty a where
Int :: Ty Int
Bool :: Ty Bool
...I suggested Ceylon as the 'modern day substitute' in the sense that it has had the opportunity to learn from mistakes made by the older FP languages. Ceylon has a very consistent type system and is therefore able to deliver more clear error messages.
But note: every single language has warts like this, especially if it's been developed for a couple of years already. I think OCaml has probably fewer warts than JavaScript, or PHP, or even Java; but more than Go, or Elixir, or Scheme. It's still very nice language and toolchain, though, perfectly usable in many cases - the learning curve may be steep at some points, but on average it's not that hard to learn, and you gain a lot of benefits if you do.
It has one standard library, and several alternative standard libraries of varying popularity. I would argue that Core is probably the most popular. For what it's worth, Haskell also has several replacement for its standard library, Prelude.
For the syntax extensions, the community has largely migrated to PPX. Alternatives are being phased out.
String is no longer mutable in recent versions of OCaml. The string type is now immutable, and a new type, bytes, has been introduced which is mutable.
For one, the different stdlibs are in fact highly compatible. Basic types (option, result, string, int, array, float) are all the same, so code using different stdlibs works together seamlessly most of the time.
Lwt and Async are a different story, and there is a real incompatibility problem there.
The syntax extension story is pretty clear and simple: PPX rules the roost, and the tools for building PPXs are quickly getting better and more unified. Reason is an interesting variant in the ecosystem, but its existence doesn't amount to a wart in my eyes. It's an alternative syntax that you can use interoperably with the rest of the OCaml ecosystem (and Dune makes that awfully easy.)
Kotlin basically has the Java type system with a few extensions, but no substational changes.
Ceylon has its own type system that draws heavily from the FP/ADT style of thinking. It's not OCaml (nor does it want to be), but it's also not Kotlin.