Hacker Timesnew | past | comments | ask | show | jobs | submit | coreyward's commentslogin

Kinda rich that the guy that thinks we don't need next-gen image formats because "bandwidth is cheap in most places" is making purchasing decisions around bandwidth being expensive.


You just 10x-ed the prices for storage a couple months ago.


Is 5 a reference to how you naked the prices so Neon doesn’t work for light-workload, moderate storage databases anymore? $69+ a month for a Segment data warehouse holding 10gb is obnoxious. It was under $10 before the switch. What’s next? $690/mo?


Either you don’t really rely on your DB or you don’t have monitoring in place. https://x.com/coreyward/status/1734647763151851878


How recently? They had 12 significant outages in a 2.5 month period in Q4 2023. Maybe should have done your homework before switching. https://x.com/coreyward/status/1734647763151851878


Since January 1st this year. We considered other PaaS providers, but Neon offered the best integration with our existing tooling.

We have an SLA in place and haven’t had a single issue so far.


I doubt I’ll ever use Neon again after they had our production database go down several times over just a couple of months Q4 last year. We got tired of the downtime during an incident and we were able to spin up a Supabase PG instance and switch over to it faster than Neon could resolve the incident. It wound up taking them days to resolve it fully. They then increased the prices significantly about a month later. Given that it’s only been four months since these issues, I don’t think that they are serious people in the slightest and don’t trust them with a production database.


(Neon CEO) I'm sorry you had this experience. We had several instabilities in Q4 as the system became popular. That was the one of the reasons we called it "preview" until we got stability to where it needs to be. We are also very transparent about every outage - see neonstatus.com and highlight even the smallest ones.

We are also iterating over prices - we were purely consumption before and realized that we need to offer $19 pain plan to start based on the value our customers get. This is in line for what other devplatform charge for using their services.


Rust got M1 support in November, 2020. There are many other Rust apps that work on M1. This isn't a viable excuse for a publicly traded behemoth that keeps taking on new verticals while ignoring the one feature users care about.


Use whatever tool you prefer, of course, but there are a few underlying assumptions here that I believe are erroneous.

Assumption #1: Design documents are contained in a file, and that file should be portable.

Tools like Figma are closer in nature to SaaS products than they are to native, file-based, raster editing softwares like Photoshop. You don't expect to be able to export your Slack workspace into a file and import it into another tool. You expect to have a means of migrating that data, potentially by exporting that data into a common format (e.g. JSON, CSV), transforming it into a format compatible with the target, and then either importing it using a provided tool or an API.

Assumption #2: Design tools all work similarly enough that document structures are largely portable.

While UI modalities remain similar enough on the surface, the underlying capabilities that produce the visual are exceedingly different. Look at type, for example—even Sketch and Figma, which are similar conceptually and of the same era, render type so differently that even robust import/migrate tools fail to capture the position of text within a few pixels for even basic, single-line, single-style text. Notions of seamlessly switching between tools disregards the real-world complexity of fonts, color profiles, raster manipulations, version history, comments, plugin-generated metadata, symbols/components, and more.

Assumption #3: There's no way to export a Figma document.

You can get the entire document structure from Figma via the API. This is the same data the viewer uses to render the document. You do not need to understand the internals of the .fig files.


Figma's case is more challenging in some ways, too, though. In multiplayer games, like the one described on your website, you rarely have multiple actors independently manipulating the same object, there's a moderate tolerance for imperfect resolution of conflicts, and the server can reject messages that are more than a few seconds out of sync with the server state.

Figma needs to have very consistent, predictable resolution in order for users to trust it with business-critical documents, and it needs to allow users to operate offline for arbitrarily long periods without throwing their work away when they reconnect. This has to happen across multiple versions of the software, and across documents (e.g. when dependency libraries are republished).


Yep, I agree the use case is somewhat different - I wrote as much after the link. Probably why calling this "multiplayer" sounds weird.


Users are currency in the business of the web, and until putting a 5+ digit number of signups in your deck is ineffective, we'll optimize for the collection of email addresses over engagement.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: