A Go Custom Flutter Engine Embedder for Desktop(github.com)
github.com
A Go Custom Flutter Engine Embedder for Desktop
https://github.com/Drakirus/go-flutter-desktop-embedder
113 comments
I had the same issue.
"Go Flutter desktop embedder". Well, that's that? Click (https://github.com/flutter/flutter/wiki/Custom-Flutter-Engin...)
"The Flutter Engine is window toolkit agnostic. " What's flutter engine? Click (https://github.com/google/flutter-desktop-embedding)
"The purpose of this project is to support building applications that use Flutter " Ok, but what's Flutter? Click (https://github.com/flutter/flutter)
"Flutter is Google’s mobile app SDK for crafting high-quality native interfaces on iOS and Android in record time."
OOOOH. Ok.
"Go Flutter desktop embedder". Well, that's that? Click (https://github.com/flutter/flutter/wiki/Custom-Flutter-Engin...)
"The Flutter Engine is window toolkit agnostic. " What's flutter engine? Click (https://github.com/google/flutter-desktop-embedding)
"The purpose of this project is to support building applications that use Flutter " Ok, but what's Flutter? Click (https://github.com/flutter/flutter)
"Flutter is Google’s mobile app SDK for crafting high-quality native interfaces on iOS and Android in record time."
OOOOH. Ok.
But what is Android and iOS? What is an SDK? There is only so deep the rabbit hole can go. They chose to stop the explanation at Flutter and I don't blame them. If you aren't already using Flutter, this won't help you as you now have to go learn a whole other library first.
"Flutter is a cross-platform UI toolkit that aims for pixel-perfect, native look and feel on each platform while minimizing code differences."
Does that help?
Does that help?
Does it work similarly on desktop platforms?
Not to my knowledge, I think right now it's just iOS and Android.
It's safe to say that if you aren't already interested in Flutter, you probably don't need to pay much attention to this project.
Unless of course you don’t know that Flutter exists but are very much working in that problem space.
If you're working in that problem space, you should already have seen news about Flutter...
One would think, but it isn't inherently unreasonable that someone wouldn't.
It's definitely ok to not know what flutter is. It seems a little unreasonable to expect specialized projects to define everything from the ground up, though.
100% agree. Haven’t been trying to suggest otherwise. Firmly in the camp that mentioning Flutter is more than enough, and discovering what it is should be left as an exercise for the reader. This all started because I was mildly disputing that this was only of interest to someone already interested in Flutter itself, as opposed to the problem space.
Very constructive indeed. For cross-platform GUI I have investigated flutter(among others, flutter at the moment is really just mobile only, so does Kivy)
It appears to produce a commercial quality cross-platform GUI, with not-so-bad looking, your only choice is Qt, be it Pyside2 or Qt/C++. For me I decide to use Pyside2.
It appears to produce a commercial quality cross-platform GUI, with not-so-bad looking, your only choice is Qt, be it Pyside2 or Qt/C++. For me I decide to use Pyside2.
I ended up choosing Dear ImGui recently
https://github.com/ocornut/imgui
Depends on the complexity of the GUI you need and on other factors.
QT is OK if your GUI is very complex and you're targeting a desktop OS.
For simple GUI QT is just too big.
For GUIs without a desktop OS (mobile, embedded), QT is not a good fit either, not enough mobile support, and their embedded license can be prohibitively expensive.
I have positive experience building moderately complex commercial quality GUIs on top of this: https://github.com/memononen/nanovg
QT is OK if your GUI is very complex and you're targeting a desktop OS.
For simple GUI QT is just too big.
For GUIs without a desktop OS (mobile, embedded), QT is not a good fit either, not enough mobile support, and their embedded license can be prohibitively expensive.
I have positive experience building moderately complex commercial quality GUIs on top of this: https://github.com/memononen/nanovg
Actually QT GUI is pretty popular in embedded space(if you're not using Android that is)
in my case I want to build a file manager and after some research I ended up with Pyside2
in my case I want to build a file manager and after some research I ended up with Pyside2
Another way to do true cross-platform Desktop GUI will be leveraging browser on MacOS/Linux/Win, you put your core logic in GO which runs as a local http-server on your Desktop that talks to your OS underneath, and use browser/html/css/javascript to do the UI. You only need ship the GO binary, users install it and then starting to use your program via a browser.
That sounds nothing like “true cross-platform GUI” to me.
> flutter at the moment is really just mobile only, so does Kivy
I can't parse that. I know for certain that kivy runs very well on desktop platforms.
I can't parse that. I know for certain that kivy runs very well on desktop platforms.
not really, it's more like running an apps on Desktop, you only have one window for example
You could also look at JavaFX. It's very modern but also has the sorts of controls you may need for complex apps.
This is a very good point, I think.
I would say for every product that is in a well defined category (like GUI toolkit) there is a default set of FAQ that an intro for it should answer. Maybe it would be a good idea to create an issue with a template of those FAQ, so other projects can use them as well.
I would say for every product that is in a well defined category (like GUI toolkit) there is a default set of FAQ that an intro for it should answer. Maybe it would be a good idea to create an issue with a template of those FAQ, so other projects can use them as well.
TIL: You can somehow collapse things in GitHub README files. Seriously why do I feel like a Markdown n00b all of a sudden. For those who don't know what I mean, click on any of the OS' listed under the 'How to install' section. I wish more README files on GitHub would sorta do this to some extent, some README's are just so bloated with too much noise, let's say it's nice for a FAQ section.
Anyway, back on topic: this is interesting, has anyone used GLFW for Go? What if I don't have a C or C++ compiler, how does Go handle C / C++ dependencies? Do you need everything required to build those too? I usually try to stick to things Go can compile in native Go as much as possible so I'm not familiar with this.
Anyway, back on topic: this is interesting, has anyone used GLFW for Go? What if I don't have a C or C++ compiler, how does Go handle C / C++ dependencies? Do you need everything required to build those too? I usually try to stick to things Go can compile in native Go as much as possible so I'm not familiar with this.
It's done via embedded HTML, which GitHub flavored markdown supports. I didn't know about the HTML details element, though. Pretty handy!
<details>
<summary>Click to expand</summary>
<div>Hidden until expanded, no JS or CSS required!</div>
</details>If it makes you feel better, I _invented_ `<details>` and didn't realize you could do that in markdown...
It also works in issue/PR descriptions and comments. As far as I'm concerned that's where it's most convenient as it lets you e.g. post big screenshots or graphical rendering of profiles (flamegraphs) without taking up screenfuls of space and bothering everybody.
The markdown in there looks like some horrible HTML / markdown hybrid. Yeah collapsing elements are cool if you’re viewing in a web browser but the point of markdown is that it’s supposed to look good in a plain text editor / terminal as it does when rendered and the raw version of that markdown file definitely isn’t.
Ultimately though I’m not going to complain that an open source developer has documented their free code in a way that differs from my own personal preferences. But before jumping on the bandwagon it’s worth thinking about whether you want your README to be readable as plain text as well.
Ultimately though I’m not going to complain that an open source developer has documented their free code in a way that differs from my own personal preferences. But before jumping on the bandwagon it’s worth thinking about whether you want your README to be readable as plain text as well.
You can use HTML in markdown, which is what was done here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
This also works for comments: https://github.com/dear-github/dear-github/issues/166#issuec...
I wish Flutter itself has been written in Go.
Actually, I've written an article a few days ago fantasising on how it could look like – "Thought Experiment: Flutter in Go"
https://divan.github.io/posts/flutter_go/
Actually, I've written an article a few days ago fantasising on how it could look like – "Thought Experiment: Flutter in Go"
https://divan.github.io/posts/flutter_go/
Looks cool but it ignores what Dart brings over everything else: Hot reload.
You can do hot reload for a long time with Java already. Go download TornadoFX and experiment with its hot reload functionality to see what you can do. This is definitely not a feature invented by Dart. From what I recall when I last looked at Dart/Flutter it doesn't have any new features not previously seen elsewhere.
Ah that feature I was using during the 90s for GUI development, but apparently was invented by Dart.
Anything mainstream with actual jobs attached, or some bizarro language that nobody used except for some research OS or something?
A variety of industrial Lisp-family languages (most notably including CL).
Smalltalk.
Erlang.
Elixir.
Ruby.
Java (limited in core JDK/OpenJDK, though there is third-party support for more complete hot swapping via DECVM and HotswapAgent).
Smalltalk.
Erlang.
Elixir.
Ruby.
Java (limited in core JDK/OpenJDK, though there is third-party support for more complete hot swapping via DECVM and HotswapAgent).
Common Lisp and Smalltalk had actual jobs attached during the 90's, and there are still people getting paid to use those systems on enterprise settings.
LispWorks, Allegro, Cincom, GemTalk are still in business.
LispWorks, Allegro, Cincom, GemTalk are still in business.
Yeah, I thought so.
Ah so for you Common Lisp and Smalltalk are bizarre languages, good to know.
Please don't be shy and let us know about all those amazing Flutter/Dart applications in production that outnumber any of those vendors, both in customer base and business value.
Other than Ad Words that is.
I start with a couple,
- Google's own ITA (CL)
- Siscog traffic management solutions used across European train networks (CL)
- JP Morgan financial risk management (Smalltalk)
Please don't be shy and let us know about all those amazing Flutter/Dart applications in production that outnumber any of those vendors, both in customer base and business value.
Other than Ad Words that is.
I start with a couple,
- Google's own ITA (CL)
- Siscog traffic management solutions used across European train networks (CL)
- JP Morgan financial risk management (Smalltalk)
>Ah so for you Common Lisp and Smalltalk are bizarre languages, good to know.
I like both of them, and they're historically important languages, but are not mainstream, and weren't mainstream even on their heyday.
I expected you to mean some post-Pascal Wirth-derived language though, or some other such project.
>Please don't be shy and let us know about all those amazing Flutter/Dart applications in production that outnumber any of those vendors, both in customer base and business value.
Well, Flutter 1.0 was just announced on Dec 2018 (so like a month ago) and the others had a 4+ decade headstart.
Still, some historical CL/Smalltalk apps aside (few enough to be enumerated in "success stories" style posts), in 2-3 years there will be more Flutter/Dart apps than CL and Smalltalk apps combined.
Heck, there are more Go apps in production "that outnumber any of those vendors, both in customer base and business value", and that went 1.0 less than 7 years ago.
If a language can enumerate it's success stories, it has already lost the popularity game. I've read the same "success stories" (and more) in Lisp forums and Smalltalk advocacy posts.
In fact, Dart before Flutter, was in the same boat "yeah, we use it in Google's ad management, and company X uses it for Y". But I have no doubt it will explode in popularity with Flutter.
I like both of them, and they're historically important languages, but are not mainstream, and weren't mainstream even on their heyday.
I expected you to mean some post-Pascal Wirth-derived language though, or some other such project.
>Please don't be shy and let us know about all those amazing Flutter/Dart applications in production that outnumber any of those vendors, both in customer base and business value.
Well, Flutter 1.0 was just announced on Dec 2018 (so like a month ago) and the others had a 4+ decade headstart.
Still, some historical CL/Smalltalk apps aside (few enough to be enumerated in "success stories" style posts), in 2-3 years there will be more Flutter/Dart apps than CL and Smalltalk apps combined.
Heck, there are more Go apps in production "that outnumber any of those vendors, both in customer base and business value", and that went 1.0 less than 7 years ago.
If a language can enumerate it's success stories, it has already lost the popularity game. I've read the same "success stories" (and more) in Lisp forums and Smalltalk advocacy posts.
In fact, Dart before Flutter, was in the same boat "yeah, we use it in Google's ad management, and company X uses it for Y". But I have no doubt it will explode in popularity with Flutter.
What were you using that supported hot reload?
Commercial Common Lisp and Smalltalk environments with student packages while at the university, before Java was announced to the world.
In a lot of Smalltalk environments, you could change the function's (method's) code in the debugger, referencing state to help follow what's going on, roll back enough stack frames to be safe, then continue. People built entire systems like that.
[deleted]
I wish it was written in Kotlin!
tbh I don't really care in what language is written, but I would really like to create Apps with Kotlin using Flutter instead of having to learn another language that it's (in my opinion) a bit inferior than the one I'm currently using.
I can see myself using flutter as a thin UI layer and just forget about the mess that Android UI layer is...
tbh I don't really care in what language is written, but I would really like to create Apps with Kotlin using Flutter instead of having to learn another language that it's (in my opinion) a bit inferior than the one I'm currently using.
I can see myself using flutter as a thin UI layer and just forget about the mess that Android UI layer is...
Kotlin is awesome and Dart is not as awesome but when you are like me and write C++, Java, and Fortran at work all day Dart still feels better than those.
Plus you never have to mess around with the Android UI layer...
Plus you never have to mess around with the Android UI layer...
Yeah, I prefer Dart + Flutter vs anything + Android UI layer...
But the library ecosystem of the JVM and Android specifics is just too big, it will take time for Dart and Flutter to have even a small part.
And also people with knowledge of the language and the ecosystem, it may be a bit risky to use Flutter right now.
I wish it was written language-agnostically, with bindings for everything, like libui.
Interesting. I think we really need a good cross-platform GUI development story. I wonder if Flutter will turn out to be it.
Does anyone know how Flutter fares when it comes to accessibility?
Does anyone know how Flutter fares when it comes to accessibility?
I have made a couple of applications with Flutter. Mainly for Android and iOS. I really think Flutter is great. It's my favourite framework currently. It feels like a modern Android SDK and frankly how the Android SDK should feel like. My "biggest" project currently is an alternative to the official NissanConnect EV app for controlling Nissan electric vehicles. You can find it here if you're interested; https://play.google.com/store/apps/details?id=dk.kjeldsen.ca...
It's also open source; https://gitlab.com/tobiaswkjeldsen/carwingsflutter
I think the Flutter team takes accessibility quite seriously; https://flutter.io/docs/development/accessibility-and-locali...
I think the Flutter team takes accessibility quite seriously; https://flutter.io/docs/development/accessibility-and-locali...
Are Toast and Dialogs using the native variants?
EditTexts feel different, but as a user I don't see much difference..
Great job! and props to you for making it open source
EditTexts feel different, but as a user I don't see much difference..
Great job! and props to you for making it open source
That looks really impressive. Well done.
Aren't there plenty of non-native-gui desktop options already? I think what we really need are cross platform gui options using native widgets (and we shouldn't pretend the impedance mismatch is too large because we've seen successful yet either license encumbered or language-unfriendly options before).
Pretty sure this has been attempted many times, and it never seems to work out well. One problem on Linux is that the native toolkits (Qt and GTK) are just garbage. Of course, creating a new toolkit is a huge, thankless endeavor and it requires quite a lot of experience with low level graphics programming, text rendering, accessibility, etc.
I think the web GUI stack is the only viable solution, but it can't be electron because of the redundant bulk--it will have to be something like ChromeOS: every program's GUI runs in its own "tab" (except tabs are laid out like windows); however, instead of pulling HTML/CSS/JS from remote servers, the servers would run as local daemons (it wouldn't really matter where the servers ran, to be honest; network transparency and all that).
I think the web GUI stack is the only viable solution, but it can't be electron because of the redundant bulk--it will have to be something like ChromeOS: every program's GUI runs in its own "tab" (except tabs are laid out like windows); however, instead of pulling HTML/CSS/JS from remote servers, the servers would run as local daemons (it wouldn't really matter where the servers ran, to be honest; network transparency and all that).
> One problem on Linux is that the native toolkits (Qt and GTK) are just garbage.
I think a lot of this stems from the fact that Linux (or BSD for that matter) don't really have a "native" toolkit.
Also, I think people overestimate the importance of using native widgets. Anecdotally I would say that only about half of the apps I use on a daily basis actually utilize the native toolkit. Microsoft Office, Adobe Reader, IntelliJ IDEA/Android Studio, Visual Studio Code, Chrome, and Firefox are great examples of very successful software that are not built using the native toolkit.
I think a lot of this stems from the fact that Linux (or BSD for that matter) don't really have a "native" toolkit.
Also, I think people overestimate the importance of using native widgets. Anecdotally I would say that only about half of the apps I use on a daily basis actually utilize the native toolkit. Microsoft Office, Adobe Reader, IntelliJ IDEA/Android Studio, Visual Studio Code, Chrome, and Firefox are great examples of very successful software that are not built using the native toolkit.
I think it's a little sad that we're now back to writing our own widget sets.
On Linux too, the toolkits of a handful of the applications I use are also, shall we say, "home made".
In fact, widgets in Windows have been theme-able since XP. Why couldn't that have been made more available?
On Linux too, the toolkits of a handful of the applications I use are also, shall we say, "home made".
In fact, widgets in Windows have been theme-able since XP. Why couldn't that have been made more available?
I think it's a positive development and a sign that GUI applications are now being treated seriously.
There's just no way that any generic widget set is going to 100% fill the needs of an easy-to-use, complicated GUI application. Nowadays when UI/UX actually matters in the success of software, it makes sense that developers are taking control of their UI's widgets. Cobbling together a GUI with a limited set of cookie-cutter widgets that are difficult to modify is no longer acceptable.
There's just no way that any generic widget set is going to 100% fill the needs of an easy-to-use, complicated GUI application. Nowadays when UI/UX actually matters in the success of software, it makes sense that developers are taking control of their UI's widgets. Cobbling together a GUI with a limited set of cookie-cutter widgets that are difficult to modify is no longer acceptable.
I think Qt does work well. Gtk isn't terrible either. WxWidgets, Iup, etc are also not bad. They just need either better cross language support (i.e. in C or with C iface) or better maintenance. I've had subpar performance with the more recently developed libui, but I have hopes there too.
You should check out JavaFX. It has a full set of cross platform widgets, can be styled with CSS, is hardware accelerated with Direct3D on Windows and OpenGL on Linux/Mac. You can do arbitrary 3D transforms of any part of the scene graph, but it also has sophisticated widgets like table views, tree views, CalendarFX, etc. There's a Material Design library for it called JFoenix. There's a visual GUI builder for it. It can play and stream hardware accelerated video. The entire toolkit is designed for reactive programming, there are libraries like ReactFX that go further and add the very latest and most advanced combinators. It's fully open source and developed on github.
It's really not that bad but the world seems to ignore it.
It's really not that bad but the world seems to ignore it.
> One problem on Linux is that the native toolkits (Qt and GTK) are just garbage.
I don't know how you get that. GTK needs more work, but Qt is spot on.
I don't know how you get that. GTK needs more work, but Qt is spot on.
> I don't know how you get that.
This is my opinion as a former Qt developer who dabbled in GTK in my spare time. Qt is all written in 90's C++ with all of the garbage that entails--awful memory management, CMake as a build system, no widely used package manager, shitty tools, etc. It's actually _worse_ than 90's C++ because it depends on a convoluted soup of preprocessor macros and a metaobject compiler in order to bolt onto C++ things like a dynamic type system and reflection. This means there's only one IDE that really understands it, and it was really buggy when I last used it (~2014). The one nice thing about Qt is QML, which is only nice to the extent that it removes or papers over the aforemetioned list of shitty Qt characteristics.
And GTK is strictly worse than Qt.
For all its issues, web development is nowhere near this bad--it's cheaper and easier for an organization to ship a bastardized browser alongside their web app than to build a Qt app.
This is my opinion as a former Qt developer who dabbled in GTK in my spare time. Qt is all written in 90's C++ with all of the garbage that entails--awful memory management, CMake as a build system, no widely used package manager, shitty tools, etc. It's actually _worse_ than 90's C++ because it depends on a convoluted soup of preprocessor macros and a metaobject compiler in order to bolt onto C++ things like a dynamic type system and reflection. This means there's only one IDE that really understands it, and it was really buggy when I last used it (~2014). The one nice thing about Qt is QML, which is only nice to the extent that it removes or papers over the aforemetioned list of shitty Qt characteristics.
And GTK is strictly worse than Qt.
For all its issues, web development is nowhere near this bad--it's cheaper and easier for an organization to ship a bastardized browser alongside their web app than to build a Qt app.
>Aren't there plenty of non-native-gui desktop options already?
No, and most of them are crap like Electron.
No, and most of them are crap like Electron.
> Does anyone know how Flutter fares when it comes to accessibility?
I believe one of the Dev sprints before 1.0 focused primarily on accessibility and there is a label widget that can wrap any widget to provide a name for screen readers.
I believe one of the Dev sprints before 1.0 focused primarily on accessibility and there is a label widget that can wrap any widget to provide a name for screen readers.
Why not Qt?
Qt's licensing can be a problem for certain platforms such as iOS. It is also quite bulky compared to Flutter. File sizes are mostly irrelevant on the desktop these days, but on mobile it still matters
I am confused. The readme says, "Disclaimer: Despite being very similar in the end goal, This project doesn't compete with this awesome one[1]."
But it is competing, isn't it?
[1] https://github.com/google/flutter-desktop-embedding
But it is competing, isn't it?
[1] https://github.com/google/flutter-desktop-embedding
I think the author is just saying that he doesn't care about the other project. He is probably having fun. Let him do his thang.
Hey that's cool, and I appreciate him acknowledging the other project. I would suggest being a little more direct with this and say, "Yes this project has the same goals as X, but I'm having fun and it scratches an itch I have, so I'm gonna keep going!"
I have the same impression.
Any idea why Flutter uses Dart language which is rather obscure. Wouldn't Java or JavaScript be the better choice in terms of adoption?
Flutter sits half-way between those two. It's more structured than JS with static types (and without all the JS oddities). It's also lighter syntax than Java with type inferencing and real first-class functions (and not everything has to be an object). The syntax is very familiar, so picking up the language is easy (Swift is syntactically quite similar).
Dart doesn't have the library issues like JS or the bloat like Java. In addition, Dart is an ECMA spec (like JS), so there are no copyright issues like with Java (other companies can even get committee members if they really wanted to invest in the language).
Dart was designed to prevent all the dynamic coding techniques that make JS slow (you can write very fast JS, but not in a normal style). Dart should be able to perform about as well as Java (it could beat Java on some benchmarks a few years ago).
https://www.nikolaybotev.com/blog/dart-vs-java-the-deltablue...
When you consider Java is multi-threading while the Dart implementations generally are not, performance is quite similar in the benchmark game too
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Off-topic, but for the pidigit test, Java just unloads all the work to a C lib. How is that a Java test? Any language will be "fast" if they are actually just leveraging highly-optimized C libs.
Dart doesn't have the library issues like JS or the bloat like Java. In addition, Dart is an ECMA spec (like JS), so there are no copyright issues like with Java (other companies can even get committee members if they really wanted to invest in the language).
Dart was designed to prevent all the dynamic coding techniques that make JS slow (you can write very fast JS, but not in a normal style). Dart should be able to perform about as well as Java (it could beat Java on some benchmarks a few years ago).
https://www.nikolaybotev.com/blog/dart-vs-java-the-deltablue...
When you consider Java is multi-threading while the Dart implementations generally are not, performance is quite similar in the benchmark game too
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Off-topic, but for the pidigit test, Java just unloads all the work to a C lib. How is that a Java test? Any language will be "fast" if they are actually just leveraging highly-optimized C libs.
"Some language implementations have arbitrary precision arithmetic built-in; some provide an arbitrary precision arithmetic library; some use a third-party library (GMP); some provide built-in arbitrary precision arithmetic by wrapping a third-party library."
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Re: Java / C usage: Generally I think this is a valid approach. Most languages use a C/C++ runtime for core data structures and abstractions. Go and Rust are notable exceptions. Ideally as a developer you are able to extend this core functionality in a seamless way. Python, Lua, JavaScript (the v8 implementation at least) and Java (JNI) are good examples where this is easily possible.
I agree completely for day-to-day use, but the benchmark game is specifically to test implementations. If you're offloading to C, then you're testing the C implementation and the FFI implementation instead of the language implementation. If you want to test those, then come up with a specific test for that.
> … testing the C implementation and the FFI implementation instead of the language implementation…
No, not "instead-of" but "as-well-as".
No, not "instead-of" but "as-well-as".
That all makes sense, but it's disappointing to see that Dart is no better than Java in type safety. Every type is nullable (the billion dollar mistake), and the type system is too weak to support mildly advanced data modeling without requiring heavy OOP.
Dart is a pain to work with. But to be honest, Flutter makes it worth putting up with.
Dart is a pain to work with. But to be honest, Flutter makes it worth putting up with.
Non-nullable types are in the works.
I'd love for Standard ML to become popular as it offers all the things in a pragmatic package. The ML languages (and their hindley-milner roots) have sat around for over 45 years without being adopted into the mainstream. At some point you have to admit that the world isn't ready for a great language yet and go with something that is a step in the right direction.
If I have to use a lowest-common-denominator language, I'll take Dart over Java any day. The syntax is better, first-class functions with closures are far superior to anything Java offers, decent type inference, etc are all steps closer to SML and make life easier.
I'd love for Standard ML to become popular as it offers all the things in a pragmatic package. The ML languages (and their hindley-milner roots) have sat around for over 45 years without being adopted into the mainstream. At some point you have to admit that the world isn't ready for a great language yet and go with something that is a step in the right direction.
If I have to use a lowest-common-denominator language, I'll take Dart over Java any day. The syntax is better, first-class functions with closures are far superior to anything Java offers, decent type inference, etc are all steps closer to SML and make life easier.
I'm not comparing Dart to an SML. If you want something to compare to, TypeScript is the pragmatic package you're looking for. It makes major steps in the right direction.
Are you comparing Dart with Java 8?
EDIT: somehow submitted half-way through typing.
Even comparing with Java 8, dart syntax is much better IMO. Java 8 type inference gets better, but still not as good (Java 10 looks to be getting closer).
Java 8 type inference gets better, but still not as good (Java 10 looks to be getting closer). Java lambdas are a joke compared to Dart. This stems from functions being first-class in Dart, but being second-class citizens in Java. Dart can handle a much more functional programming approach much more easily than Java.
Java closures only work with final variables while dart works with all enclosed variables. In Java, if I want a function to accept another function, I have to explicitly say that I accept a Lambda because Lambdas are special cases. With dart, I can accept any function that matches my expected types because functions are first-class. Another big difference is that Dart functions can be top-level. If I need a one-off function somewhere, I don't need to pack it in a class. I just make it and use it.
I also prefer Dart syntax because of things like private variables, implicit setters/getters, named parameters, async/await, no need for `new` keyword everywhere, implicit interfaces, generators, etc.
Even comparing with Java 8, dart syntax is much better IMO. Java 8 type inference gets better, but still not as good (Java 10 looks to be getting closer).
Java 8 type inference gets better, but still not as good (Java 10 looks to be getting closer). Java lambdas are a joke compared to Dart. This stems from functions being first-class in Dart, but being second-class citizens in Java. Dart can handle a much more functional programming approach much more easily than Java.
Java closures only work with final variables while dart works with all enclosed variables. In Java, if I want a function to accept another function, I have to explicitly say that I accept a Lambda because Lambdas are special cases. With dart, I can accept any function that matches my expected types because functions are first-class. Another big difference is that Dart functions can be top-level. If I need a one-off function somewhere, I don't need to pack it in a class. I just make it and use it.
I also prefer Dart syntax because of things like private variables, implicit setters/getters, named parameters, async/await, no need for `new` keyword everywhere, implicit interfaces, generators, etc.
Java 12 is about to be released....
And if we get started on supported OSes, available libraries, modelling tools, industrial vendor and IDE support, then it is a non-starter.
This putting aside that Kotlin, Scala, Common Lisp and Clojure are also options on the JVM.
And if we get started on supported OSes, available libraries, modelling tools, industrial vendor and IDE support, then it is a non-starter.
This putting aside that Kotlin, Scala, Common Lisp and Clojure are also options on the JVM.
[deleted]
They published an article elaborating why they went with Dart: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
You need to know Dart/Flutter's history to understand. For once Dart exists because JavaScript sucks(or at least it sucked more when Dart was released)
Because Dart allows static typing for speed (not just for checks), AOT compilation, and hot reload.
Java does the latter badly, and Javascript doesn't do static types and AOT (with the possible exception of someone's custom bizarro Rube Goldberg JS compiler).
It's also simpler than Java, saner than Javascript, and more under Google's vision and control than either.
Java does the latter badly, and Javascript doesn't do static types and AOT (with the possible exception of someone's custom bizarro Rube Goldberg JS compiler).
It's also simpler than Java, saner than Javascript, and more under Google's vision and control than either.
Last hope to make Dart relevant outside Google AdWords team.
Fuchsia also uses Flutter and Dart for the UI, but they are now playing with alternative UI engines and the Android team is adding support to run ART on top of Fucshia.
Fuchsia also uses Flutter and Dart for the UI, but they are now playing with alternative UI engines and the Android team is adding support to run ART on top of Fucshia.
I might be wrong, but I think Flutter was conceived during a time when Google was pushing hard for Dart. They even pushed for including native Dart support in browsers. Google probably still considers Dart highly relevant, especially since the upcoming Fuchsia OS seems to rely on Dart (and Flutter) for its apps.
Fuchsia devs appear to be now experimenting with alternative UIs, given the introduction of Scenic and an experimental Rust UI framework.
[deleted]
what does a "Custom Flutter Engine Embedder for desktop" mean ? I understand what Flutter does. I understand what an Engine and Desktop is. But I can't easily understand quite get the "". Is it a cross platform GUI toolkit/library using Flutter for golang as @christophilus is hinting ?
TL;DR - converts a mobile app written with flutter.io to desktop, including binary packaging.
From what i understand, it allows you to package your flutter application (android/ios framework using dart) as a standalone binary on windows/mac/linux.
From what i understand, it allows you to package your flutter application (android/ios framework using dart) as a standalone binary on windows/mac/linux.
What is everyone's take on the future of Flutter for Desktop? It's exciting to think that it could be a viable alternative to Electron or Qt but the fact that this is enabled entirely by third-party projects concerns me. Is Flutter for Desktop something that has a future? Will apps built with these tools be maintainable a year from now? At what point would you say it's safe to invest time building and deploying projects built with it?
I've tried them all.
- I don't want to return to C++
- I dislike javascript for large projects because even the best tooling is lacking, and the exploding dependency count.
- I love C#, but WPF renders worse than Electron (and Windows only).
- WinForms - mothballed.
- VB6/Delphi are EOL.
- UWP - Very lacking, will probably be abandoned.
- Java - I have no experience.
It will be a case of Flutter sucking less than the current options. Dart is actually a nice language, especially considering the runtime size - there's no framework overhead/bloat.
I imagine it to be Electron, but with a decent set of widgets and without the overhead.
Edit - to answer the main question:
Personally, I wouldn't develop anything more than a throw-away or personal project right now, but it's worth keeping an eye on it.
It would be nice to have a cross-device framework.
- I don't want to return to C++
- I dislike javascript for large projects because even the best tooling is lacking, and the exploding dependency count.
- I love C#, but WPF renders worse than Electron (and Windows only).
- WinForms - mothballed.
- VB6/Delphi are EOL.
- UWP - Very lacking, will probably be abandoned.
- Java - I have no experience.
It will be a case of Flutter sucking less than the current options. Dart is actually a nice language, especially considering the runtime size - there's no framework overhead/bloat.
I imagine it to be Electron, but with a decent set of widgets and without the overhead.
Edit - to answer the main question:
Personally, I wouldn't develop anything more than a throw-away or personal project right now, but it's worth keeping an eye on it.
It would be nice to have a cross-device framework.
Google is already experimenting with using flutter for desktop
https://github.com/google/flutter-desktop-embedding
They also took care to stress multiple times last year, even during Q&A, that only iOS and Android are their main focus.
Experimenting is the key word there. From the caveats section of their readme: "This is not an officially supported Google product." It's promising if they decide to officially support but it's dubious until then.
Apologies for the semi-off topic question and it’s not directed towards your project specifically, but why do Go projects always emphasise that they are Go projects? I never see announcements like “Foo, a C# library to do Bar”. That fact that it’s C# (or anythig else) will become apparent to anyone who cares to look at the source. With Go projects it’s always emphasized that they are written in it. Am I the only one who noticed this trend?
Having wasted far too many hours of my life dealing with complicated installation procedures, particularly with projects written in C and C++, and a few interpreted languages, knowing what language a project is written in is a huge selling feature for me.
While this is a feature not strictly limited to Go, Go applications on the whole have been very easy to install, so it piques my interest when I can have some confidence that using it is just a simple command away.
While this is a feature not strictly limited to Go, Go applications on the whole have been very easy to install, so it piques my interest when I can have some confidence that using it is just a simple command away.
Go is popular among open source developers, so announcing up front that the project is written in Go will attract more eyeballs and potential contributors.
If I'm going to contribute to an open source project in my free time, I'm more likely to contribute to a project if it is written in a language I enjoy working with.
If I'm going to contribute to an open source project in my free time, I'm more likely to contribute to a project if it is written in a language I enjoy working with.
New or niche languages always have their projects advertising their implementation language as a point of interest, basically as marketing for that language. You'll rarely see "In C" or "In Python" because those are just known-popular choices. (Not never of course, but rarely.) By contrast, I bet we're going to see a lot of "In Nim" in the next year.
Go's actually on the tail end of that right now; I've seen a number of things posted to HN that are just implemented in Go without saying so. Of course if you don't click through and look, you won't notice. :) But at this point, if I click through to a GitHub of some project and it's in Go, it's only mild surprise at best; it is most of the way to being just one of the default choices.
There's an even earlier version of this phase, which is when all the projects include the language in the name of the project, i.e., "gosql", "gobrowser", "punwithgo", etc. Go's been out of that one for long enough that I think it's kinda off when a new library has "go" in it unless there's a really good reason (for instance, development tools that really are about Go specifically and not just implemented in Go).
Go's actually on the tail end of that right now; I've seen a number of things posted to HN that are just implemented in Go without saying so. Of course if you don't click through and look, you won't notice. :) But at this point, if I click through to a GitHub of some project and it's in Go, it's only mild surprise at best; it is most of the way to being just one of the default choices.
There's an even earlier version of this phase, which is when all the projects include the language in the name of the project, i.e., "gosql", "gobrowser", "punwithgo", etc. Go's been out of that one for long enough that I think it's kinda off when a new library has "go" in it unless there's a really good reason (for instance, development tools that really are about Go specifically and not just implemented in Go).
A few reasons off the top of my head...
Go has very simple dependency management. A library written in Go generally needs very little environment management and will often integrate easily with a Go codebase. This is further enhanced with Go’s implicit inheritance model.
Go compiles to a static linked binary. A library written in Go usually can be static linked as well with no system dependencies.
Go has excellent cross platform support. Unless a library makes system calls (and sometimes even then), it will also be cross platform.
Go has a clean, simple, style. The lack of features like generics, operator overloading, and constructors means you can look at the code and instantly understand what it does. There is no spooky action at a distance because a variable declaration turns out to be a complex function call. This makes it much easier to understand the overall system impact of using libraries written in Go.
Applications and libraries written in Go build very quickly. My experience with other languages is that trying a substantial new package is a go-make-a-sandwich level of inconvenience. Go libraries usually are ready to use as soon as git clone finishes.
Go has very simple dependency management. A library written in Go generally needs very little environment management and will often integrate easily with a Go codebase. This is further enhanced with Go’s implicit inheritance model.
Go compiles to a static linked binary. A library written in Go usually can be static linked as well with no system dependencies.
Go has excellent cross platform support. Unless a library makes system calls (and sometimes even then), it will also be cross platform.
Go has a clean, simple, style. The lack of features like generics, operator overloading, and constructors means you can look at the code and instantly understand what it does. There is no spooky action at a distance because a variable declaration turns out to be a complex function call. This makes it much easier to understand the overall system impact of using libraries written in Go.
Applications and libraries written in Go build very quickly. My experience with other languages is that trying a substantial new package is a go-make-a-sandwich level of inconvenience. Go libraries usually are ready to use as soon as git clone finishes.
> Go compiles to a static linked binary.
By default. Go has supported dynamic linking for a while now.
By default. Go has supported dynamic linking for a while now.
I see it in the vast majority of languages I’ve used, use, or consider using—Go, Elixir, Python, Ruby, you name it.
I don’t think it’s much of a trend. It seems a practical thing to do to ensure your project can be found by others—it helps when you want your <thing> to be found when someone searches for “<language> library for <thing>” or “do <thing> in <language>”. For Go specifically, it often may be mentioned alongside “cross-platform”, a signifier that you can use it for such work and, I think, also to help when people search for that term when looking to do <thing>.
I don’t think it’s much of a trend. It seems a practical thing to do to ensure your project can be found by others—it helps when you want your <thing> to be found when someone searches for “<language> library for <thing>” or “do <thing> in <language>”. For Go specifically, it often may be mentioned alongside “cross-platform”, a signifier that you can use it for such work and, I think, also to help when people search for that term when looking to do <thing>.
For me it raises the question of weather it works with programs written in anything other than GO. My first thoughts were - hey I'm learning Rust and Flutter looks neat, will this allow me to use Flutter as a GUI for my rust apps? They say it's written in GO, so that must be relevant right? And it probably means it's meant for apps written in GO right?
It's an interesting line. I like the notion of apps I use being written in one of the more modern languages (GO or Rust) but it's not a core feature to a user. This means I can appreciate the language being mentioned but in a much less prominent way. If language isn't critical to a user or developer (of other things) IMO it shouldn't be so prominently mentioned.
It's an interesting line. I like the notion of apps I use being written in one of the more modern languages (GO or Rust) but it's not a core feature to a user. This means I can appreciate the language being mentioned but in a much less prominent way. If language isn't critical to a user or developer (of other things) IMO it shouldn't be so prominently mentioned.
Its usage in fact has nothing to do with Go or any other languages, Flutter is a framework for Dart and Dart only.
I think it's the best way to do it, to be honest. If I'm searching for a library in my preferred language to do X, wouldn't it be better if the website is really explicit about what it does and in which language?
Perhaps it's simply that there's still a little insecurity around writing an application in Go, and authors feel the need to justify it.
I think it's unwarranted, though.
I think it's unwarranted, though.
For me, an emphasis on Go indicates that I won't have problems with cross compilation and that I'll have a static binary to run. I'm more inclined to give a tool a try when I don't have to deal with language sandboxes.
For the same reasons as Rust, both are in the middle of their growth phase and mass adoption stages.
Didn't manage to get it running. Binaries crashed. Building from source was successful but the result crashed during runtime too.
Can I make a cross-platform GUI with it (a) in the current state, (b) maybe later? If so, what features does it support? How does it compare to Qt, Lazarus, Sciter, Elektron, etc? Does it have internal drag & drop? External drag & drop? Standard file and folder dialogs? Are widgets native or not (I suppose not, but it should be clear from a glance at the page)? Which widgets are supported? Does it have rich text support? Does it have OS-level clipboard support? Does it have transitions or not? Is it themeable? Is it fast? How large are executables built with it? Is it intended for ease of use or somewhat complicated? Do I need to write in other languages (HTML, markup, Javascript) to get things done or can everything be written directly in Go?
All of this is absolutely essential information. Nobody can reasonably decide whether to use this GUI toolkit or not without getting answers to all of the above question. So please, please explain in one sentence what Flutter is and make a section with keyword features.
[Please don't take this wrong, I'm not a naysayer. This is meant as a constructive criticism, not just of this page but of many similar ones. It sure looks like an interesting project.]