hbrundage

I think your definition of heavy is different than lots of other folks I know -- I'm at $1500 / mo and am actively holding back.

I agree and would take it one step further — the structure of the joins is something that should most often come from the schema, not the query. In the same way that the attributes of an entity should be modelled out ahead of time, the relationships between the entities should be as well, and that yields more productive querying and better performance.

We built a GraphQL / SQL hybrid expression language that does just this here: https://docs.gadget.dev/guides/data-access/gelly#gelly , curious what yall think.

This is the content from the node docs reproduced without credit: https://nodejs.org/en/learn/asynchronous-work/dont-block-the...

Boo!

The move is now to sample it and make new music!

Isn't 63% => 54% regression on MMLU-Pro a huge issue? They said that it excels at advanced reasoning but that seems like a big drawback there.

Makes sense!

I was just talking with a Temporal solutions engineer this week and this metric is their recommended one for autoscaling on. Instead of autoscaling on queue depth, you scale on queue latency! Specifically for them they split up the time from enqueue to start, and then the time from start to done, and you scale on the former, not the total ("ScheduleToStart" in their terms).

Its interesting to see how the Rails world still thinks in terms of the number of processes listening to a queue, instead of thinking in the cloud-native, elastic, serverless terms.

There's always an autoscaling delay, but Rails itself (and the community) don't seem to fit into the serverless paradigm well such that these questions around how to design your queues come up.

I think a lot of Lambda developers or Cloud Run developers would instead say "well my max instances is set to 500, I am pretty sure I'm going to break something else before I hit that", you know? Especially when using the cloud's nice integrations between their queues and their event-driven serverless products its super easy to get exactly as much compute as you need to keep your latency really low.

Dang this is cool! I get why replit went so heavy on nix but I also feel like it must have a cost for them — nix is hard to learn, especially for folks new to development which I know makes up a lot of replits customer base.

We built a solution to the same problem with a similar approach[1], but that just snapshots any old files instead of doing nix derivations. Nix couples the build process to the content-addressability of the output, which works great if you want to put all the effort in to deterministic builds. We just read files like git does which works great for non-deterministic processes like npm install (tragically).

I like the idea of the Big Disk style of attaching a content addressable cache, but in our experiments we still found the network latency to the attached disk too high when reading file by file, like when booting a node app, so we’re caching a much smaller amount on a local SSD for each prod server. Maybe replit isn’t as sensitive to read perf from the cache layer, or they have fancy local per-node read through caching within the overlay setup? Regardless, cool!!

[1]: https://github.com/gadget-inc/dateilager

Practical dichotomy — that’s why this thread exists. You either platform it or you don’t, and you’re either legislated to do so or not. What middle ground do you see that allows this degree of free speech without platforming hate?

It’s a fundamental issue though — there’s no “figuring it out” that a government can do that won’t either censor or facilitate. 25 years has been long enough to find tactical policy changes that make it easier, but there aren’t any, which is why nothing has happened. The choice we have to make is either de-shrine free speech above all else or entrench hatred, and it’s bogus that we haven’t picked the thing that doesn’t kill people yet.

A new paradigm for building web apps: a framework integrated with a runtime integrated with an IDE! https://gadget.dev

We think that so much of software development is still the same stuff repeated over and over: auth, hosting, CRUD, search, tables, forms, etc etc. Each app always has some juicy special something about it, but that core is wrapped in layers of stuff you don’t need to redo every time. Our mission is to make the first and only lines of code you write super pertinent to the specific problem you’re solving.

We’re starting with Shopify apps cause we can give developers a one click, fully managed, code-extensible API integration which is a lot of work with the Shopify API otherwise. Would love to know what y’all think!

Postgres materialized views have to be manually refreshed on a schedule, and so are always out of date, whereas ReadySet keeps your results up to date automatically as the input changes. For PG materialized views, the compute required proportional to the size of the input data, and is paid every time, whereas with ReadySet the computation is incremental, so it's proportional to the size of the change in the data over time.

And finally, ReadySet's (Noria's) big innovation is that the result set can be only partial, storing only the elements of the result set (and underlying data flow graph) that are frequently accessed, instead of the whole result set like a materialized view would.

This system doesn’t support interactive transactions does it? In that the whole read / write set needs to be known up front before a transaction can start being processed? I know that systems like FoundationDB and Calvin/Fauna work similarly and get incredible performance because sequencing is so much easier / lock free. I think those two systems couldn’t be adapted for interactive transactions really (without client side retries) but maybe warp could be which is cool!

I mean, it’s also a bug with Resque? Resque predates the introduction of the new command in Redis and hasn’t really been maintained since. “My software is as buggy as 10 year old software unless you pay” seems pretty sketchy to me!

So glad that Mike has set up a sustainable model for building rock solid infrastructure, however:

I can’t stand that you need to pay for a pro license to avoid completely avoidable data loss. Sidekiq doesn’t use RPOPLPUSH for moving jobs around until you start paying — doing the exact same thing with a different, more correct command. No new infrastructure or configuration is needed. To me this feels sketchy and like a betrayal of the pro-version business model — willfully introducing data loss in order to drive upgrades instead of just removing capabilities or features.

https://therecord.media/security-researcher-drops-chrome-and... says this isn't a fully weaponizable exploit because you still need to escape the Chrome sandbox after using this. But, the researcher shows a screenshot of having started calc.exe which seems like something that'd happen outside the sandbox?

A missing colour in the discussions around complexity today is the ever growing ambition for the problems we're all trying to solve. My grand unified profoundly unserious theory is that we're always going to complain about accidental complexity because we will keep discovering new reams of it by extending what we're trying to do out into the unknown parts.

If we continued to play in just the known parts of the problem space, we'd see it melt away further and further into Brooks' model of the world. Instead, we built distributed systems, we work in absolutely giant teams, we deploy to the strange heterogeneous runtime we call the web, etc etc, and all of that generates new complexities to abstract away before we get back to just the essential stuff.

Nothing wrong with starting there as long as there is a path to profitability with a mass market product! Do you think there is one for vertically grown potatoes? Or corn? Both are 10-100x less valuable per pound and both take 10-100x longer to grow, 10-100x more water, and 10-100x more energy. I am not sure Tesla was battling the same order of magnitude of order of magnitudes.

Totally possible to compete on quality, especially if you are more in it for the lifestyle or the community aspect. You can sell at a farmer's market for 5x what the local grocery store charges and you get 100% of the margin!

Better yet, if you harvest at the right time your product will taste way better because it wasn't shipped across the continent!

Lots of people are still getting into farming these days, you can make a full time salary on as low as 1 acre, especially if you do microgreens. See this fellow's content for far more detail than you might ever want https://www.youtube.com/watch?v=jbHwAfHQA9M

So far, everyone growing vertically is growing crops that are almost entirely water because they're the only things that grow fast enough to turn a profit. They then sell them to rich people who pay 5x for taste and the feeling of eating local. It's a quality-differentiated product, not a solution to food scarcity or security.

Until someone can grow cash crops, vertical isn't gonna make a dent, and it's gonna be really hard when competing with the free rain, free sun, and insane automation available for field agriculture already. Even Plenty with SoftBank's extra 'nutrients' tops out at strawberries. See https://www.eater.com/2018/7/3/17531192/vertical-farming-agr... for some raw data on unit economics.

One application of vertical that does make sense to me is as a community hub or a public health initiative around healthy eating. See https://www.thegrowcer.ca/ who makes container farms for isolated communities in northern Canada and measures success by community outcomes and entrepreneurs inspired, or https://farm.bot/ which encourages hardware hacking and food supply awareness.

That’s just it — no benefit to you, but a lot of benefit to them. They need analytics to sustain their business. They need ads to sustain their business. They (maybe) need fancy interactions to differentiate and thereby sustain their business. If you expect everyone else to only do things that benefit you instead of mediating between benefiting you and benefiting themselves, you’re gonna be pretty disappointed.

Ah, that explains a lot, thanks for the breakdown. And yeah, Prisma 2's type safety is stellar and in a league of it's own.

With respect to building out a big-boy operational datastore -- I think that's really cool. It'd be nice for me to be able to use something like TAO or EVCache or what have you without having to build it all myself, that's for sure. I understand why Prisma's API is constrained compared to a regular relational database in order to support those needs. That said, I think that the very best (and certainly most sell-able) Application Data Platform doesn't require adopters to drop key abilities or semantics they are used to in order to switch away from a normal database. I think those semantics only need to be dropped at the kind of scale which very few Prisma users are ever going to reach, yet they pay the productivity penalty for those missing semantics from the very first moment they begin using the tool.

Yes, you can do a lot of the same things you might want to do with transactions with nested or batch operations, but, not everything. For example, Rails' transactional testing feature is battle tested and seemingly well loved by the community, and currently impossible with Prisma. Instead, you must use a slower and more error-prone database cleaner tool. Another example would be a bank style database with double entry accounting. You want to decrement one account by a certain amount and increment another account by a certain amount transactionally, but only if the from account has a total greater than the certain amount. `SELECT FOR UPDATE` to the rescue in Postgres, but negative account balances with Prisma.

Teaching developers to not hold transactions open for a long time, or to use smart, efficiently implemented nested inserts is a good thing without a doubt, but you could still do that education while preserving transaction semantics. Devs have been used to having those since the 70s. The two aren't in conflict if you ask me. It would make your life harder, that's for sure, but it would make my life as a potential user easier, and remove one argument for not switching over.

You're totally right about connecting to your database from the edge. That said, I think JS is quickly becoming the target for a lot of hosted runtimes because it is so easy to sandbox and has the option to drop down to WASM for high performance and indirectly supporting other languages. Cloudflare Workers (and Fastly, and Superfly, and and and) are all following that path at the edge, but I think as the consensus builds around JS + WASM as a server runtime, we might see the same style of environment for more traditional workloads that might wanna connect to databases.

Prisma is a little bit lower level -- you'd use it within a node backend to get data to and from the database in a typesafe way. Hasura could be used for the same thing, but you'd have to spend some time setting up your own JS client to use within a backend to talk to Hasura. I think Hasura shines a bit more for powering client side apps directly, who just make GraphQL calls right to the "database" service.

Prisma's architecture seems novel and ... a little strange to me. It works by running a Rust engine as a subprocess and then communicating with the engine from JS land over a non-spec compliant GraphQL API. The engine holds the actual databae connection pool and does all the SQL generation and data marshalling. See https://www.prisma.io/docs/reference/tools-and-interfaces/pr... for more info on this arrangement.

It has some weird ramifications though:

- when they go to implement a new feature (like recently added JSON column support) they have to implement it on both sides which can cause bugs like this: https://github.com/prisma/prisma/issues/2432

- they're a little limited to the semantics of GraphQL based RPC, which namely excludes any stateful stuff like arbitrary START TRANSACTION; blocks that might or might not commit. See https://github.com/prisma/prisma-client-js/issues/349 for more info on that

- they don't run everywhere JavaScript runs like the browser or Cloudflare Workers (unless there's something fancy that compiles the engine to WASM I'm not aware of)

I wonder if their intention is to re-use the engine between different JS processes for caching / sharding or something like that, or to add Prisma clients in other languages. Why create the indirection?

I do like Prisma's type safety compared to the pure TypeScript alternatives like TypeORM and MikroORM -- it's really good at typing the results of specific queries and preventing you from accessing stuff that wasn't explicitly loaded. The style of the query language is the cleanest I've seen out of the three as well IMO.

Edit: I think node modules can install arbitrary binaries to some serverless JS runtimes, not sure specifically about Cloudflare but I know their dev tool bundles JS using webpack, which would exclude other binaries from node_modules.

Oh of course, and to be quite honest, I really hope you folks can succeed in your mission. But, I still found that at least locally (in southern Ontario), the unit costs of importing from California still make sense compared to growing locally because of the cost of artificial lighting and the difficulties growing year round. The big greenhouse operations locally grow a premium product that can command a much higher price in order to justify the capex compared to field agriculture or just importing. I assume that premium price would have to go up even more to justify a big investment in automation, right? That's why I was asking if expensive robotics are viable now vs reliant on some change in the market dynamics.

I did! Transportation only accounted for 22% of the cost of a head of lettuce in my local Walmart, which wasn't really enough margin to justify the cost of the artifical lighting necessary to grow in Canada (even in dense southeastern Ontario). I think right now the most realistic application of these technologies is for premium products that are branded as such, like hot house tomatoes or living plants that can command 2-5x the standard barebones import price. Do you have different data?

I spent a bunch of time modelling out the unit economics for autonomous greenhouses and struggled to find any combination of technologies that could even come close to competing with the current costs of field agriculture, including labor. Do you folks need something key to change in the competitive landscape (like climate change or very different immigration laws in the US) to become profitable?

See https://www.eater.com/2018/7/3/17531192/vertical-farming-agr... for an example of the costs for the case of indoor vertical farms.

What % kind of hit do you think you take? I think live streaming the development process might be a really cool way to build a community around a developer-focused tool I might build. Imagine if DHH had streamed the process of creating Rails before it was Rails. I think you're totally right that there's tension between being entertaining and being productive, but do you think one could it well enough that ancillary benefits might be worth it?

Why not? I bet all of the people reading this wrote programs at 5 months into their careers that did something useful, most probably earlier than that! I imagine that most of us readers now have more than 5 months experience under our belts and have since grown, so we can write that program faster or to do more or what have you. None the less, we and these potential students can be productive before being fully educated.

I think it's important that we don't gatekeep as a community and encourage people, especially visible minorities, to join the industry and help us build better stuff! https://dellsystem.me/posts/fragments-50