Why would you care if the compiler supports AOT compilation unless it’s because the JIT compiler is just too slow? It doesn’t seem like an actual advantage, just a workaround for a disadvantage.
Edit: oh dear, and further down in the article they’re citing lack of multithreading as “a big advantage”. I don’t even.
You mean that as the time the JIT takes to compiler is too slow, or that the generated code is too slow? Either way, I can think of several reasons why one could prefer AOT over JIT (and vice versa):
Performing compiler optimizations takes time in an AOT you have more leeway to how many you can perform as they are not occurring at during the run-time of your application.
You can perform full program analysis.
JITs (usually) use heuristics to determine when to kick-in. This results in unpredictable performance.
It seems as a design decision more than a workaround for a disadvantage . Viewing it as the latter seems to imply that JITs are always better. (apologies if you didn’t intend to imply that).
If you read further, it’s not a lack of multithreading, it’s that they make sure their threads are isolated (calling out Erlang’s actors as an inspiration), and use message passing. This seems like a very good choice for UI code.
This article has sparked interest in trying out Dart for me. It seems to have beaten the odds that came against it a couple years ago (where it was kept alive by the Google Adwords team). The fast UI reload sounds like it could finally be the GUI framework that upends TCL in terms of easy usability.
The one thing that concerns me a little is the comparisons to Ruby. That bodes of messes down the line.
Totally - and another parallel with Erlang that also makes me want to try out Flutter is the hot reloading:
It is hard to appreciate how important really fast (and reliable) hot reload can be during development, unless you have experienced it yourself. Developers report that it changes the way they create their apps, describing it as being like painting their app to life.
Perfect description of how leaving Erlang gen_servers running and reloading changed module code live feels to me, especially when developing apps that have continuous data streams running through them. If Flutter can do that for mobile dev, keeping state present during dev so I could update code without the whole restart thing in RN, and then the whole thing compiles to native code for production, that ticks a whole lot of boxes for me. Only thing I wonder is about the simulator execution story, will have to read up more on that.
Just to circle back, I tried out Flutter using IntelliJ IDEA on Mac to check out the basics and see the hot-reload/simulator integration. It works pretty darn well.
Minor setup niggles (it is beta, so not unexpected): IDEA didn’t seem to be able to pull the Flutter/Dart install from my ${PATH} like it said it would, so I had to find the config place to set that. I installed Xcode on the machine specifically to try Flutter on, so although I’d accepted the license etc, when I initially tried to run the app in a simulator, it came up empty; after I ran Xcode once & restarted IDEA, an iPhone X simulator appeared in the dropdown, and it worked perfectly. I couldn’t really get the VS Code integration going at all, but it’s probably ‘cos I’ve never used VS Code before - that said, I’ve barely used IDEA either, so.
After running through just the getting started section, I found there are a few places where the MacOS versions of setup things aren’t documented that well (again, beta), and it seems that although there are a few “Cupertino” (iOS-style) widget implementations present already, the number lags heavily behind the Material Design widgets available.
In a sense this shouldn’t matter, except that it seems the way things are implemented is that you choose either a Material or Cupertino style, and then it renders that on whichever platform you target, because IIUC it’s not actually using native components, but has implemented Flutter/Dart widgets to look like them. Which I found pretty surprising(!). A few things I’ve read (inc. in the Flutter google group) suggest there’s a way to auto-select depending on platform, but if the number of iOS widgets is so greatly reduced compared to the Android ones, one wonders how well that’d play out. Apparently you can implement your own UI from the ground up too, but the first-glance tutorial stuff makes it seems heavily geared towards Material - e.g. in the Navigator module you can use the supplied MaterialPageRoute class to provided a navigation stack, but the auto-complete has no CupertinoPageRoute equivalent.
So there’s a lot more to investigate, but first impressions are good, model seems straightforward, and as long as you’re down with Material Design, it should make it straightforward to create reasonably involved interfaces even just using a lot of the pre-built widgets.
JIT compiled code will always have slow startup time. There’s no way to avoid that, since they need to compile code before executing it or interpreting it until the compiler is done.
JIT compiled code will always have slow startup time.
It’s true that on the JVM you need to be able to AOT-compile your code, because the JIT takes too long to warm up. But on LuaJIT that’s not the case, so it’s far from being a universal rule.
As much as anything, by having aggressively simple semantics, and having some interesting compile-time optimizations, like having every string literal pre-hashed for quick access in tables. Then for LuaJIT, optimizing those simple semantics to a hilt. There’s a lot more to it than just that, but Lua 5.0+ and LuaJIT are both fairly well-engineered.
I hate to be a curmudgeon, but this “article” seems like an ad. I think an article describing (in technical detail) what “Flutter” or “Dart” are, and how they work, would be more in line with lobsters. Most of the words here are attempting to persuade me that I want to know more about these two things, without actually explaining either of them.
Why would you care if the compiler supports AOT compilation unless it’s because the JIT compiler is just too slow? It doesn’t seem like an actual advantage, just a workaround for a disadvantage.
Edit: oh dear, and further down in the article they’re citing lack of multithreading as “a big advantage”. I don’t even.
You mean that as the time the JIT takes to compiler is too slow, or that the generated code is too slow? Either way, I can think of several reasons why one could prefer AOT over JIT (and vice versa):
It seems as a design decision more than a workaround for a disadvantage . Viewing it as the latter seems to imply that JITs are always better. (apologies if you didn’t intend to imply that).
You can’t ship a JIT on iOS. And Dart’s combination of shared nothing threads with async/await makes for a pretty nice experience.
It’s more general than JITs; you don’t get to mark pages as executable.
(You are probably aware, just expounding in case someone doesn’t know what it’s about.)
If you read further, it’s not a lack of multithreading, it’s that they make sure their threads are isolated (calling out Erlang’s actors as an inspiration), and use message passing. This seems like a very good choice for UI code.
This article has sparked interest in trying out Dart for me. It seems to have beaten the odds that came against it a couple years ago (where it was kept alive by the Google Adwords team). The fast UI reload sounds like it could finally be the GUI framework that upends TCL in terms of easy usability.
The one thing that concerns me a little is the comparisons to Ruby. That bodes of messes down the line.
Totally - and another parallel with Erlang that also makes me want to try out Flutter is the hot reloading:
Perfect description of how leaving Erlang
gen_servers running and reloading changed module code live feels to me, especially when developing apps that have continuous data streams running through them. If Flutter can do that for mobile dev, keeping state present during dev so I could update code without the whole restart thing in RN, and then the whole thing compiles to native code for production, that ticks a whole lot of boxes for me. Only thing I wonder is about the simulator execution story, will have to read up more on that.Just to circle back, I tried out Flutter using IntelliJ IDEA on Mac to check out the basics and see the hot-reload/simulator integration. It works pretty darn well.
Minor setup niggles (it is beta, so not unexpected): IDEA didn’t seem to be able to pull the Flutter/Dart install from my
${PATH}like it said it would, so I had to find the config place to set that. I installed Xcode on the machine specifically to try Flutter on, so although I’d accepted the license etc, when I initially tried to run the app in a simulator, it came up empty; after I ran Xcode once & restarted IDEA, an iPhone X simulator appeared in the dropdown, and it worked perfectly. I couldn’t really get the VS Code integration going at all, but it’s probably ‘cos I’ve never used VS Code before - that said, I’ve barely used IDEA either, so.After running through just the getting started section, I found there are a few places where the MacOS versions of setup things aren’t documented that well (again, beta), and it seems that although there are a few “Cupertino” (iOS-style) widget implementations present already, the number lags heavily behind the Material Design widgets available.
In a sense this shouldn’t matter, except that it seems the way things are implemented is that you choose either a Material or Cupertino style, and then it renders that on whichever platform you target, because IIUC it’s not actually using native components, but has implemented Flutter/Dart widgets to look like them. Which I found pretty surprising(!). A few things I’ve read (inc. in the Flutter google group) suggest there’s a way to auto-select depending on platform, but if the number of iOS widgets is so greatly reduced compared to the Android ones, one wonders how well that’d play out. Apparently you can implement your own UI from the ground up too, but the first-glance tutorial stuff makes it seems heavily geared towards Material - e.g. in the
Navigatormodule you can use the suppliedMaterialPageRouteclass to provided a navigation stack, but the auto-complete has noCupertinoPageRouteequivalent.So there’s a lot more to investigate, but first impressions are good, model seems straightforward, and as long as you’re down with Material Design, it should make it straightforward to create reasonably involved interfaces even just using a lot of the pre-built widgets.
JIT compiled code will always have slow startup time. There’s no way to avoid that, since they need to compile code before executing it or interpreting it until the compiler is done.
It’s true that on the JVM you need to be able to AOT-compile your code, because the JIT takes too long to warm up. But on LuaJIT that’s not the case, so it’s far from being a universal rule.
Wow, you are right, the Lua VM is bloody fast! I wonder what they did to accomplish that!
As much as anything, by having aggressively simple semantics, and having some interesting compile-time optimizations, like having every string literal pre-hashed for quick access in tables. Then for LuaJIT, optimizing those simple semantics to a hilt. There’s a lot more to it than just that, but Lua 5.0+ and LuaJIT are both fairly well-engineered.
I hate to be a curmudgeon, but this “article” seems like an ad. I think an article describing (in technical detail) what “Flutter” or “Dart” are, and how they work, would be more in line with lobsters. Most of the words here are attempting to persuade me that I want to know more about these two things, without actually explaining either of them.