Flow9 programming language is now open source | Hacker News Reader

Flow9 programming language is now open source

github.com

179 pointsexebook52 comments

The accompanying blog posts includes a lot more information and screenshots: https://flow9.org/2019/04/26/why.html

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.

What do you mean by "not getting through the moderation"? Everyone is free to leave comments...

Not sure about this, all I know is he told me that he left the comment and the comment have never appeared.

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.

If his username is concolor his comment is marked as [dead] for some reason.

> 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 says that Flow apps run everywhere (Android, iOS

I'm curious too since I did a quick browse and there doesn't seem to be any info/docs on generating an APK.

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.

Anybody?

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 :)"

It is GC only. For our C++/bytecode target, we have an incremental, copying GC. For our experimental Wasm target, we have a ref-counted version.

Does the GC ( and the language ) support OS threads natively?

We have some support for concurrency in Java and JavaScript backends, see lib/sys/concurrent.flow.

Setup steps very strange

You are being downvoted, but I agree.

Look at https://github.com/area9innovation/flow9/blob/master/doc/lin....

That's a lot of hoops for something that should probably be a precompiled binary.

We want to roll a Docker-image to make this easier, but did not get around to it yet. Contributions welcome.

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.

- QtByteRunner is licensed under LGPL 3 http://www.gnu.org/licenses/lgpl-3.0.html

Does anyone how / where this is used? If it is in the runtime it would prevent embedded use (inside signed firmware) without making all code GPL..

Linking against lgpl code does not make the whole programm lgpl. Thats the point of the lgpl,in contrast to the gpl.

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.

Interesting. To quickly check this out on Windows, how about including a pre-compiled demos[1] app?

[1] https://github.com/area9innovation/flow9/blob/master/demos/d...

We want to enhance the web site to have some runnable demos, but did not around to it yet.

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.

You need to rebuild QtByteRunner. Cd to platforms/qt/. There is a readme there for full explanation, but in short:

- clone asmjit (https://github.com/area9innovation/asmjit.git) into platforms/common/cpp folder first (eventually we'll move to upstream asmjit, we use our copy of this lib yet);

- make sure you have Qt 5.12.0 (or upper) available in your system;

- review paths in QtByteRunner.pro, they're usually fit our needs, but in some cases may require changes;

- run build.sh, it'll produce binary for your system.

Then you'll be able to run flowcpp tool.

The call chain is:

- you run flowcpp and feed it with .flow file;

- flowcpp see that it is source file and calls compiler

- compiler produces .bytecode file

- flowcpp executes .bytecode file and runs file you called.

You can call compiler directly with flowc or flowc1 commands.

Great, thanks for the explanation!

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.

Great news ! I was waiting for it for more then a year!

What does it mean that it has an incremental compiler? Does it support hot code reloading like Common Lisp?

It means compiler caches results of module compilation and reloads them if module didn't change. Hot code reloading is not supported.

Why open sourcing this ? I don't see any article mention this one.

Take a look: https://blog.area9lyceum.com/area9-open-sources-flow-program...

> 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.

https://reasonml.github.io/docs/en/what-and-why

>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.

Also, Reason catch on much?

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).

It always annoys me when people describe Elixir as “friendlier” than Erlang because it’s familiar, or assert that familiar is an unalloyed positive.

Why does it annoy you?

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.

Naming it like Facebook's Flow https://flow.org/ might not be the smartest idea.

Reading the article might help.

> Flow was conceived almost 9 years ago

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.

If you're at all intrigued, I made a go at implementing the interface as described here: https://bitbucket.org/oofoe/flow

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.

So, bad SEO might turn the tide against these guys?

Can we get a rap about that?

I think there ought to be a verse for Go too.

I always search for "golang" instead of "go", seems to provide good results. Same with crystal, searching for "crystal lang" seems to help.

Slight inconvenience, but not a deal breaker.

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.

I believe they renamed it to Flow9 at least partly because of the namespace clash with FB's Flow.

Reply on news.ycombinator.com