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

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

241–250 of 748 posts

Re: We're forking Flutter

#241

Post by kccqzy »

jonas21 wrote: post #206
devjab wrote: post #183

Earlier quoted context omitted.

I’m not sure what you mean by this but Python can be very performant when you want it to be. That is to say, when you build computation heavy parts in C (or Zig), and remember to avoid the various performance pitfalls like not using generators when you didn’t want to load all those millions of elements into your memory. What sets professional Python aside from most other programming languages is that everyone who use…

So, basically: Python is performant when you don't use Python?

Yes. Python is performant when all the performance-sensitive code is written as extension code.

Re: We're forking Flutter

#242

Post by epcoa »

dotancohen wrote: post #211
epcoa wrote: post #204

Earlier quoted context omitted.

What's a native UI? The only thing closeish to a native UI is macOS and iOS AppKit and UIKit. Winforms aka Win32 is still a thing, but Microsoft has been undogfooding that and putting out alternatives for years, now WinUI3 will definitely kill off Winforms for good! What is native on Linux? Gtk, Qt, Motif (lol)? And then Android? Ironic then that Google is the one behind Flutter. The concept of native outside of MacO…

I would consider both GTK and Qt native on Linux.

So that means one has to target both GTK and Qt to be native on Linux. Fat chance of that on anything but yet another music player or other relatively trivial UI app.

In any event, that still doesn't answer what it means to be "native"? And my point is I think most definitions are dumb or useless.

If I'm running a GTK desktop, Qt apps are generally not "native" no matter how much theme fuckery one tries. Native can also speak to other common UI affordances and design guidelines, and there sure as hell is nothing like there is in the MacOS world for linux. Some core GNOME and KDE desktop apps maybe, but overall there isn't much adopted standardization in Linux world.

90% of the work I get done involving a GUI outside a browser on Linux usually involves Java, whether it be Intellij, ghidra, etc. Maybe I'll pick up blender from time to time. Audacity, there's a good one, targeting (for now) a cross-platform toolkit that pretends you can have your cake and eat it too - wxWidgets never fooled anyone - they sure as hell don't look native on MacOS, and they invariably look much closer to what they riffed off of, a 90s MFC app. (And wxWidgets wraps GTK and AppKit, so is it native? If so, native is meaningless IMHO. If not, why not?)

Re: We're forking Flutter

#243

Post by eseidel »

irq-1 wrote: post #169
eseidel wrote: post #49

Earlier quoted context omitted.

Flutter Founder here. I'm very pro open-source, and pro taking-action, so hopefully good things will come out of it. I think this particular author is mostly stirring up a bunch of noise and does not represent a significant chunk of the community, but we'll see. :shrug:

> ...the Flutter team is in maintenance mode for 3 of its 6 supported platforms. Desktop is quite possibly the greatest untapped value for Flutter, but it's now mostly stagnant. Can you make any comment on this? Is it accurate?

I can no longer speak for the Google team (since I no longer lead it), but my understanding is that yes, Google is focusing their efforts on other platforms rather than Desktop (despite themselves using Flutter on Desktop for a variety of platforms). Canonical is contributing to the Desktop efforts substantially.

Re: We're forking Flutter

#245

Post by skywhopper »

munificent wrote: post #94
skywhopper wrote: post #77

Weird, I'd never heard of Flutter (or at least it never registered), but then I'm an infra engineer, so why would I have? But particularly strange is that if you go to flutter.dev, you'll notice you can't find anything about who Flutter is. There's no about page with links to the people behind it, or any indication of what company sponsors it. Then this flutterfoundation.dev site... weirdly also doesn't say who's beh…

> But particularly strange is that if you go to flutter.dev, you'll notice you can't find anything about who Flutter is. It's on the front page: "A Global Open Source Community. Supported by Google, open to everyone."

“Supported by Google” doesn’t communicate “owned by Google”, and anyway, marketing text in the middle of the page is not particularly telling. I expect a site about some technology to have an About page with some information about who is behind it and who funds it.

Compare https://go.dev/project which explicitly mentions that Google runs the show. The front page makes it clear that Google runs the language’s cloud infra. Plus there’s the Google logo in the footer.

The Flutter page never mentions who runs it. If it’s independent but sponsored by Google, there ought to still be people involved. If it’s owned by Google, it should be clear about it, and not just indirectly mention it.

Re: We're forking Flutter

#246

Post by toast0 »

EGreg wrote: post #191
fhdsgbbcaA wrote: post #187

Earlier quoted context omitted.

50 people is a pretty huge team at Google to start with, there’s teams of <5 that support weird bits of core infrastructure that serve billions of users an hour.

Exaggeration? Billions per HOUR seems quite a stretch there..

I believe it. I've never worked at Google, but I was the engineer for SMS/Voice registration at WhatsApp, ocassionally with one other engineer (I believe the team was 3 when I left, not sure if it grew); I think there were two engineers doing my job for Facebook; although they had a little bit more scope, since there were more kinds of SMS they sent. That doesn't have a huge request rate, but it is super important.

Something like DNS or BGP is going to have a tiny team and a huge impact. Load balancers probably has a bigger team, maybe 10-20 engineers, and almost everything goes through load balancers. And that's just the things that are easy to enumerate. I can think of lots of small teams when I was at Yahoo that worked on bits of software that are hard to explain, but were critical.

Re: We're forking Flutter

#248

Post by Degorath »

skybrian wrote: post #82

Back when I worked on GWT, we had trouble accepting outside contributions because the team had a mandate to support Googlers. That is, much like other libraries and tools at Google, changes could not break google3. This means testing patches against google3 and either changing the patch, or fixing whatever code used it, and these are tasks that no outsider can do. Shepherding these patches is no fun when you have you…

Couldn't flutter work as public-first that then gets vendored into third_party? Or is that literally the fork strategy you are talking about that I'm too dense to understand?
Post reply on HN