That's fair, but I think going on _just_ the quantifiable stuff was still enough of a justification for us. My feels are that the cost of our confusing former name is higher than we know, but the known cost was still great enough.
Scott from Gel here. I suspect for everyone we talked to in the "So, this is a database for Edge computing?" camp there were a dozen people who thought that and just kept moving even if they were our target audience. It's hard to quantify just what the cost have having a name with such a strong connotation (which has arguably gone up and down in the hype cycle over the lifetime of EdgeDB) has been.
Gel doesn't have any really strong existing computing connotations, so maybe people might make a stretch that it's about some non-computing-related domain and maybe we miss reaching them. But that just seems far less likely than trying to continue to push against the overwhelming feeling that "Edge" just has too much baggage and was working against us.
Personally, I think it's fine if people find the name confounding or just personally dislike it. I think products like Supabase, Neon, Drizzle, CockroachDB, Django, Flask, Express, etc etc kind of prove that if your name is general enough, you'll overcome that reaction eventually via recognition for the value of the product itself.
This really was solidified by going through the course at https://type-level-typescript.com since it involves learning the type-level language of TypeScript and solve little puzzles. Doesn't really address performance much, but I think having a working-level understanding of what the type-checker is doing when it's "solving" your TypeScript type-level programs is an important prerequisite for having some intuition about type checker performance.
Yeah! Making explicit return types, especially of public functions, is a good practice to follow. I'd say the main reason isn't performance, though, but rather to ensure you have a stable public API for your module.
How much it actually speeds up the type checker depends on how hard it is for the type checker to infer the return type. And that depends on the return expression, but I don't think there is a single hard and fast rule here. But, if you already have a named type for the return value of the expression, I would absolutely annotate it explicitly when possible. Sometimes the inferred type won't be really the type you intend, and there might just be a more clear type you want to use for communication/documentation purposes.
Hey, article's author here! Happy to answer any questions, or poke at this general problem with anyone who is interested. Understanding the type checker and its performance is my current personal focus and I find it helpful to bat around ideas with others.
Super excited to see Automerge getting this high-level API out. Been following since before 1.0 and I can't wait to play around with the latest incarnation! Congrats to the Automerge team.
A lot of the comments here seem to think this has to become the next Uber, but it really doesn't. It just needs to sustain the cooperative workers and provide a service at whatever scale makes sense for them and our community (speaking as a NYC resident) and that will be success. Heck, it doesn't even need to be the only cooperative like this! They could federate this and it still is more ethical and equitable then the current system. Bravo. Let's do food delivery next!
"The only thing that matters is HEAD+1. I don’t even know why we use version control. It’s entertaining, I guess—the commits and the bug fixes and the rewrites, and stuff like that. But what already happened doesn’t really matter. You don’t need to have the past snapshots to make changes to the current code. In technology, all that matters is tomorrow."