The alternatives for cross-platform GUI are
1. Electron
2. Frameworks like C++/Qt C/Gtk
3. Bindings to (2)
Using frameworks like Qt in native C++ sucks because C and C++ are just terrible languages for GUI development, even with the bolted on object systems and language extensions (Qt extends the C++ language).
Using bindings to those frameworks is nice in theory because you don't have to manually manage your own memory or use their type system, but in practice you still need to understand how their types bridge to your language's types and how their memory management bridges with your language's memory management (typically a GC). So while you're dealing with C types and manual memory management less frequently, when you do have to deal with it, it's more complicated than dealing with it in standard C/C++. So (3) is hardly better than (2).
Electron is probably the most cost-effective option, but it has its own problems (notably the high resource consumption that comes from bundling a whole web browser).
With those considerations in mind, learning a new high level language is the least of all problems, especially if the GUI framework is high-quality.
Though Qt Widgets in C++ isn't too bad if you use the designer instead of insisting on doing everything in code.
As someone developing GUIs with Qt bindings for Python daily, and has been for the past 8-9 years, I respectfully disagree.
Understanding of the underlying types and memory management is rarely an issue (e.g. once every 3 months), and when it is it's incredibly straightforward (e.g. maintaining reference to a window you've just created else Python garbage collects it for you).
Topics like these appear every now and then and remind me how there are still developers out there that still struggle to find the right combination of language and framework, some resorting to Electron because of assertions like this. This is a solved problem for my line of work - VFX and workflow related tools.
The styling system of qt is also quite limited. Their 'css' is a small set that does not work well on everything.
HTML+CSS allows for creating almost anything, it's the same on all platforms if the renderer is right. It's seperate from code and easily viewable and debuggable within a browser program. I have yet to see anything similiar with Qt, or a style heavy program like Discord made in Qt without becoming spaghetti.
But I also disagree that the styling is quite limited. Yeah, css in Qt is pretty limited, but creating a custom widget doesn't require all that much intimate knowledge (depending how custom we're talking). You can tweak the behavior of default widgets easily, you can draw a completely new one by painting and following the rules (for sizing, redrawing, etc). For new interaction models you'll need to be more familiar with the internals, but that's the case if you're stretching the limits of any framework.
Qt works really well for cross-platform apps that adhere to the OS' style and behavior. I think way too many apps waste time and frustrate users by reinventing the wheel. QML seems to be their approach to UIs untethered to the host OS (I don't have any experience) and seems to be their focus for the past handful of years. Their Qt (Widget) demos always show a bunch of cool features I rarely use, but I do pilfer their code for examples when I need something.
For a Discord like example; Maya, Nuke, and Houdini were all originally developed using their own UI toolkits and have migrated to Qt while maintaining each of their distinctive behaviors. They are all cross platform and require relatively low overhead and high performance with heavily customized UI behaviors.
Maya: https://damassets.autodesk.net/content/dam/autodesk/www/camp... Nuke: https://www.foundry.com/sites/default/files/styles/teaser/pu... Houdini: https://d2wvmrjymyrujw.cloudfront.net/media/uploads/products...
These apps did fork Qt5 when they moved from Qt4 to Qt5, but it was mostly Qt4 regressions and did it in a way intending to contribute their changes back into Qt mainline.
I see Electron devs being asked to match the slickness of an existing website with similar delivery time and productivity. You don't seem to be able to get close to that with native APIs, API frameworks, or higher-level tools without a lot of work. When you remove these UI and delivery requirements then almost all other frameworks seem to have a fighting chance.
The whole reason OSes give you reusable components is so its easy to implement the conventions users are familiar with. Those are the things that are supposed to be fast and easy.
This likely violates the delivery timelines, but Maya, Nuke, and Houdini are all professional, heavily customized apps that were written in their own UI toolkits but were ported years ago to Qt and are cross platform.
From my perspective as a user, Electron apps are for companies who don’t really care much about quality and are too cheap and lazy to write native apps. YMMV.
Ironically, Microsoft was one of the early adopters of the idea of "web technologies for desktop apps":
About a year ago I began work on Label LIVE, an Electron app to interface with thermal label printers. It’s not perfect but it fills a niche. It wouldn’t exist if it wasn’t for Electron. Check out the video or download and give it a try. http://label.live
[0]: https://bitbucket.org/chromiumembedded/java-cef
Jupyter Notebook does this.
What's the reason, lack of discoverability? I'd rather run one Chrome instance than a dozen apps that use varying versions of Electron.
The dependency on Chrome is a turnoff for people who don't already use Chrome. An Electron app just depends on the operating system (apparently), so the install is much like other desktop apps.
Is this part of what Microsoft is doing with Chrome being pre-installed (via Edge)? I can't find a source, but I heard that using the existing chrome on the machine would reduce disk size for applications and possibly even allow them to share memory.
PWA's are a sandboxed environment, where devs do not have control of browser version, cannot modify chromium, and cannot bundle necessary binary code. Even Spotify bundles in faster JSON parsers, and probably a number of other things.
An average user might not be able to connect the dots this way and realize what's going on with their machine. They'll just complain "my laptop is slow all the time and I don't know why". As developers, I feel like we have a responsibility to take better care of our users in this manner. Using a solution that will consume a GB or more of unshareable memory for something that doesn't need it (which is mostly everything) is a poor choice that puts the developer's needs (write-once-run-anywhere; faster, cheaper development time; fewer developers needed) over the user's.
So I fundamentally disagree that users only care that the app does the things they want, and nothing more.
[1] https://github.com/MGWL/QtE5
D's team is doing an incredible job of matching C++ compiler specific ABIs, name mangling/etc -- just so D users can use C++ libraries (including templates) directly from D without loosing the features of the language.
[2] https://dlang.org/spec/cpp_interface.html
Here is also an older video of Walter Bright (2015) talking about the challenges that D is tackling
It's a thing that solved a lot of very real problems that are still halfassed by NPM and Node ecosystem - package manager, build system, tooling around it - it was all a step above the quality of TypeScript/NPM/JS. Saner object semantics, good standard library, good tooling - it just got me to solving the problems I had. DOM wrappers it had were very nice, came with their own wrappers for Observable events (from standard library). They had proper async/await implementation working waay before TS.
Dart feels like a better TypeScript and for me the learning curve was really low.
One issue I had with it was using Dartium to debug the code - Chromium build that ran Dart VM naively to avoid transpiling to JS all the time - it was buggy as hell back then. Supposedly the dev compiler for JS is fast enough now that this isn't an issue - and in the case of Flutter you're running Dart natively so it's irrelevant.
I'm looking forward to doing a new project in Flutter this weekend - I've played with a hello world app when it was in beta and I was very impressed with the dev experience - hopefully it lives up to it in practice.
I’m with him, I want to like the idea, but I think the adoption has been slow and it doesn’t appear like it’s going to suddenly take off. I could be wrong, I just don’t see any successful indications yet.
It's apparently the primary language for Google Ads. As such, I expect it to be maintained as long as Google continues to sell ads and if they do move away from it you'll have plenty of warning.
https://itunes.apple.com/us/app/google-ads/id1037457231?mt=8
https://play.google.com/store/apps/details?id=com.google.and...
That said, Adwords used to be written in GWT. It's not impossible to migrate, but quite a big job.
Common Lisp was rarely used at Google when I was there, though it's a big company and you do see a little of everything, sometimes due to acquisitions. You might be thinking of ITA software, which is (was?) used for airline reservations.
How’s GWT looking these days?
That's Dart, not Flutter.
And even so, Dart transpiles to JS for the Google Ads. They could switch to plain JS, or Typescript, or even move to a whole new implementation of Google Ads, and pull the plug.
They also used to use GWT, did that hold on?
From my point of view learning Dart/Flutter isn't really a big investment so the downside of it getting abandoned soon is not as large as the payoff if it actually delivers - quality cross platform UI framework with great dev experience that I can use on my projects.
If this is true, and if the other rumors about Fuchsia replacing Android are also true, then I doubt Flutter and Dart are going anywhere.
Heck, from what you say, it already got bored with Android -- if Fucshia is to replace it in say 2022, it means that Android just lasted around 15 years as a platform.
I'm no big fan of Google, but 15 years is plenty long enough. And really, Android is definitely struggling and showing its age by this point.
This is what the comments above were alluding to, a "final release" before the project is abandoned. Installations still continue, in the same way there's probably places still doing the books on a C64, but it's no longer supported.
I have the opposite viewpoint on this. I've worked on mobile the last 5 years or so, and dedicated native Android the last 2.5 years. The last year or two have been dramatic revolutions in the Android developer experience, from my perspective. Things like ConstraintLayout and full Kotlin support with ktx have opened up a new world for me compared to the state of the art several years ago.
Then you look at companies like Peloton using large form-factor Android devices in their core products, and Samsung DEx using Android as a seamless mobile<->desktop computer.
To me it seems like Android is just hitting it's stride. Who knows though, it's Google.
I think it makes sense that it would go back to the drawing board and try to make something better from scratch.
Time will tell.
That's only if you use Typescript as a class-based OOP language. If you're more used to functional programming and prototypal inheritance, then Dart will bear no familiarity.
Due to its adherence to classical OOP, it feels way more like Java than Javascript.
As someone who never did any serious programing in those classical OOP languages, I struggled a lot to find the right abstractions to implement any kind of clean business logic. It was the first time I had to actually read up about "design patterns" and unironically consider writing factory factories.
It seems that due to Dart's rigidity and adherence to classical OOP, any library which needs to deviate from this paradigm has to hook into an additional build step (e.g. built_value for immutable types, has to use build_runner). That's an acceptable compromise for lib users, but adds a huge burden to actually writing those libraries, let alone incorporating those in your app's code.
You might need other design patterns, though.
But we also missed a lot of good stuff that we used to have.
Compare a 1980 compiler with the optimizations GCC and LLVM make.
Or v8 with the best interpreter in 1990.
Or video codecs (almost non existent then). Or cryptography code (immensely improved). Or the capabilities of InDesign compared to a 1990 DTP. Or Photoshop compared to crude editors in the 80s. Or modern GCs versus crude 80s and 90s GCs. Or a modern DAW compared to 1990s midi apps...
The coolest part was distribution. Under the File menu, you had an option to build a .exe file. I would build it and put the .exe file on 1.44 MB floppy disk, and share my little VB6 programs with friends. Such wonderful memories!
Most people just repeat Dijkstra's headlines without having even read his text, let alone understanding it.
I think we lost something important with the shift from workgroup to client/server (especially ODBC).
I banged out a lot of dBase II, FoxBASE, MS Access (in-house) apps, back in the day. I've not felt as productive since. I miss it dearly.
Unfortunately, in 2019 cross-platform compatibility for native apps has only gotten harder (good luck supporting windows, mac, linux, android, and ios), which is why people tend to default to making web apps (or hybrid solutions using frameworks like React Native) rather than native apps, and this has perhaps also created a vicious circle by reducing interest in what cross-platform options there are (QT and javaFX).
Not sure why people keep making the claim that native is dying. More and more people are doing their computing on their smartphones and the vast majority of the top 100 apps on both iOS and Android are built in Objective-C/Swift/Java/Kotlin. It seems to me like the main people pushing the whole web app/PWA renaissance are web developers who resent the fact that the web is dying.
Can you imagine trying to explain to a developer in 1995 what you need to use to produce an app feature equiv in 2019
Edit: Also the continued existence of null in new programming languages is a baffling choice to me.
Dart is objectively a terrible language to be productive in for app development. The abstractions provided by the language are clunky to use for window elements on a device screen. Don’t get me started on Material Design, either.
Swift, Objective-C/C++, or even Java is way easier to start building apps with, in comparison. The tooling is mediocre for Dart as well.
https://medium.com/@hinchman_amanda/null-pointer-references-...
https://www.infoq.com/presentations/Null-References-The-Bill...
https://www.quora.com/Why-was-the-Null-Pointer-Exception-in-...
https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...
entity = Entity.fetch(id)
if (!entity) doSomething()
Different languages solve this problem in different ways. Many languages get rid of null entirely, and use option types in its place. Other languages, like Kotlin, fix it in the type system, by differentiating between e.g. String and nullable String (spelled String? in Kotlin) .
In Kotlin, for example, you mark something with a question mark to say that it can be null, which forces you to check for null before using it:
val entityOrPossiblyNull: Entity? = Entity.fetch(id)
if (entityOrPossiblyNull == null) {
doSomething()
}
else {
// The compiler knows that the variable is not null in this branch,
// so this assignment is OK.
val entityForSure: Entity = entityOrPossiblyNull
doSomethingWithEntity(entityForSure)
}> functional features like sum types and pattern matching
"Functional features" means different things to different people. Dart (like most modern languages) has a lot of the core functional features: first-class functions, closures, lambdas, higher-order functions. Our built-in collection libraries are heavily oriented around functional-style transformations. You don't need an external library to map() and filter() your lists to your heart's content.
At the type system level, we also have function types, generic functions, and even first-class generic functions, which is a really unusual, powerful feature.
Sum types are a slightly different beast. Sum types are basically a functional language's answer to subtyping and runtime polymorphism. But object-oriented languages already have full subtyping and polymorphism using classes. There's a sort of zen koan here where algebraic datatypes are a poor man's subclasses and subclasses are a poor man's algebraic datatypes.
The way most multi-paradigm languages like Scala and Kotlin handle this is that sum types are just syntactic sugar for defining a little class hierarchy. Likewise, pattern-matching becomes syntax sugar for instanceof checks and field access. I like that sugar and hope we can add something similar to Dart, but I don't find it's omission to be a profound oversight. It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language.
> Dart just feels like the same sort of OO language we've been getting since Java became popular.
Yeah. The original designers of the language designed something very conservative. I think they wanted to make a VM with certain features (single dispatch, static class structure, no static initialization, etc.), and designed the safest language they could come up with to let them do that.
There is a lot of benefit to familiarity. I like classes and C-family syntax, and we see very clearly that Dart is really easy for people to learn and become productive in. We've done user studies where participants have been able to write correct Dart code without knowing what language they were using. It's hard to underestimate the value of that.
But there is also value in providing the modern tools people want in order to write clean, beautiful, correct, maintainable code. Dart has some catching up to do there. We're making a lot of progress. With Dart 2.0, we replaced the old unsound optional type system with a real, modern, expressive, sound static type system. It was a ton of work to do that while dealing with millions of lines of existing code.
We didn't get all the type system features we wanted, but we have a foundation we can build on now. The optional type system had some nice properties, but was effectively a dead end. When your types are optional, you can't hang any language semantics off them. That takes lots of features off the table: implicit conversions, extension methods, etc.
> Also the continued existence of null in new programming languages is a baffling choice to me.
I have always believed [0] that not having non-nullable types was a mistake in Dart 1.0. We are fixing it now:
https://github.com/dart-lang/language/blob/master/working/01...
There's a lot of work to do, but I'm really excited with the design. Unlike many other languages, we have something that becomes fully sound with respect to null errors. This means that once a program is fully migrated, a compiler will be able to take advantage of non-nullable types for performance optimizations. It will be quite a while before we get to the point where we can do this, but it's cool that that's on the table.
[0]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...
Sum types and exhaustive pattern matching aren't about expressiveness, they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes, and decreasing the cost of making changes by heavily reducing the amount of test code that needs to be written to make sure a closed set of options is handled appropiately; in OOP languages you can get this by using interfaces but to make use of it you'd have to use huge classes with methods pertaining to every usage of this closed set.
I would never willingly pick up another language that doesn't provide me with them after experiencing the productivity gains. I really like the direction Dart is moving towards and the steps taken demonstrate there's a team behind it that cares about correctness and productivity over being just a familiar Java-like, but this is the one hard blocker for me.
That's true for some kinds of code but not others. This is the classic Expression Problem [0]. For some things, it makes sense to keep all of the code for a single operation together. For others, it makes more sense to keep all of the code for a single datatype together. ML-style languages optimize for the former, and object-oriented languages optimize for the latter.
In practice, for the kinds of code Dart is designed for, the latter is a better fit most of the time. There's a reason OO and UI have been married together for decades.
Ideally, a language provides both styles so you can choose the one that fits your problem best. You see that now with languages like Scala. I hope we get there with Dart too.
I don't think it's fair to say that subclassing and method dispatch is objectively wrong just because it's a bad fit for some kinds of code. (Though, naturally, if it's a bad fit for the kind of code you need to write, then an OO language might be an objectively bad choice for you.) Class-based method dispatch is annoying for some things (God knows I've written enough Visitor pattern implementations over object-oriented AST class hierarchies), but it's really beautiful for others.
Being able to define a new widget class that bundles its rendering and interaction behavior together and can seamlessly extend a UI framework is something so natural that we take it for granted, but is very difficult to express in a language like SML. In fact, in order to do it, you'll probably end up doing a "design pattern" that reimplements something like v-tables at the application level.
[0]: http://journal.stuffwithstuff.com/2010/10/01/solving-the-exp...
I do however disagree on subclassing being the best fit for UI code. "The Elm architecture" as well as the model presented by React functional components with hooks offer sets of tradeoffs that I at least have found are better for most of the development I find myself doing when writing (and particularly when maintaining) regular business frontends.
People repeat this a lot, that OO goes with UI, but I don't think it's actually true, and I think e.g. React Hooks and immediate mode GUI in general demonstrate that it's not true. OO has been coupled with UI out of inertia, not because OO has unique strengths when applied to UI.
Sum types are a primitive language feature, akin to product types, which absolutely no one rejects the value of. The sum/product analogy to arithmetic is compelling to me: they are the building blocks of complex types and deserve recognition. I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!
It is evidentially true. Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages. It does work and it can't be that bad if that's continuing to happen even after the emergence of other alternatives.
Whether there are better ways is a good question, but I think it's pretty clear that you can ship good apps using OOP for your UI.
> React Hooks and immediate mode GUI in general demonstrate that it's not true.
I'm far enough into my career now — I've been doing UI programming of one form or another since the 90s — to have seen that pendulum swing several times. If there is a silver bullet, we haven't found it. It's probably not immediate mode GUIs because if it was, I wouldn't have seen game teams tear them out to replace them with something more retained several times in the 2000s.
What I think actually happens is that we forget the problems lurking in the solution we are not currently using. The grass over there gets greener and greener until we hop the fence and the cycle starts over. Incremental progress does happen. (I am not keen to revisit MFC any time soon.) But if a given concept (1) has been around a long time (2) has not already supplanted the alternatives, it's pretty unlikely that it is now an amazing solution today. The only time when that isn't true is when the surrounding technology context has changed since then.
For example, neural nets weren't a good solution for AI problems in the 80s because compute was too expensive and we didn't have a lot of data. Now that CPUs are cheap and everyone puts their entire life on the Internet, machine learning is here.
I haven't seen anything around UIs that to me looks like a significantly changed context, so I think we're still orbiting around retained-mode and immediate-mode as both having their own trade-offs and neither being a slam dunk.
> I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!
I really don't think that's true. Just look out there in the world. More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades. Heck, the software you are using right now to read this comment is sitting on a stack of several layers of subclass-based architectures! You've got JS running on top of the DOM inside a browser written in C++.
Sum types are really nice. But open-ended subclassing is too.
I just want to address these lines:
> Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages.
> More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades.
I agree that there's a huge amount of code out there using subclassing and not sum types. I'm not disputing the utility of subclassing; I just think the analogy to arithmetic is compelling, in that a closed sum type is a more primitive notion than open ended subclassing. It's easier to describe what a sum type is than what a subclass is; sum types have a smaller impact on a type system than subclassing. Pretty much any metric you can think of, sum types are just simpler, and more widely applicable. Any time you are describing a data structure, an ADT is immediately useful; subtyping may or may not be useful and is always more complicated. It's very difficult for me to understand how anyone could possibly say subtyping is on the same level as a basic operation like addition. Subclassing may or may not be nice but sum types are a primitive in a way that subclassing simply cannot be.
I don't know how to break it down more than this: we already have multiplication of types, and everyone accepts this as a primitive. Well, you can also do addition of types! Multiplication, addition, a neat little pair, just like algebra class[0]. Subclassing is way more complicated than this. That's it, that's a bullet proof argument as far as I'm concerned.
I suppose I do have an uncharitable opinion of mainstream programming languages, because I do think they've been getting this wrong for decades. It's nothing personal, it's just that industry has other concerns besides how clean their languages are. My browser being written in C++ is not an argument in favor of subclassing, though. You can build anything out of toothpicks if you're paid enough.
I agree, sum types have a real beautiful elegance. But I often wonder if that's some sort of "appeal to mathematical aesthetics" fallacy. When I see, for example, painters deciding what brushes to use, I don't see them choosing brushes whose diameter follows the Fibonacci sequence or something.
Simplicity is a virtue because it lowers the cognitive load of a language. I don't know if mapping something to arithmetic tells us something actually profound about the productivity of a language feature, even if it gives me a little shiver of delight when I think about it.
> Any time you are describing a data structure, an ADT is immediately useful
For what it's worth, I often run into problems where I think I can map something to a nice set of ADTs but then it ends up still having ugly corners. As elegant as the language feels, when I use them in practice my code is still awkward sometimes.
> It's very difficult for me to understand how anyone could possibly say subtyping is on the same level as basic operation like addition, one of them is clearly a more basic idea.
Subtyping is set theory, and sets are obviously more fundamental than arithmetic! :D
> we already have multiplication of types, and everyone accepts this as a primitive.
Well, actually, lots of languages don't have tuples and records/structs aren't simple product types.
> I suppose I do have an uncharitable opinion of mainstream programming languages
I wasn't talking about languages I was talking about people. There are languages out there with all of the features you describe. Yet millions of people are choosing other languages. You must have an uncharitable view of those people if you presume that all of them are making a choice that goes against their own self-interest to be happy productive programmers.
In case this wasn't clear, the "arithmetic" in question is being performed on sets (or types). For example, for sum types, the number of inhabitants of the type is the sum of the inhabitants of the components. All three of addition, multiplication and subtyping are operations on sets (types). So this was a strange thing to say.
> Simplicity is a virtue because it lowers the cognitive load of a language. I don't know if mapping something to arithmetic tells us something actually profound about the productivity of a language feature, even if it gives me a little shiver of delight when I think about it.
My real point is this: if you are deciding to build a language, as far as I'm concerned, it is very strange to add multiplication (why don't structs count as multiplication? I would say they do), then not add addition and instead add something much more complicated than addition. It just doesn't make any sense. It's not about the "productivity" (how do we measure this?) of the feature, it's about it not making any sense to do this! You add multiplication, you add addition, that's really all there is to it. I don't know, I guess I'm just repeating myself now and you won't find it convincing, but to me it's like trying to defend Roman numerals after being shown the Arabic system.
> You must have an uncharitable view of those people if you presume that all of them are making a choice that goes against their own self-interest to be happy productive programmers.
I don't think so at all. It's not really a fair choice; people choose languages in order to build things, and it's easier to build things in languages that other people are using. The full range of options is not obvious to every programmer (does the average webdev even know about ML?), and most of the time there are more important concerns than whether your language has a nice theory behind it.
For one imgui gains traction again, especially among game developers, simply as it gives a lot for the ease of compile, understanding, compactness of code, etc. You can really build complex tools out of it.
But there is one nasty elephnant - the state, and imgui's approach is to hide it somehow - it used be behind your __LINE__ (or __COUNTER__, stack.line in some langs), or maybe part of your label points to your data, and if you've had the bad luck of having same labeled names, then there is yet another workaround, something special hidden in there.
All in all, it seems like it's missing a language feature, and we are suddenly grasping on all kinds of tweaks to achieve that.
That, .. and layout.. Layout is damn hard in immediate language. It works by magic, and then your app might crash, and lock. No I'm not kiddin...
Then again I'm but a simple user of UI toolkits, never fully written one.
Compare that to Rust where compilation speed is almost as bad as C++, RLS is slower than e.g. Qt Creator's clang lints, and has auto-completions so innaccurate that they are almost worse than nothing.
Buuut.... I wanted to make a deep copy of an object (a map of maps) in Dart, and one of the suggestions on Stackoverflow is to serialise it to JSON and then deserialise it. Eek. In C++ you just do `auto a = b;`. In Rust `let a = b.clone();`. How do they leave out such basic functionality?
Sure, but does it do what you want? :) If that map contains pointers or other types with "interesting" assignment semantics, then your idea of a deep copy and that author of that type's idea may not be the same. Cloning is a surprisingly hard problem.
The two languages you compare to don't have GCs and prefer value semantics. But in most GC languages, everything is by reference and "copying the bits" isn't as meaningful of an operation.
I looked up how to deep clone maps in some other GC languages:
https://stackoverflow.com/questions/4157399/how-do-i-copy-a-...
Ruby: Top suggestion is to marhsall/unmarshall it.
https://stackoverflow.com/questions/5105517/deep-copy-of-a-d...
Python: Import a separate "copy" module. May have to implement some custom methods if you use user-defined objects in the map. The module isn't thread-safe. A comment recommends converting to JSON and back.
https://stackoverflow.com/questions/28288546/how-to-copy-has...
Java: No built in solution. Have to traverse the map yourself and do element-wise copies.
Definitely true that they may have done something weird, but I think the idea of a deep copy is pretty easy to define: It should not be possible to modify the original object using only the deep copy. (Note that this doesn't preclude copy-on-write, etc.)
I think it is quite weird that so few languages (even GC'd ones) provide a proper solution for this. It's clearly a thing people want to do.
I'm not sure I'd learn Dart apart from Flutter, but if you just treat it as part of learning the framework (think learning ruby along with rails, or Vue's random HTML-esque DSL, which people do), the overall learning curve is not high.
Dart is open source: https://github.com/dart-lang
It took me two minutes to find that using googles real proprietary technology..their search.
But this is true of so many widely used open source projects.
Literally nothing
Forks are nice for small patches or development teams with a plan, no one outside Google cares enough about Dart fwik.
I just started coding as if I was working with a version of Typescript.
I only Google from time to time for the standard library docs.
That was in fact the most pleasant things about Flutter for me, the language was a non-barrier.
There's not much of an ecosystem for multiplatform yet for desktop projects at all. For macOS you have a way of "making a framework you can use" and that's about it.
There is a lot of promise, though, in the mobile space: https://touchlab.co/touchlab-square-kotlin-multiplatform-col...
My sense is that as the mobile multiplatform space gets ironed out, the desktop space will benefit.
Though generally speaking, Kotlin/Native has a _much_ lower level of "institutional" risk, since the Kotlin approach doesn't subvert the control Apple or Microsoft have over their platforms. Flutter, on the other hand, seems to abstract it away.
Its also pretty slow compared with other native solutions.
If you want a debugger you need CLion, though. And the compiler is really, really slow – but they seem to be working on benchmarking things recently, so presumably it will be improved.
While Flutter doesn't work yet for desktop or web, ReactXP already works for these environments, and is used in the new Skype for Web.
Windows support is done and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper.
Check the IDE: (https://www.lazarus-ide.org/) and the cross-platform apps built with it: http://wiki.freepascal.org/Lazarus_Application_Gallery
... is this a comment from 1997 ? Qt is licensed under both GPLv3 and LGPLv3 - and Trolltech as a company hasn't existed for more than a decade...
And trolltech is very alive and publicly traded in fact. It has just been renamed to Qt company: https://en.wikipedia.org/wiki/The_Qt_Company
GTK+ and wxWidgets are other viable and popular choices for cross-platform desktop GUIs.
Besides Ad Words, there is very little being sold by Dart.
Plus how much money would it cost to replace all the existing software stack?
I can relate to this. While that's always been part of my motivation, there were other things in play too, like wanting to do something "better" than before. Or using new methods. Or applying X to Y just because. Now, as I get older, I don't want to deal with overly complicated shit, excessive dependencies, or unnecessary bling.
As an example in the GUI space I keep wondering why GTK 4 is getting a scene graph. I've done GFX programming for years and scene graphs are almost never the right answer. Why does a GUI toolkit even need one? No GUI should be that complex. No GUI toolkit should provide one for applications - that's not their job. Don't get me wrong, GTK is my preferred toolkit (in spite of gnome), I just think people keep extending things for the wrong reason. If it works and isn't broke, don't change anything. If the world changed and wants multi-touch, fine, add that. But don't go around doing your science experiments in projects that lots of other people use as infrastructure or building blocks.
Change is constant. Real progress is slow.
Interesting, why would you say that ? I saw a bunch of projects go from "more-or-less smooth at 1080p" to "buttery 120fps smooth at 4k" by migrating to UI toolkits with a scenegraph architecture.
If you have the time to spend to build an app, learning Dart to do it will be the less of your concerns.
Sure, maybe in production you want to use JSX and/or TypeScript, but learning a new language and a new framework together is overwhelming, period. Pedagogically, it makes it hard to conceptually separate what is a language feature and what is a framework feature. (To this day, I still have trouble separating what parts are Ruby and what parts are Rails.)
I love working with it more than any other languages I've worked with.
Python, Java, Go, Javascript, Lisp...
I think there's some combination between it being typesafe, amazingly expressive, dynamic and also productive because you're on the web platform.
Generics might be a bit much for some Javascript people because it's like a whole language in and of itself but it's worth it IMO.
Flutter is the best-designed framework I've encountered (whether mobile, front-end, back-end or machine learning).
The only downside is Dart, and while it's annoying, it's also very minor.
Few exceptions do exist, where several companies support out of there need and importance.
I think Fuchsia and Flutter are Google's primary likely plans for the future of their consumer platforms. I don't really know why, it's just a feeling.
A lot of it comes from Google planning 10+ years out a lot of the time. Reader was a mistake to kill, but you could see how Google management thought it would not be a widely useful product in the long-term future (though let's repeat, they were wrong).
I think Flutter+Fuchsia has that 10+ year plan to it. I'm on board with Dart because it seems likely to be a major ease on development along with a likely promising future.
As such, I'll pass since this feels like a dead-end just like polymer was. It felt like polymer had the same hype cycle as flutter - was going to make development so much easier/faster/less error prone etc. It is now a semi-abandoned legacy hulk of a project that people hate working with (anecdote I know, but that has been my experience) because its totally different and alien to how people are used to working, for no/little obvious benefit apart from "this is from google! its got to be good!"
I wish Google would just accept defeat and support existing common tools rather than suffering from "not-invented-here" syndrome and create something totally different and non-compatible, rather than contributing to the existing industry de facto standards to make them better. There may still be a few "google-scale problems", but UI frameworks and HTML libraries are not them.
[1] https://github.com/flutter/flutter/wiki/Desktop-shells#c-wra...
Not to mention that Google might be a bit sensitive to anything JVM / Oracle right now, given the lawsuit they lost.