price

I'm not sure I ultimately buy that Dropbox is expensive - for one thing, Notion now charges basically the same as Dropbox, and you don't even get file sync in the deal.

I can definitely believe that that was an objection customers had, though. I just suspect that what it really meant was another way of expressing that there wasn't PMF - if the PMF were there, they'd have willingly paid, just like they do now for Notion or Slab or what have you.

And yeah, there was definitely some energy going into trying to tie the products together more (putting Paper docs in your Dropbox folders) - and when that finally shipped it sadly made the Paper experience worse, not better.

Yeah, when signing into Paper it always felt pretty silly how the auth flow was all like "are you sure you want to share your Dropbox account info with this Paper thing?" as if it was some third-party service.

Ironically, just within the last year Paper has gotten much more integrated into Dropbox as a single UX. And… it's significantly worse: slower, clumsier, harder to navigate. (I don't think there's any inherent reason those had to be correlated; it's just that Paper has clearly been destaffed a lot in recent years, so naturally any new changes will tend to be less polished.)

And they had Paper, which was an excellent product (I was at Dropbox a decade ago; we all used Paper constantly and it was great) very close to what Notion later became. They never got it over the hump to wider PMF — like you say, a failure of product and of enterprise execution.

(Given that it was so close to Notion, I think Paper is one area where the product vision was on to something good; but they didn't succeed at product execution, connecting customer feedback to iterating correctly on product improvements.)

I think the gp is saying that out of those millions of total Discord servers, there are >10k of them that each have >10k users.

In other words there are >10k large servers, in addition to the much larger number of smaller servers.

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.

The timezone is UTC+7. That's in Asia, two hours from Japan time. That's why the staff member making the reply brought it up:

> My timezone is UTC+7, so it should be easier for us to set up time.

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.

They're reverting this developer's previous changes, because those changes were bad.

More on those previous changes here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797#no...

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.

Heh, well, I'll take that as a vote for prioritizing that feature. :) (It's in our tracker already: https://github.com/zulip/zulip-flutter/issues/419)

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.

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.

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.

Yeah. The iteration speed with Flutter's fast, solid, hot reload is seriously a big deal for the developer experience.

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.

Definitely to get the most ergonomic programming experience, while also having a sound type system, you'd need to change some of the semantics of the language.

A prime example is that if you index into an array of type `T[]`, JS semantics mean the value you get back could be undefined as well as a `T`. So to describe existing JS semantics in a sound type system, the type would have to be `T | undefined`, which would be a big pain. Alternatively you could make the type `T`, but only if you make the runtime semantics be that an out-of-bounds access throws instead of returning undefined.

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.)

There's nothing arcane or particularly theoretical about soundness. It means that if you have an expression of some type, and at runtime the expression evaluates to a value, the value will always be of that type.

For example if you have a Java expression of type MyClass, and it gets evaluated, then it must either throw (so that it doesn't produce any value) or produce a value of type MyClass: either an instance of MyClass, or of one of its subclasses, or null. It will never produce an instance of some other class, or an int, or anything else that isn't a valid value for the type MyClass.

In addition to helping human readers reason about the code, a sound type system is a big deal for a compiler: it makes it possible to compile the code AOT to fast native code, without inserting a bunch of runtime checks and dynamic dispatching to handle the fact that inevitably some of the types (but you don't know which) are wrong.

The compiler implications are what motivated the Dart language's developers to migrate from an unsound to a sound type system a few years ago: https://dart.dev/language/type-system#the-benefits-of-soundn... so that they could compile Flutter apps AOT. This didn't require anyone to make their code resemble what you'd do in a theorem prover — it just means that, for example, all casts are checked, so that they throw if the value doesn't turn out to have the type the cast wants to return.

TypeScript is unsound because when you have an expression with a type, that tells you nothing at all for sure about what the value of the expression can be — it might be of that type, or it might be anything else. It's still valuable because you can maintain a codebase where the types are mostly accurate, and that's enough to help a lot in reading and maintaining the code.

When a language's type system is sound, that means that if you have an expression with type "string", then when you run the program the expression's value will only ever be a string and never some other sort of value.

Or stated more abstractly: if an expression has type T, and at runtime the expression evaluates to a value v, then v has type T.

The language can still have runtime errors, like if you try to access an array out of bounds. The key is that such operations have to give an error — like by throwing, so that the expression doesn't evaluate to any value at all — rather than returning a value that doesn't fit the type.

Both TypeScript and Flow are unsound, because an expression with type "string" can always turn out to evaluate to null or a number or an object or anything else. Flow had the ambition to be sound, which is honorable but they never accomplished it. TypeScript announced up front that they didn't care about soundness: https://www.typescriptlang.org/docs/handbook/type-compatibil...

Soundness is valuable because it makes it possible to look at the types and reason about the program using them. An unsound type-checker like TypeScript or Flow can still be very useful to human readers if most of the types in a codebase are accurate, but you always have to keep that asterisk in the back of your head.

One very concrete consequence of soundness that it makes it possible to compile the code to fast native code. That's what motivated Dart a few years ago to migrate from an unsound type system to a sound one: https://dart.dev/language/type-system so that it could AOT-compile Flutter apps for speed.

One of the things that's made us at Zulip very happy with Flutter is that it's an honest-to-goodness functioning open-source project. The issue tracker is out in the open, as are the PRs and code reviews. You can (and we did) show up with bug reports and someone whose job is to develop Flutter will read it and make a cogent reply. And getting a change merged in Flutter is however easy or hard it is to do the change well, but no harder — the codebase is high-quality, and the maintainers are responsive. It's at quite a high percentile among all the open-source projects I've interacted with.

I don't know much about Kotlin Multiplatform or Compose Multiplatform. But from what I've seen, the Android group in general doesn't live up to that high standard as an open-source project. You can report bugs and might get a reply, but can't really participate in the discussion; the public bug often gets linked to a bunch of internal bugs you can't see, and the code reviews for any fix happen in private.

(I lead the Zulip mobile team, so the decision to use Flutter was primarily mine.)

Zulip | Senior Flutter Engineer | REMOTE or San Francisco | Full-time | https://zulip.com/

At Zulip, we're out to build the world's best collaboration platform, and we're committed to keeping it 100% open source. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations. Our product serves as the communication hub for businesses, open-source projects, educators, and communities around the world.

We're building the next generation of Zulip's mobile apps in Flutter. We're looking for a senior engineer with Flutter experience to join our small core team and help define the future of team chat. Our Flutter prototype is just a few months old, so this is a greenfield opportunity to help shape the app's architecture from early on.

For full details, check out https://zulip.com/jobs/. Apply at [email protected].

Interesting! Thanks for tracking down that bit of history.

Interesting.

My perception in 2014 was right in line with the way it's told in that 2015 article: that this was a new and clever UI twist, one that I hadn't seen before and that many people in the industry were copying after seeing it in Mailbox. That was as an engineer in San Francisco, talking with designers and product folks and people much more plugged in to industry gossip than me - so I think that means it truly had not previously existed in the mobile apps (really, the iPhone apps) that people here who were connected were paying attention to.

It sounds like Palm had the feature years earlier. Maybe the Mailbox folks got the idea from there! In any case I think they did succeed in bringing the feature to a lot more users, by making it something that people in the industry widely knew about and copied.

That was in fact Dropbox's plan circa 2013-2014. (I worked there 2014-2017.) In fact they had email too: Mailbox, a mobile mail client with some brilliant product ideas, which marked the start of the acquisitions spree that included Zulip as well as Hackpad (which became Paper) and many small others.

It didn't work out. Some of the reasons are in this Casey Newton article: https://www.theverge.com/2015/12/8/9873268/why-dropbox-mailb...

A comment there on LWN, from a Debian developer, adds useful context:

> [T]his is a misleading writeup of a Debian-internal announcement. One specific action that is mostly internal to Debian, which some developers wanted to push ahead with after the bookworm release, has been paused.

> On a merged-/usr system (which will include all Debian 12 and Debian 13 systems, both new installations and upgrades), both /bin/cat and /usr/bin/cat exist, but dpkg is only aware of one of those paths (/bin/cat in this case); in dpkg jargon, the other is said to be an alias. The specific action that should not proceed until further notice is: swapping the path that dpkg considers to be canonical, for example from /bin/cat to /usr/bin/cat.

In particular, the thing that this announcement pauses is only a shuffling of internal metadata. For users, /usr will already look merged either way.

The other bit of context is that this "pause" comes as Debian approaches its next major release, and they expect to unpause it shortly after that.

No; read the decision, or Reddit's filing. Three of these seven users did talk about RCN. Reddit defended their privacy too.

No, some certainly were. There's one quoted in the blog post, for example.

In a small community, and if you're not using it for lots of chit-chat but rather for something focused like scientific research, you can go years and years without reaching 10k messages. So in that circumstance, it's pretty reasonable to have chosen Slack under its old policy. Especially if one wasn't aware of Zulip. ;-)

(I'm one of the Zulip developers.)

Zulip | Senior Mobile Engineer | REMOTE or San Francisco | Full-time or part-time | https://zulip.com/

At Zulip, we’re out to build the world’s best collaboration platform, and we’re committed to keeping it 100% open source. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations. Our product serves as the communication hub for businesses, open-source projects, educators and communities around the world.

We’re looking for a senior mobile engineer to join our small core team and help define the future of team chat. In this role, you will design new features and subsystems, write design proposals for discussion, and build them in JavaScript using React Native.

We are also hiring for other Engineering, Marketing, and Technical Writing roles. For full details on this role and other open positions, check out https://zulip.com/jobs/. Apply at [email protected].

> Unless I've crossed the line for criminal prosecution (which is far from anything we're discussing here), the worst-case consequence of that is .... damages.

This is not how the law works. In addition to damages, if you're a party to a civil lawsuit then a court can order you to do something. This is called an "injunction".

For example, if I write something and you start selling copies of it without permission, and I sue you over your copyright infringement, a court can and will order you to stop. Copyright has teeth like that.

If the thing you were selling was your product -- based illegally on my GPL'd code -- then that may be a lot worse for you than some damages.