The author of the talk here. I am excited about the Multicore OCaml upstreaming plan.
We're going to phase it into 3 distinct phases. First, we will upstream the multicore runtime so that it co-exists with the current runtime as a non-default option. This will give a chance to test and tune the new GC in the wild. Once we are happy with it, it will be made the default.
The second PR would be support for fibers -- linear delimited continuations without the syntax extensions (exposed as primitives in the Obj module). This will help us test the runtime support for fibers and prototype programs.
The last PR would be effect handlers with an effect system. Any unhandled user-defined effects would be caught statically by the type system. The effect system is particularly useful not just for writing correct programs, but to target JavaScript using the js_of_ocaml compiler where we can selectively CPS translate the effectful bits à la Koka. As a result, we will retain the performance of direct-style code and pay extra cost only for the code that uses effect handlers. In the future, we will extend it to track built-in OCaml effects such as IO and mutable refs. At that point, we can statically distinguish pure (as Haskell defines it) functions from impure ones without having to use Monad transformers for the code that mixes multiple effects. I'd recommend Leo White's talk [0] on effect handlers for a preview of how this system would look like.
What really surprised me, that Facebook with so active usage of ReasonML doesn't push/sponsor Multicore OCaml. Surely that will improve performance in their high-load setups.
ReasonML has only very superficial changes to ML using the ppx AST extension framework. Multicore GCs are not really what Facebook planned on contributing, or at least has shown signs of contributing yet. It is also a bit outside of the scope of their project since they (mainly) market reason for compiling to JS VMs.
Rust is beginning to understand that they need more stability and LTS versions, and libraries are blossoming nicely.
Ocaml already has a very mature module ecosystem and is now becoming safe and modern.
I think rust will still have an edge in adoption due to its portrayal as C++ unfucked, but ocaml is definitely the easier tool to work with, imo. And maybe that will change.
I don't think even linear types and multicore would be enough for ocaml to make any significant dent in the systems programming world. Rist and C/C++/D/Zig all do memory management too conveniently, and it opens doors too close to the bottom for ocaml to keep up.
Any ocaml hackers: would you want to write system drivers in ocaml? Why/ why not?
I feel like OCaml is a language that has a lot of potential, but is hampered by somewhat gnarly syntax, a toolchain that feels utterly antique (for example, last time I worked with it, the REPL had no Readline support and had to be run with rlwrap), and lack of a good killer app.
In some ways, OCaml's problem mirror that of Erlang. The gnarly syntax is largely being addressed by Reason (much like Elixir does for Erlang), but I don't see it catching on as much as I'd like, and it still has some warts, I think.
As for killer apps, distributed data processing is something that OCaml could be great at, given that it marries Erlang's functional style with a rich type system, and there was a minor wave of libraries (for concurrent, distributed actor programming) way back in the 2010 or so, but those libraries are now dead and nothing really happened. Meanwhile, Scala largely leads that story (Akka is very popular, and Scala also seems to be the language of choice for Spark, Beam, etc.) and Haskell now has Cloud Haskell, which is modeled on Erlang. Also, we kind of need multicore for this.
(Distributed data is an area where I hope the Java/Scala world gets competition soon. A lot of people, I suspect, would like this, so there's an opportunity to rapidly gain mindshare. I don't see much happening there. Pony is promising (e.g. Wallaroo), and some people have had success with Go (Pachyderm). I don't know Pony, but without genetics, Go is a pretty awkward fit for data pipelines; witness the number of hoops jumped, and resulting limitations, in the Apache Beam SDK for Go. Spark et al rely on distributing bytecode to worker nodes, something you just can't do in Go. Not sure about OCaml.)
I'd say if you ever get the time again, give OCaml another look. The toolchain experience has been improving at a rapid pace! I started to explore OCaml again earlier this year and the day to day tooling around it has felt at par or better than my experience with other languages.
Between Opam [1], Dune[2] and utop[3] the "new comer experience" has been really good so far. The editor integration with vim/emacs has been top notch, and visual studio code has turned into a really nice option as well for people who don't like vim/emacs. I'm sure there is still room for improvement, but i'd say its atleast heading in the right direction!
compiler writing could well be ocaml's killer app; the problem is that it's a very niche application in terms of the number of people who do it. i was hoping facebook's pfff [https://github.com/facebook/pfff/wiki/Main] would extend that to language analysis tooling in general but it never seemed to catch on.
What should I learn if I want to develop desktop apps and I like functional programming? I feel like most of the cool 'new' programming languages are OOP (rust, go, scala).
For desktop apps specifically + functional programming, F# is probably your best bet. On Windows WPF is king, and F# works great. For desktop apps on Linux and elsewhere, you can use Xamarin, GTKSharp, AvaloniaUI...and the list goes on. Desktop apps are a strength of the .NET ecosystem.
> I feel like most of the cool 'new' programming languages are OOP (rust, go, scala).
For what it's worth rust and go are not OOP languages. Scala and Swift (to add another new, hot language) have inheritance and OOP features for ffi with their platform langagues java and objective-c respectively. However, the OOP features are largely discouraged and their type systems have more in common with haskell and other strongly typed functional languages. Rust has basically the same type system as haskell and swift with its famed borrow checker on top. Scala, Rust, Swift are all mixed paradigm with their community's' preference for functional design in roughly that order. Go has a totally different type system from the others and is almost entirely an imperative langauge.
F# got mentioned already but I would like to add another vote to it. C# is the first choice for most people when building desktop apps for Windows but F# works exceptionally well too. There is a small but robust community and there are a ton of libraries/tools that you can hook into via .NET.
after some functional programming experience, you may learn that functions just compose more elegantly than objects.
"Objects are a poor man's closures" (NN)
some heropunch community members have expressed their intention to take responsibility for x0[1]. the plan is to build a nice DSL in elixir that binds to nuklear[2]. some of my notes are in the linked repo, but i'm currently focused on other aspects of the toolkit.
really looking forward to seeing where they go with it!
I’m not sure where your perception is coming from. Rust and Scala are more functional than they are OOP. Rust for example uses Hindley-Milner type inference, putting it squarely in the functional camp. And Scala is highly functional as well, considering its use of higher order functions and monads.
The newest thing in functional languages and UI is haskell + reflex. Reflex is a usable FRP system (not that reactive-banana, et al, were not; just that they were not usability focused at all). Reflex-dom is pretty nice for web stuff, and you can use reflex to build apps with other UI toolkits as well.
If you can afford to exclude windows and linux, Swift.
If you like windows but also want cross platform, C#/F# and Xamarin.Forms or UI or whatever its called. I've heard very positive things about dotnet gui work these days.
I'm spending time with rust to try my hand at game development. As an older developer, it's all a bit foreign to me so I don't really know what's good and what's not.
That having been said, desktop development is something the rust community at large is dedicated to ant interested in. There's already a fee libraries, like Conrod for Piston, gtk.rs, etc but I don't know how these options stack up against industry standards.
C# 7 is a lot more functional and pleasant than the C# 4/5 everybody dismissed years ago.
F# can compile to wherever you need it and you can write functional first and just include it in your nuget built just like you normally would.
If you're adamant about functional, consider dotnet. Of course C# is still very much OOP, that's just what it is. But I find the primary benefits to FP in my own code to be more related to correctness, testability (and therefore more correct) and a convenience in modelling data structures quicker than subclassing. Even with generics, having unions and record types makes it just that much more satisfying.
F# actually has a little micro-discipline called domain-driven programming. Search for that term and you can see how different researchers have used F#'s incredibly flexible type modelling to adapt to their domain and make their code easier for people in that domain easier to understand.
OPAM and Dune (jbuilder) work very nicely IME. You don't need to touch a Makefile, you don't need to build anything by hand outside of the package manager.
I saw a discussion once (can’t remember where) about the possibility of adding opt-in GC functionality to Rust. If that ever comes to fruition, I wonder if that’d cover many of the current use cases for OCaml?
I mean stability in what they are offering. LTS versions are essentially being done through the concepts of Editions, where every other year or so, a new edition is released and the changes and new features from the previous edition up to that point are summarized.
It's not that rust code is breaking, that's not it. It's that with new things happening every six weeks, if I wanted to write something that 100 developers will work on, how would I do that? Where I would begin? What version should I choose to ensure everybody is on the same page?
Once 2018 edition is polished up, this will be mostly a solved issue, so kudos to rust team.
I don't think that 'slow' is the problem here: C++ developers use shared_ptr almost everywhere, which is just reference counting and hence slower than if they were to use a garbage collector (yes, there are garbage collectors for C++).
I think the problem is that the cost is unpredictable. They want absolute control over _when_ things happen.
While ocaml is garbage collected, you can always tell exactly when the garbage collector will run - and it's very feasible to write code in a non-allocating, non-garbage collecting style when necessary.
Readit News
We're going to phase it into 3 distinct phases. First, we will upstream the multicore runtime so that it co-exists with the current runtime as a non-default option. This will give a chance to test and tune the new GC in the wild. Once we are happy with it, it will be made the default.
The second PR would be support for fibers -- linear delimited continuations without the syntax extensions (exposed as primitives in the Obj module). This will help us test the runtime support for fibers and prototype programs.
The last PR would be effect handlers with an effect system. Any unhandled user-defined effects would be caught statically by the type system. The effect system is particularly useful not just for writing correct programs, but to target JavaScript using the js_of_ocaml compiler where we can selectively CPS translate the effectful bits à la Koka. As a result, we will retain the performance of direct-style code and pay extra cost only for the code that uses effect handlers. In the future, we will extend it to track built-in OCaml effects such as IO and mutable refs. At that point, we can statically distinguish pure (as Haskell defines it) functions from impure ones without having to use Monad transformers for the code that mixes multiple effects. I'd recommend Leo White's talk [0] on effect handlers for a preview of how this system would look like.
[0] https://www.janestreet.com/tech-talks/effective-programming/
Or perhaps port or create a system similar to OTP using the effects, fibers, and threads.
Rust is beginning to understand that they need more stability and LTS versions, and libraries are blossoming nicely.
Ocaml already has a very mature module ecosystem and is now becoming safe and modern.
I think rust will still have an edge in adoption due to its portrayal as C++ unfucked, but ocaml is definitely the easier tool to work with, imo. And maybe that will change.
I don't think even linear types and multicore would be enough for ocaml to make any significant dent in the systems programming world. Rist and C/C++/D/Zig all do memory management too conveniently, and it opens doors too close to the bottom for ocaml to keep up.
Any ocaml hackers: would you want to write system drivers in ocaml? Why/ why not?
In some ways, OCaml's problem mirror that of Erlang. The gnarly syntax is largely being addressed by Reason (much like Elixir does for Erlang), but I don't see it catching on as much as I'd like, and it still has some warts, I think.
As for killer apps, distributed data processing is something that OCaml could be great at, given that it marries Erlang's functional style with a rich type system, and there was a minor wave of libraries (for concurrent, distributed actor programming) way back in the 2010 or so, but those libraries are now dead and nothing really happened. Meanwhile, Scala largely leads that story (Akka is very popular, and Scala also seems to be the language of choice for Spark, Beam, etc.) and Haskell now has Cloud Haskell, which is modeled on Erlang. Also, we kind of need multicore for this.
(Distributed data is an area where I hope the Java/Scala world gets competition soon. A lot of people, I suspect, would like this, so there's an opportunity to rapidly gain mindshare. I don't see much happening there. Pony is promising (e.g. Wallaroo), and some people have had success with Go (Pachyderm). I don't know Pony, but without genetics, Go is a pretty awkward fit for data pipelines; witness the number of hoops jumped, and resulting limitations, in the Apache Beam SDK for Go. Spark et al rely on distributing bytecode to worker nodes, something you just can't do in Go. Not sure about OCaml.)
Between Opam [1], Dune[2] and utop[3] the "new comer experience" has been really good so far. The editor integration with vim/emacs has been top notch, and visual studio code has turned into a really nice option as well for people who don't like vim/emacs. I'm sure there is still room for improvement, but i'd say its atleast heading in the right direction!
[1] https://github.com/ocaml/opam
[2] https://github.com/ocaml/dune
[3] https://github.com/diml/utop
[4] https://github.com/ocaml-ppx/ocamlformat
I don't remeber anyone on those assignments ever complaining about syntax.
What should I learn if I want to develop desktop apps and I like functional programming? I feel like most of the cool 'new' programming languages are OOP (rust, go, scala).
Some links:
https://fsprojects.github.io/FsXaml/
https://github.com/Prolucid/Elmish.WPF
https://github.com/GtkSharp/GtkSharp
https://github.com/AvaloniaUI/Avalonia
https://github.com/xamarin/xamarin-macios
Because significant portion of your learning/cognitive effort you will be spending on understanding the UI paradigms offered by a given GUI toolkit.
So take a look at the languages, in language bindings available for
1) Qt UI toolkit http://wiki.qt.io/Language_Bindings
2) at the languages, in the language bindings available for wxWidgets UI toolkit
https://en.wikipedia.org/wiki/List_of_language_bindings_for_...
2) And same for FLTk http://www.fltk.org/wiki.php?LC+P139+TC+Q
Perhaps, also, you can also investigate if you can use F# (equivalent somewhat to ocaml), to develop Windows Apps with https://github.com/Microsoft/react-native-windows
Same for Nim https://github.com/andreaferretti/react.nim (there is probably a way to package it as Electron App ).
(depending on your desire for adventure/early/small community/small ecosystem interest)
For what it's worth rust and go are not OOP languages. Scala and Swift (to add another new, hot language) have inheritance and OOP features for ffi with their platform langagues java and objective-c respectively. However, the OOP features are largely discouraged and their type systems have more in common with haskell and other strongly typed functional languages. Rust has basically the same type system as haskell and swift with its famed borrow checker on top. Scala, Rust, Swift are all mixed paradigm with their community's' preference for functional design in roughly that order. Go has a totally different type system from the others and is almost entirely an imperative langauge.
Or F# with WPF, though F# is also OOP, but for some reason I feel its less so then Scala, and forces more functional constructs on you.
ClojureScript with Electron can also be an option if you're okay with Electron apps.
Finally Haskell and reactive bananas is an option too, that's pretty strongly functional.
I'll also mention Red, red-lang.org, its still in alpha, but is pretty sweet for simple GUI app on desktop.
If you don't mind your app working through Electron or some other variation of a web-view, there's a lot of resources for those.
really looking forward to seeing where they go with it!
[1]: https://source.heropunch.io/tomo/x0
[2]: https://source.heropunch.io/mirror/nuklear
You can also check out Racket.
If you like windows but also want cross platform, C#/F# and Xamarin.Forms or UI or whatever its called. I've heard very positive things about dotnet gui work these days.
I'm spending time with rust to try my hand at game development. As an older developer, it's all a bit foreign to me so I don't really know what's good and what's not.
That having been said, desktop development is something the rust community at large is dedicated to ant interested in. There's already a fee libraries, like Conrod for Piston, gtk.rs, etc but I don't know how these options stack up against industry standards.
C# 7 is a lot more functional and pleasant than the C# 4/5 everybody dismissed years ago.
F# can compile to wherever you need it and you can write functional first and just include it in your nuget built just like you normally would.
If you're adamant about functional, consider dotnet. Of course C# is still very much OOP, that's just what it is. But I find the primary benefits to FP in my own code to be more related to correctness, testability (and therefore more correct) and a convenience in modelling data structures quicker than subclassing. Even with generics, having unions and record types makes it just that much more satisfying.
F# actually has a little micro-discipline called domain-driven programming. Search for that term and you can see how different researchers have used F#'s incredibly flexible type modelling to adapt to their domain and make their code easier for people in that domain easier to understand.
Hope this helps!
It just needs a cargo equivalent. The existing tools weren't sufficient last I checked.
(Haven't used cargo, and only briefly touched OPAM. Don't know the feature gap, but am curious to learn more)
[1] https://opam.ocaml.org
Do you have any resources on this? I am learning Ocaml and am interested to see what is changing.
i though rust has been stable since 1.0. am i wrong?
It's not that rust code is breaking, that's not it. It's that with new things happening every six weeks, if I wanted to write something that 100 developers will work on, how would I do that? Where I would begin? What version should I choose to ensure everybody is on the same page?
Once 2018 edition is polished up, this will be mostly a solved issue, so kudos to rust team.
But yeah. This is an ocaml thread anyways.
Computing history has lots of examples, all the way back to Mesa/Cedar workstations at Xerox PARC.
Android Things user space drivers are mostly written in Java.
Deleted Comment