Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter 2

developers.googleblog.com

Post reply on HN
Print view View original

731–740 of 780 posts

Re: Flutter 2

#731

Post by hajile »

munificent wrote: post #570
kroltan wrote: post #473

Earlier quoted context omitted.

Fair enough, that is a meritable goal. Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too) I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.

> Have you considered not going full-on structural-typing but still providing some sort of union? I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS. The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebr…

Any idea when dart will get tuples (and maybe immutable structs)?

Re: Flutter 2

#732

Post by silisili »

mraleph wrote: post #719
axaxs wrote: post #118

Earlier quoted context omitted.

Eh, it's a little murky. I was playing with dart a little. It can in fact create a single binary, but it looks like it's just putting the interpreter with the code. I say that because if you strip or pack the binary, instead of working it shows the output of running dart with no arguments.

[I work on Dart VM team] `dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code. The approach is not pretty but was chosen as an implementation shortcut. That's why `strip` does not actually do good things to the binary. There is no reason to run `strip` on such binaries - becaus…

Thanks. Also noting that upx has the same behavior.

I didn't inspect the binaries, just try to see how/if they compress.

Re: Flutter 2

#733

Post by dep_b »

distances wrote: post #418
ignoramous wrote: post #231

Earlier quoted context omitted.

Thanks. Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress. And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply…

Android development is like that; you hit a framework bug, you'll expect it will never get fixed. Just find a workaround and accept it's what it is.

At least with iOS you know it will take three years for something to come out of beta but then it's pretty solid. It's just Xcode that never gets fixed.

Re: Flutter 2

#734

Post by rubicon33 »

eseidelGoogle wrote: post #392
rubicon33 wrote: post #285

Earlier quoted context omitted.

Flutter used to be such a great experience, but something happened ~6 months ago that totally derailed it. It brings my late 2016 MBP to a crawl if I am building on iOS simulator. After reading online about it being related to Metal, and needing to switch flutter channels, trying that, and still seeing no success... I just gave up on Flutter (for now). Maybe Flutter 2 has resolved this?

[Flutter Eng. Dir here] I would love to learn more about your experience. Would you be willing to file an issue and either post it here or CC me on it? flutter.dev/support

This closed issue from 2018 appears to be the same issue I was experiencing in ~mid 2020.

FWIW, I was also using Rive animations in my app.

https://github.com/flutter/flutter/issues/21445

Re: Flutter 2

#735

Post by mdoms »

EvilEy3 wrote: post #646
mdoms wrote: post #529

Earlier quoted context omitted.

I don't know what that is but I assume it's some kind of American nonsense I don't care at all about.

Accessibility is American nonsense?

You think the word "accessibility" is the part that I had not heard of?

Re: Flutter 2

#736

Post by igouy »

mda wrote: post #640
danielscrubs wrote: post #625

Earlier quoted context omitted.

Here are some benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The Dart implementation seems much slower than the NodeJs implementation and it doesn’t bring anything new to the table? It added null safety today. Anyone that knows if it has any feature beyond for example what Ocaml has?

Uuh the benchmarks in this site is very misleading (for all languages). Do your own tests otherwise the numbers there are practically meaningless.

Yes, when others have not written the programs you would like to compare — write your own programs to compare.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

How programs are written does matter.

Re: Flutter 2

#737

Post by igouy »

mda wrote: post #689
danielscrubs wrote: post #625

Earlier quoted context omitted.

Here are some benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The Dart implementation seems much slower than the NodeJs implementation and it doesn’t bring anything new to the table? It added null safety today. Anyone that knows if it has any feature beyond for example what Ocaml has?

To give context, the implementations for the same problem are completely different, e.g. javascript versions uses worker thrreads on 4 cores for most of the examples. To compare actual performance first similar approaches should be used.

> worker thrreads on 4 cores

So how different are the "busy" measurements?

To understand actual performance first understand what approaches were used.

Re: Flutter 2

#738

Post by munificent »

c-cube wrote: post #639
munificent wrote: post #571

Earlier quoted context omitted.

Yes, union types are really nice for data like that. But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types). In a language that is built more strongly on objects and stat…

People build less unions because these languages fail them. Just add sum types or something similar, it's a disgrace to not have them in 2021. Static typing goes wonderfully well with them, allowing for exhaustiveness checks and all that. The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.

> Just add sum types or something similar

I think you're confusing union types and sum types, which are very distinct features. SML, Haskell, and Rust don't have union types.

OOP languages can model sum types already. It's mostly a question of how much the surface syntax encourages that style.

Re: Flutter 2

#739

Post by munificent »

hajile wrote: post #731
munificent wrote: post #570

Earlier quoted context omitted.

> Have you considered not going full-on structural-typing but still providing some sort of union? I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS. The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebr…

Any idea when dart will get tuples (and maybe immutable structs)?

No time frame, sorry. We generally don't make promises about future dates because schedules tend to be flexible and picking dates just sets people up for disappointment.

Re: Flutter 2

#740

Post by vially »

yesimahuman wrote: post #528
vially wrote: post #515

Earlier quoted context omitted.

I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves. Some examples from the top of my head: - various performance issues (e.g.: memory leaks which haven't been fixed for years [1]) - their push/pop router navigation seems like a rea…

This heavily depends on the framework you choose to use, and modern Ionic uses the stock tooling your framework does, so build times should be on par with any other project of that framework type. Earlier versions of Ionic had custom tooling and much slower build times.

This was happening in an Ionic 4 project which was already using the stock tooling of the framework (Angular CLI). But I remember it being worse in Ionic 3 with its custom tooling, so overall things do seem to be improving with time.

My findings at that time (it was a while ago) seem to match exactly the slowdowns described in this issue [1]. Just importing the IonicModule in a new Angular project (without actually using any Ionic component) made the dev server build times jump from around 200 ms to a couple of seconds. And the situation only seemed to get worse as more Ionic features were being added to the app.

Just to make it clear, I understand that this is an open-source project and I don't expect anyone to fix my issues. And I'm also very grateful to you and the Ionic team for giving us Capacitor which is such a big improvement from Cordova.

So I don't like being all negative in here. But I did encounter a fair share of issues with Ionic and I'm only sharing my experience here as just another data-point in case it helps someone make a well-informed decision.

And I have to say, the overwhelmingly positive reaction to Ionic in general did make me question my own abilities several times. Maybe I just don't "get it". I still haven't ruled that out as a possibility.

[1] - https://github.com/ionic-team/ionic-framework/issues/17902

Post reply on HN