It's simplistic, but I think there's two ways you can approach building a product company.

Either you focus on creating a great product that customers love. As a consequence, you'll hopefully make some money.

Or you focus on making a truckload of money as quick as possible, and building a product is merely a means to an end.

As OP said, there's far too few companies choosing the first approach, and far too many choosing the second one.

This shouldn't really be that surprising. There's a stronger incentive to do the latter than the former. If it's plausible enough to take the latter strategy that the expected value of the strategy is higher, then that will be the strategy preferentially taken.

I think that's a misconception.

It's quite possible that the expected value for most companies over, say 10 years, is overall higher. I obviously have no data, call it a hunch

We just don't hear enough about companies growing steadily and profitably over the years, but over report on the unicorns and smash hits.

Investors do have that data, and they clearly seem to disagree through their investment strategies, and it seems to be turning out well for them enough for that strategy to be consistently profitable, so your hunch may be wrong.

Investors are pushed to care about this quarter's revenue, and discouraged from caring about anything else, by a host of warped and unintentional incentives.

I don't think we can use their behavior as an indicator of what's optimal over the long run.

So dedicated a longer portion of my life for an equally uncertain lessor reward or try to cash out as soon as possible to focus on the important things. Obviously the latter is the better option.

Even those who follow the former path often opine about lost youth and time with friends and family.

Under the hood, it uses good ol' fork and keeps track of the generated process IDs.

It's surprisingly simple. You can check out the relevant source here: https://github.com/rails/solid_queue/blob/main/lib%2Fsolid_q...

Author here. What a pleasant surprise to see this on HN!

Happy to answer any questions.

Thanks for the write-up, I feel like I understand Solid Queue quite well, now.

I suppose my primary question is: What does this do better than Sidekiq+Redis; or, why should I convert my Sidekiq jobs to use Solid Queue? I'm curious also if there are comparisons of performance anywhere.

All-in-all, though, it looks technically quite promising!

thanks for this write up.

some of us are happy rails users so more rails content is always welcome

I launched something similar a year ago, funnily with an almost identical name.

Different tech stack and slightly different features though. Super cool to see more other tools in the space!

https://datadeaddrop.com/

That's awesome — love seeing others thinking in the same direction! Just checked out your project, and it’s really well put together. Funny how we both ended up with such similar names and ideas. I hadn’t seen yours before launching mine, but it’s super cool to see how you approached it differently with those extra features. More privacy-focused tools in the space is always a win!

He's talking about npm

You have been able to do that for a few years now, e.g.: `npm i https://github.com/user_name/node_project_name`

...or with `npm i git+ssh:...`, and npm will git clone it locally, as long as it has a `package.json`

You can install a certain commit, or even from a Gist!

Have been using asdf (with Ruby and JS) for years, haven't had a reason to look for something else yet.

I stopped using asdf as it's a huge security nightmare. Literally, you're running third-party Bash scripts, which have no checksums and absolute no security considerations! Even WordPress is better as it controls the source code of the standard plugins unlike asdf! Also, I often face an issue with GitHub IP quotas as each formula is on its own, often doesn't follow any basic security best practices or conventions, and does not use GITHUB_TOKEN to authenticate against the GitHub API. 90% of the plugin code for asdf is the same. I'm not sure why there's no basic framework that uses eget or other now-popular tools to fetch binaries for the proper arch from GitHub releases! That's why I use aqua [1], which just does this, and unlike asdf, is extremely fast as it has caching and downloads binaries in parallel.

[1]: https://aquaproj.github.io/

Asdf is great - I'm not knocking it at all and have built several scripts for it over the years - but I think mise might be a better tool for someone starting out from scratch: https://github.com/jdx/mise. These days I'm using nix, but it's not for everyone.

Yes, asdf just works for me. I can't recall a single issue in like 8 years of using it

See edge guides (https://edgeguides.rubyonrails.org/7_2_release_notes.html) for some highlights.

I'm looking forward to using some of the developer experience stuff, such as default RuboCop or default GH actions for new apps. Not sure if it's everyone's cup of tea though.

I think there has to be some investments into the DX, I mean look at Ruby, it's lacking so much compared to other languages. Basic autocomplete is barely working, it's probably because the nature of Ruby but it still adds friction to the workspace.

> I didn’t want to deal with databases.

So instead I used a third party authentication service, store some data in JSON files, and also threw up a lamda gateway to store some more data in Google Sheets?

It's not relevant to the bug hunt, but I'm genuinely intrigued. Is this approach considered easier to work with than using a regular ol' DB?

My first thought as well. This is the most complicated stack I’ve seen for something so simple. Just convinced me more to avoid using JavaScript as a backend

Honest question: how is that JS's fault?

I think the evolution of this person's personal server as outlined in the readme is very insightful.

Goes from literally no configuration management (just SSH into the box to install your stuff) to Ansible and then to Docker and k8s. Quite the Journey.

I think a lot of people here can relate, I certainly can.

Looks nice!

I'm on an older phone though and your landing Page murders it. Animations stutter and scrolling is pretty janky. Not sure I'd that's an issue with the components or something else?