Eich's own company, Brave, is pushing AI plenty hard: the Brave browser promotes a "smart AI assistant" called Leo. That's much more AI integration than I see in Firefox.
I don't speak for everybody but personally I like applications experimenting with ways of using new technology instead of taking some sort of political stand against AI. Firefox's translation extension is based on such technology I believe, and works well enough, I like it. Going further, like Brave is doing, also seems interesting. I think people who get upset about ineptly implemented AI features are being a bit unreasonable. It's new technology so people still have to. figure out what does or doesn't work. Mozilla using funds to develop new browser features is something I want more of, not less.
Experiment if you want. But leave it at that until it's polished. I shouldn't have alpha features forced on me as a default.That's the primary problem with this AI push. Google keeps trying to push "AI mode" in my face, Microsoft tries to stamp Copillot on my main Taskbar.
At least when Rider asked me about it, I say "no" once and that's the end of it.Cool, no hard feelings. You're $15 a month is earned.
Thanks for sharing that story! I love that your dream was to be the last line of defense protecting users from bad software. We need more of that, and it's sad that execs at Microsoft and others have made it harder.
Definitely some blame also belongs to the Xorg committer who reviewed and merged those changes (and it looks like that person understands that in retrospect). But the primary responsibility for getting a change right is the author's.
I haven’t seen a lot of discussion here of other existing apps moving to Flutter, which surprises me because my experience and my team’s has been so good — the performance, the quality of the code and documentation, and also our experience working with upstream. So I thought I’d share this here.
Happy to answer any questions people have about Flutter and our experience with it. I also plan to write a more detailed technical blog post in a couple of months.
That is in fact one of the new features in this 9.0 release! There's a new less-dense default, and the previous dense layout remains an option (which for myself I immediately turned on).
We're also planning to give a wider array of options in an upcoming release, including independently setting the line-height and the font size. It's a lot of work to get even two options to both have a reasonable layout throughout the UI, though (among other things, it involved changing a lot of hardcoded values in px to be in relative units), which is why only the two-way switch made it into this week's release.
Flow is not sound. They have the ambition of trying to be sound (which I appreciate), but they've never accomplished it.
I went looking for where on their website they claim to be sound. There's definitely some misleading wording here:
https://flow.org/en/docs/lang/types-and-expressions/#toc-sou...
but if you read the whole section, it ends up also acknowledging that it's not entirely sound.
That's true but misleading: if "any" and "unknown" were the only types, then "any" would be indistinguishable from "unknown" and you'd really have just the one type. Which makes the type system sound because it doesn't say anything.
If your type system has at least two types that aren't the same as each other, then adding "any" makes it unsound right there. The essence of "any" is that it lets you take a value of one type and pretend it's of any other type. Which is to say that "any" is basically the purified form of unsoundness.
Yeah, Flow had the ambition to be sound but has never accomplished it.
If you read the Flow codebase and its Git history, you can see that it's not for lack of trying, either — every couple of years there's an ambitious new engineer with a new plan for how to make it happen. But it's a real tough migration problem — it only works if they can provide a credible, appealing migration path to the other engineers across Facebook/Meta's giant JS codebase. Starting from a language like JS with all the dynamic tricks people use there, that's a tough job.
(And naturally it'd be even harder if they were trying to get any wider community to migrate, outside their own employer.)
Flow doesn't even check that array access is in-bounds, contrast to TypeScript with noUncheckedIndexedAccess on. They're clearly equally willing to make a few trade-offs for developer convenience (a position I entirely agree with FWIW)
Neat example, thanks! I hadn't known TS had that option. Array access was actually exactly the example that came to mind for me in a related discussion:
https://news.ycombinator.com/item?id=41076755
I wonder how widely used that option is. As I said in that other comment, it feels to me like the sort of thing that would produce errors all over the place, and would therefore be a real pain to migrate to. (It'd be just fine if the language semantics were that out-of-bounds array access throws, but that's not the semantics JS has.) I don't have a real empirical sense of that, though.
