Interestingly, the language seems similar in a lot of ways to https://reasonml.github.io/ in that it is an ML-like language with a more C-family syntax with parentheses and braces, that can compile either to idiomatic JS or native code. There's also an in-progress cross platform UI library for Reason using a React-like style https://github.com/revery-ui/revery
The article also links to Haxe. It looks like Haxe does not come with a cross-platform UI framework, but there are some projects that appear to do just that.
It seem that indeed Flow9 is the only thing I'm aware of that provides a great cross platform UI framework. There is Qt which targets desktop and mobile, and there are a whole bunch of JS solutions that target some but not all platforms.
I'm a bit weary of learning the language on its own merits, as it does not really seem to innovate over what I already know, but if I'd had to write a cross-platform app, it's definitely worth considering.
My friend who works on Flow9 for something like two years was willing to answer questions, but his message did not get through the moderation in this thread I believe. Basically Flow is a functional language somewhat similar to OCaml (that's my naive understnding). It has multiple backends, and my friend who originally is a math teacher in university and develops theorem provers was hired to work on some of the backends, I think it was the Java backend. He is always so exited talking about Flow, and kept telling me for a about year that they are going to release it as open source and there is a lot of excitement because of that.
I wish they could build a community around this language at least as successful as OCaml's community is.
Sometimes comments get caught in spam filters. I'm not seeing any case of that here, but if your friend's comments aren't visible, please tell him to email us at hn@ycombinator.com so we can mark his account legit.
> Flow is a complete platform for writing apps in a functional programming language that can run everywhere.
It says that Flow apps run everywhere (Android, iOS and the browser via HTML5). Maybe I missed it, but how does it do this? Does it compile to a progressive web app?
It has multiple backends. It can produce optimized JS, readable JS, typescript, and that can be used for progressive webapps.
It also has a Java backend for server-side use and command line programs (such as the self-hosted compiler).
It has a native bytecode, which is used for Android and iOS native apps. There is a 64-bit JIT for x64 for Linux, Mac, Windows for this bytecode as well.
There is also a C++ backend, which can also be used for Android, iOS and desktop OSes.
There is also a C# backend for Windows Phone, but since that platform is dead, it has bitrotted. Should not be too hard to resurrect if someone needs it.
The language is relatively small, so easy to add a new backend. The biggest task is to port the runtime.
Doesn't seem to say whether it is an obligate-GC language, or supports something akin to the C++ destructor or the Rust "Drop trait". The JS target suggests GC, but that would not forbid programmed resource management.
I've been told it's GC only in their Telegram channel.
"May cause memory leakege if used unproperly - f.e. not calling unsubscriber functions for so called behaviours. Read the following manual before use :)"
I really like the jit implementation. small, fast, elegant, does not do much more than it needs to do: inline certain ops but not all, apply type specializations to some. x86_64 only.
Dynamic linking is indeed specifically exempted with the LGPL, but static linking is not; building a statically-linked binary would require the whole program to be under the (L)GPL.
Exactly. And embedding in an app or firmware that needs to be signed before deployment, in other words, the end user cannot update the lpgl part and deploy this new binary on the device, is seen as static linking. Since lgpl 3 even the legal gray area of Tivonisation is taken care of.
Which might some people wonder if the use of flow9 in a closed source Android or iOS app is even allowed. Can the end users create a new version of the app with an updated version of the lpgl3 lib AND deploy this library on their device? Normally they can not, but you can provide your binaries and build scripts to be compliant. See also this answer (not by me): https://stackoverflow.com/a/39438539
So in the end only for closed source non user updateable (signed) firmware, the use of LGPL3 is impossible. Think about most TV settop boxes or payment terminals.
I could not find any information on how to compile the compiler itself. Trying to run this on CentOS 7 fails because it is looking for libjpeg.so.8, but CentOS provides libjpeg.so.62.
What's tooling like? Would be keen to jump on if, say, generating a web app, an exe, and an apk were straightforward, but it seems to be anything but that.
> Meet flow
> flow is a simple, functional language in the ML family
Cool!
> C-family syntax
> Designed to look like other languages and be easy to learn
Uh, what? A functional language is going to be easy to learn because it "looks like other languages"? "C-family syntax" is what makes a language easy to learn? Gee, why didn't I think of that...
> A functional language is going to be easy to learn because it "looks like other languages"? "C-family syntax" is what makes a language easy to learn?
Facebook had the same rationale with Reason, so it's not unusual.
>Reason is not a new language; it's a new syntax and toolchain powered by the battle-tested language, OCaml. Reason gives OCaml a familiar syntax geared toward JavaScript programmers, and caters to the existing NPM/Yarn workflow folks already know.
I know it's not "unusual"... I've seen the same wrong-headed reasoning many times before. But syntax is rarely a significant obstacle to learning a language, it's the semantics that bite! And when the semantics are significantly different I think that a familiar syntax might make things harder rather than easier by confusing form and function.
So, I regret posting this... sarcasm isn't even my style, and I don't like to be negative. But I do think the approach is wrong... I just don't believe you can make a language easy to learn by shoe-horning a "familiar" syntax onto strange new semantics. And you're not likely to create an expressive, concise and readable language that way.
The motivations behind this language are interesting to me... a strongly-typed functional language focused on cross-platform GUIs could certainly have its niche. That's why it made me sad to see the approach to syntax they decided to take.
It really works, since we've hired many people, which obviously were not familiar with Flow. I came myself as c-family programmer. It took about 3,5 weeks for me to learn the language itself and be introduced to some inner techs, such as UI and parser(we have a bunch of exercises for these purposes).
Treating familiarity as equivalent to friendliness is a disservice to languages that have other benefits, and to developers who may not have the exposure/experience to recognize the vast power that is outside their horizon.
"Elixir is more friendly than Erlang" is both subjective and misleading. It's more verbose than Erlang, which to me is not friendly. It has more complex syntax, which to me is not friendly. I don't believe that it has a significantly lower learning curve than Erlang despite its familiarity.
Actually, if you want to go back even further... Jef Raskin of Mac fame created a programming language called FLOW in 1971 for teaching computer programming to humanities students. It's a cute little language (you definitely wouldn't want to implement anything significant with it) but he claimed that students who worked with it first did much better when introduced to "traditional" languages (BASIC, FORTRAN, etc.) than those who went in cold.
Among other things, it has the first implementation of what we would now call "autocomplete" that I know about.
References at the bottom of the page. I actually contacted the Stanford University Library to get them to send me copies of his journal pages and papers so I could implement it.
Not sure it matters seeing as Facebook's Flow is already more popular. Good luck searching for "How do I [X] in flow" without getting more result for Facebook's Flow.
Even if Facebook's Flow never existed, the word "flow" is a challenging term to search for and was a poor name for both Flow9 and Facebook's Flow.
However, it was only open-sourced now, while FB Flow has been open-source for several years. It is actually kind of confusing considering both target JS.
Interestingly, the language seems similar in a lot of ways to https://reasonml.github.io/ in that it is an ML-like language with a more C-family syntax with parentheses and braces, that can compile either to idiomatic JS or native code. There's also an in-progress cross platform UI library for Reason using a React-like style https://github.com/revery-ui/revery