lordofmoria

I completely agree that people are vastly undervaluing convenience, reliability and SaaS being essentially a great way to make something “someone else’s problem”.

The count argument would be that building with AI will potentially give you infinite customizability, which is especially attractive if you’ve ever hit a brick wall using a line-of-business SaaS product. It works great until you hit that wall.

But again, I think this counter argument oversells the value of customization. Most users-would-be-builders would happily build a monstrosity that doesn’t even serve themselves well, if you let them. Building good workflows (and therefore good SaaS products) is not nearly as easy or straightforward as it seems.

I wonder if there’s a simpler and less interesting answer? That it’s just picking up on voice and style, not anything that would apply to the average non-writer?

This person is a skilled writer. Part of that skill is developing a unique voice and style. The AI can identify that - and while that’s certainly impressive because it can identify even relatively niche authors, it has nothing to do with a wider capability to deanonymize people based on arbitrary written text (ex Facebook or text messages).

If you are a professional musician, it’s not difficult to identify a well known musician / recording after listening to only a few seconds - whether they’re playing Bach or Rachmaninov, the style is just “them” - this is the same thing. But you couldn’t take some anonymous high school musician and guess who they were, even if they were your student - the median quickly regresses towards a homogenous, non-distinct style / voice.

A small warning for folks.

I once was responsible for migrating a legacy business app to Azure, and the app had a local MSSQL server co-running with the app (the same pattern that Litestream is using).

As have been mentioned below, the app had been developed assuming the local access (and thus <1ms latency), so it had a ton of N+1 everywhere.

This made it almost impossible to migrate/transition to another configuration.

So, if this style of app hosting doesn't take off and you're at all worried about this being a dead end storage once you reach a certain scale, I'd recommend not doing this, otherwise your options will be very limited.

Then again - I bet you could get very very far on a single box, so maybe it'd be a non factor! :)

I don't understand all the pessimism and incredulity about the valuation. This is an acquisition to take on and disrupt Apple.

Ives + Altman is perceived as a viable successor to the Ives + Jobs partnership that made Apple successful.

Apple is weak and doesn't seem capable of innovating anymore, nor do they seem to understand how to build AI into products.

There's an opportunity to build an Apple-sized hardware wearables company with AI at its core, just as Altman built ChatGPT and disrupted the Google-sized search.

"Apple-sized" more than justifies a 5B valuation.

Sorry, I probably phrased that poorly - when you’re coding with AI, you should get in the habit of spending more time checking for security mistakes. Not sanitizing, not scoping properly. Same mistakes a junior or mid would make, but unlike them, the AI will not doubt itself and highlight particular code it wrote asking “is this right?”. So you need to develop the habit of being careful.

What? Note for any juniors reading this: DO NOT TRY THIS AT HOME.

Does the author enjoy writing code primarily because they enjoy typing?

Are they not able to have the mental discipline to think and problem solve whilst using the living heck out of an AI auto complete?

What's the fun in manually typing out code that has literally been written, copied, copied again, and then re-copied so many times before that the LLM can predict it?

Isn't it more dangerous to not learn the new patterns / habits / research loops / safety checks that come with AI coding? Surely their future career success will depend on it, unless they are currently working in a very, very niche area that is guaranteed to last the rest of their career.

I'm sorry, this is a truly unnatural and absurd reaction to a very natural feeling of being out of our comfort zone because technology has advanced, which we are currently all feeling.

The fundamental problem here is lack of context - a human at your company reading that text would immediately know that Gorilla was not an insider term, and it’d stick out like a sore thumb.

But imagine a new employee eager to please - you could easily imagine them OK’ing the document and making the same assumption the LLM did - “why would you randomly throw in that word if it wasn’t relevant”. Maybe they would ask about it though…

Google search has the same problem as LLMs - some meanings of a search text cannot be de-ambiguified with just the context in the search itself, but the algo has to best-guess anyway.

The cheaper input context for LLMs get, and the larger the context window, the more context you can throw in the prompt, and the more often these ambiguities can be resolved.

Imagine in your gorilla in the step example, if the LLM was given the steps, but you also included the full text of slack/notion and confluence as a reference in the prompt. It might succeed. I do think this is a weak point in LLMs though - they seem to really, really not like correcting you unless you display a high degree of skepticism, and then they go to the opposite end of the extreme and they will make up problems just to please you. I’m not sure how the labs are planning to solve this…

I think the assumption is that this is going into a somewhat modern hashing algorithm like argon, bcrypt (created 1999 - that's a quarter-century ago), or scrypt with salt. With those assumptions, the calculations aren't reusable, and definitely not 1B passwords / second.

If that's not true and the password is being stored using MD5 (something that's been NIST-banned at this point for over a decade), then honestly all bets are off, and even 128 bits of entropy might not be enough.

Yes, edited!

Rails went through a down period 2014-2020 due to several reasons:

1. React burst on the scene in 2014

2. the hyperscale FANG companies were dominating the architecture meta with microservices, tooling etc, which worked for them at 500+ engineers, but made no sense for smaller companies.

3. there was a growing perception that "Rails doesn't scale" as selection bias kicked in - companies that successfully used rails to grow their companies, then were big enough to justify migrating off to microservices, or whatever.

4. Basecamp got caught up in the DEI battles and got a ton of bad press at the height of it.

5. Ruby was legitimately seen as slow.

The big companies that stuck with Rails (GH, Shopify, Gitlab, etc, etc) did a ton of work to fix Ruby perf, and it shows. Shopify in particular deserves an enormous amount of credit for keeping Ruby and Rails going. Their continued existence proves that Rails does, in fact, scale.

Also the meta - tech-architecture and otherwise - seems to be turning back to DHH's favor, make of that what you will.

I had a bad experience with Action Cable + Redis (extremely high memory overhead, tons of dead redis connections), so it's a bit "fool me once" with regard to action cables.

The main argument for caching in the DB (the slight increase in latency going from in-memory->DB-in-memroy is more than countered by the DB's cheapness of cache space allowing you to have tons more cache) is one of those brilliant ideas that I would like to try at some point.

Solid job - i just am 100% happy with Sidekiq at this point, I don't understand why I'd switch and introduce potential instability/issues.