thdxr

Exciting to see this space evolve. Looks like a formidable competitor to Mighty

I've been a subscriber to TailwindUI since it launched. Unfortunately it's not well suited for complex B2B SaaS products that have high information density UIs

I've been doing a lot of research into design systems and one thing that's lacking in most of these documentation sites is examples build with the component library. It's hard for me to get a feel for it without being able to click through a real application.

Also, paid managed services on the backend are super common. I want a paid frontend component library. There are very few of these and I think there's room for an all star frontend team to sell professionally maintained, always improving components. Even on day 1 of my company I'd be willing to pay $100s a month for this

Earthly is great! Finally makes it so CI runs the same everywhere. I try to use it wherever I can

If I had to make an argument for Github I'd suggest that Copilot is just an advanced search feature. It can be seen as simplifying the workflow of using Github's search and then copying the results

Not sure if this simplification crosses some threshold

I'm sure to a lot of people this may not seem like a big deal. However I think this makes a huge difference in lowering the friction to quickly hop in/out of audio. It seems minor but is pretty transformational in how remote communication happens

Working harder is normally interpreted as laboring harder.

I view it as spending the energy in finding creative ways to make money that over time reduce the need for labor. It still counts as working hard because it takes a lot of effort to not just follow a predefined path

Very low quality article with several inaccuracies.

You can rent all the space you want from AWS, you still need to create the plots. Creating them on AWS isn't very economical (which is why no one is doing that) and creating them at home means you have transfer terrabytes out to AWS which won't happen quickly or cheaply.

There's some conflation between plotting (which is one off and intensive) and farming (which is extremely low power and can be done by a rpi)

You might plot on fast NVMEs and transfer to slow HDDs (usually recycled). It's possible to burn out the NVMEs but you're only going to plot as much as you can store.

As with most things it's more complicated than it seems on the surface.

Plenty of comments here have documented the headaches around microservices and predict a shift back to monoliths.

However an alternate perspective is the microservices were not micro enough to make it worth the overhead + cost. My opinion is the reason this none of this feels great is because a container is not small enough of a base unit to enable you to completely forget about infrastructure.

That's why I'm betting the next paradigm that gains traction is fully serverless architectures. The overall direction things have been going for decades is to make hardware more invisible and I think we finally get pretty close with serverless.

In a competitive environment automation doesn't actually help business make money. The increased margin quickly gets turned into discounts that competitors will trade to grab more marketshare.

Areas where there is automation but prices continue to go up have issues with competition - banks are a great example because banking licenses are impossible to acquire.

Roomba, changed my life especially having two cats

I've been avoiding figuring this out years and resorting to editing /etc/resolv.conf manually and chattr +i it to make it readonly. I'm a NetworkManager user so guess it's time to set it up through there

I need to do some benchmarking myself but it seems that even in a local region writes are in the 100s of ms. I'm aiming for my Lambda functions to be < 100ms so using Fauna seems difficult to work in.

Unless you meant I can limit "how global" my data is and that would improve write speeds?

I would love to see more options in the serverless persistence space. Given the infinite combination of tradeoffs that exist with databases there's a lot of room for different solutions.

AWS Aurora Serverless v2 is close to what I'm looking for but think it's held back by trying to make non-serverless technology serverless.

Fauna is close but I don't really need global consistency and don't want to pay the 150ms latency price for it: https://status.fauna.com/

This isn't entirely true. There are payroll taxes levied directly against the corporation, for example social security which is 6.2% by employee and 6.2% by employer

Having spent a lot of time in both it's hard to argue it's as easy in Elixir. You can do it reasonably with a lot of tests but it's nowhere near the same experience as TS

I've been using Elixir for five years and I think it's sorely missing a better type system. I've done fine without it and have gotten entirely used to it but that doesn't mean things wouldn't be better with one.

I only really started noticing as I started to build more complex Typescript systems how much it helps. My teammate shipped a bug in Elixir yesterday that would have been caught by a static type checker

My experience has been extremely the opposite. It's likely the language you tried it with has a poor type system

Highly recommend taking a look at the JSONAPI spec - https://jsonapi.org/

It directly addresses the cons mentioned in the article while retaining all the pros

Been using this for a few months and it has been excellent! Highly recommend this for full stack serverless deployment

This is incredible, congratulations on your launch!

I'm currently working on a product for companies in your space. I'm in the research phase - do you mind if I reach out to you for a quick chat?

Been exploring this more for my next project. Do you think using Purescript both on backend and frontend is viable?

Weird amount of negativity in this thread, of course it's not going to compare to editors with decades of development.

Pretty impressive what you've put together! I'm sure it's really cool being able an editor to work exactly the way you want it to work.

Think you're mixing up parallelism and concurrency. Other databases with connections that support pipelining can easily get to high concurrency even with a single core. The key is the cpu can kick off 100 queries to a single connection and just wake up when a response is available.

This actually doesn't solve the underlying issue that I'm referencing. While this lets you share a pool between multiple processes it does not change the high memory requirements on Postgres to support a highly concurrent workload. One connection (10mb) still can only be doing one thing at a time. Most of the lifetime of a request the connection is idle but locked

I wasn't criticizing Postgres as much as I was a bit confused why I don't hear more people talking about this issue.

I think poolers confuse the issue because they solve the problem of allowing multiple processes to share the same pool, they don't increase throughput to the server.

The 5000 connection example was probably missing some context. I actually was using 10mb per connection as the overhead which creates a decently expensive server for not a lot of throughput.

By pipelining what I mean is allowing multiple requests to be in flight on the connection, each tagged with an ID that gets queued on the server. When a worker process gets around to processing it, it'll send back a response with the same ID. This increases driver complexity but also makes it so you need very few connections per client.

I do not understand why people aren't clamouring against postgres's connection model.

I might be missing something but as I understand it, Postgres had chosen to couple the concept of a connection and a unit of concurrency for simplicity of implementation. However this means that even if your server can theoretically handle 5000 concurrent reads you will never get there because opening 5000 connections isn't practical. You'll likely hit a memory limit.

Why is this generally accepted as ok? Decoupling concurrency from connections seems possible via pipelining commands over a single connection. Is it just too late for a project as mature as Postgres?

Genius!

Although software development tends to come across as deterministic with rules on what to do when, a lot of it is up to developing good judgement.

The more time you spend thinking about the business and how what you're building will support it the better judgement you'll develop. You might not be able to articulate or argue it but you'll have an instinct on when an abstraction is going to be useful vs brittle.

This is great, I can see the potential of something like this and am jealous I'm not the one working on it!

Don't take the pushback in the other comments too seriously. There is definitely an audience (myself included) who'd want a focus, specific tool