OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.
It still doesn't really meet your idea you probably have in your head. When people can choose between different types of pointers, people will choose rust's normal lightweight lifetime references 99% of the time. Gc<T> will probably only be used in those rare cases where an object has no clear owner. They figured this out in the early days of rust.
Unfortunately, the fsharp.org site is kind of out of date. I think that's mostly a function (heh) of the MS F# docs becoming much better (can be found here[6]). These instructions for getting a dev environment set up are pretty good[7]. If you hunt around, you can also find blog posts which may be a little more comprehensive[8][9][10].
[1] https://fsharpforfunandprofit.com/why-use-fsharp/
[2] https://fsharpforfunandprofit.com/series/designing-with-type...
[3] https://fsharpforfunandprofit.com/series/thinking-functional...
[4] https://fsharpforfunandprofit.com/series/map-and-bind-and-ap...
[5] https://fsharpforfunandprofit.com/site-contents/
[6] https://docs.microsoft.com/en-us/dotnet/fsharp/
[7] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/
[8] https://atlemann.github.io/fsharp/2018/01/13/fsharp-on-ubunt...
[9] http://www.prigrammer.com/?p=363
[10] https://medium.com/@edgarsanchezg/four-easy-steps-for-instal...
[1] - ziglang.orgAs Python dev since 10 years I can't point fingers -- Python is probably worse though I've memorized the idiosyncrasies -- but I couldn't justify my way up the tooling learning curve in addition to the language curve.
Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support, but we're quite close to finishing that.
[0] http://fable.io
Is there a viable cross platform ui option for f# on core?
Since it's useless, not having it is great since you no longer have to worry about it and the problems it causes like random pauses, sawtooth-shaped and excessive memory usage and inability to use swap properly (although you have to worry about heap fragmentation, but usually that's not as terrible).
Also you'd need lifetimes and borrowed references anyway to have static guarantees like that there are no remaining references to mutex-protected data after you unlock the mutex, so having a GC as well actually increases complexity.
I think there's a lot to that. I'd be really interested to try it, though, to see how it pans out.
What I’d like to see is for one language to be possible to use “vertically” through a stack. That is - for example a C# systems version with manual memory that you can use instead of C interop for the small core of your app. Or, the opposite, a dumbed down version of Rust that works well for classic reference heavy UIs and similar.
I get what you're saying though. Another poster mentioned Swift and indeed Graydon Hoare, Rust's creator, is now working on Swift at Apple. And I believe some kind of notion of borrow checking/lifetimes is supposed to be coming to Swift in the future?
I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.
I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things.
I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward references, a plethora of file types to deal with, no UTF8 strings without bringing in an external lib, and so on).
You don't need to use bucklescript toolchain to write Ocaml, it has a very good package manager, the build-system tooling is getting better, already has great editor support for many years now(merlin).
I think the tooling scene is much better than Haskell. Not sure what you mean by "no forward references"?
I'm guessing they are talking about having implicit mutual recursion between items in a module, like Haskell has.
I probably got the name wrong, but it's the ability to use a function before it is defined.
In OCaml/ReasonML, you'd have to use the rec keyword and structure your codebase in a particular way to define mutually-recursive functions. It is a small but noticeable papercut, especially since recursion is so common in a functional language.
F# code (with a catch) --> F# AST --> Bable AST --> JS
The big thing here is that the F# code you write has slightly different semantics than "normal" F#. That's because the runtime environment is different, and so you can't escape that. Rather than attemp to gloss this over, the Fable creators are pretty explicit about this, including documenting each of the (small) differences. The result is pretty good. Abstractions don't seem too leaky from my vantage point.
AFAIK there is some work on a GC in Rust, but it doesn't take away the borrow checker like you wished ;) So you will still need to use `.borrow()` and `.borrow_mut()`.
A language similar to Rust but with GC (and no borrow checker) could be quite useful for a lot of applications out there. Basically Go but a more "modern" language.
(ARC, not tracing GC, but still.)
ARC is automatic reference counting. Arc is Atomic reference counting.
In Rust you still have to manually .clone() to addref an Arc. In swift you don't. This is a major difference ergonomics-wise.
I wonder how threading would work without the borrow checker though. It would be cool if you could still have the "fearless concurrency part".
But if you are willing to accept runtime GC, a JIT runtime like JVM/Node might also not be out of the question.
So Scala Native would be spot on, if it were ready for production use.