That movie is absolutely excellent in all too many aspects, but the one I like most (and most relevant for the HN crowd, I think) is the politics in the business. Thanks to amazing script and stellar performances you get it all:

* Unfair blanket layoff precluding a senior person from alerting anyone * One of the senior execs being made the scapegoat, framed by her evident accomplice in the scheming * Engineers who become quants * Locking people up in a room to make sure they do not spill the beans to anyone

I think Margin Call deserves to be on the same rung of the ladder as LA Confidential - a timeless classic, and some of the cast as well!

I'd say having the luxury to say "No" to things is underrated, and it does come packaged with small teams.

This rings true, but I also saw a lot of situations where just as spaghetti was being tangled, the few folks who resisted it were overruled, again and again.

This is hardly the property of languages or frameworks - just orgs being orgs and incentives being incentives. I don't see why a codebase in a compiled lang would not have queries that "start joining and joining and you get monstrosities of queries" if the business logic demands that queriage to be queriaged?.. Maybe you could make a case to the business that the speed of rework has to be reduced "because static lang and we do things properly here" - but the same can be done with dynamic langs, just with a bit of rigor.

I have worked on quite a few Ruby web apps and built quite a few myself. Maybe 3% of the cases I encountered were about Ruby not being performant enough to do what I needed it to do. Where did the rest of the productivity of end users get lost?

Org dysfunction.

Note that those were web apps - so the user did not have to install the runtime, dependencies etc. to use the software. That is a whole other story (and not a very merry one, at least for all the scripting languages out there).

This is a great presentation/article, thank you for posting it since I haven't seen it go by elsewhere.

What holds me, personally, from Sorbet is the fact that it tries (unwillingly) to dictate which features of Ruby are "bad" by not supporting them - specifically, "prepend" and Refinements. Now, Refinements I havent' seen used in the wild, but "prepend" I use the living hell of - both when designing modules and when overriding other libraries (with moderation, and when I do it is gawddam' well necessary).

While I can appreciate opinions, I am not really motivated to adopt a tool which snaps me on the fingers because I use the tools I know the utility of. I am not working at Stripe nor at Shop :-) Another thing I could really appreciate would be ad-hoc interfaces a-la Go - and more support for duck-typing in general. Maybe I missed this in Sorbet, but it seemed the idea was to "inherit like you are told to and shut up" - which is not how truly great things can get done in Ruby, at least in my experience.

Interesting to see where Sorbet goes in the coming years - and stoked for more RBS/Sorbet interplay!

Thanks!

Much appreciated!

--humbly signed-- a fellow admirer of Geert Van Schlänger

I wouldn't say so, with use cases I saw the databases of tenants would almost never exceed available memory. A database could be loaded into memory in its entirety for the duration of the request, provided the disk IO on the server is cooperating (i.e. "does not degrade to floppy drive speed once you are out of IOPS credit").

That is true, but in my experience this is less of an issue if your migration allow running against "current - 1". If your migration borks on one of the tenants - your system should still work, and you can grab that tenant and investigate.

This problem also does happen with sharded databases - which is why most co's have a structured approach of deploying schema changes, observing them having applied everywhere, and only then deploying the feature relying on the schema changes.

Yeah but “schemas out of sync!” Is a never ending development and operations problem with SQLite database per tenant.

Postgres row level access control gives all the benefits of strong isolation with none of the pain of schemas getting out of sync.

You do need to keep tabs on whether they are or not, that is true - and you will have a bit of management to do if they are under constant heavy write load. For me, this all works out because I don't have too many tenants - and I have tools to block writes when running migrations.

It's all tradeoffs after all.

That is what most tenanting scale-ups do. "Jumbo"-tenants get relocated either to separate partitions, or to partitions which are more sparsely populated.