chucke

lol, the trans-pacific route was pointless. Portugal monopolized the Indian ocean and spice trade for more than 100 years. It established the atlantic triangle trade of Africa (supplying slaves) to Brasil (supplying sugar) to Europe. All of them comercially viable for centuries. Meanwhile, Spain could barely cross the Pacific ocean and make it the viable trade route to the spice islands that it longed for to be.

Many forget that the circumnavigation of Magellan was both a mistake and a failure. The discovered pass to the Pacific, the southernmost point in the planet not counting Antarctica, was considered unnavigable most of the year (the magellan fleet had to wait 6 months at Puerto San Julian before daring to continue the search, surviving its first mutiny attempt), before treading the slow currents of the Pacific, which took down the majority of the fleet to scurvy (while most likely contributing to the madness of Magellan, which made him the delirious zealot which jumped foolishly to his death at the hands of Lapu Lapu). In fact, part of the fleet tried to make it back through the Pacific, only to give up again, come back to the spice islands and be captured by the portuguese, while the remainder barely made it back, commanded by Elcano, one of the mutineers of Puerto San Julian; a route that btw, they feared taking, as it was in direct violation of the Tordesillas treaty and would certainly condemn them to death would they be discovered. 1 ship out of 5 made it back. 18 out of 270 men. By the time they arrived, the new world colonization was still mostly considered a failure, Columbus still an outcast, not even worthy of naming the continent he discovered (this was roughly 18 years before the Aztecs, Incas, and all the gold and silver that got plundered).

Meanwhile, the portuguese routes remained largely uncontested, that is, until a certain young portuguese king died in a battle in the north of Africa leaving no children, thereby opening the door for the two crowns being ruled by the same king, and with it, making Portugal a target for the many enemies Spain had been collecting along the way. And that was the beginning of the end for the portuguese century.

The Manila galeon is certainly an historic milestone, but it connected America with Asia. Payload needed to be carried by land all the way to the Gulf of Mexico before departing to Europe. Barely global, if that's what's implied. It started quite late in the history of the spanish in Americas, some 100 years after the conquest of Mexico, because until then, extracting and transporting all the gold and silver to Europe was considered more profitable, until there was so much silver in circulation in Europe that it devalued it, thereby making Asia a more enticing market for its silver, as it was still considered valuable by then. The route also lasted a bit more than 50 years. Consider that the portuguese route to India was still being navigated way into the end of the 1800s, and only being truly disrupted by the opening of the Suez canal.

I'm not here to downplay the several achievements, or exacerbate the atrocities of the spanish empire. Every empire had them, no less the portuguese (while they did not come up with the idea of slavery, the atlantic triangle is responsible for the biggest intercontinental forced transfer of human beings in history, and the massive economic dependence it created in African kingdoms caused its brutal collapse after the abolition). But not calling it the first global empire of the discovery age, specially taking into consideration that they literally started a century before anyone else, is factually incorrect.

Both are true. Different camps meant that any significant change to the language was scrutinised loudly. If my memory doesn't fail me, the last significant changes from the time Guido was still in charge, and he mostly abandoned the BDFL because of backlash. Since then python has been on a constant "analysis paralysis" state, with only efforts about performance pushing through (no one complains about a faster horse).

Maybe I wasn't clear, but until now there were 2 types of type notations being debated, RBS and sorbet/RBI. Sorbet adopting RBS means that's the lowest common denominator. Typing is definitely not a standard, not yet. rbs-inline is definitely not a pet project, it's the RBS creator response to the main complaint about RbS , its the reason sorbet finally adopted it, and will be part of mainline rbs gem.

Happy bday ruby!

For the usual doomsdaysayers saying "ruby can't X so I left it for Y", when X is typing, RBS is becoming the accepted standard (now that sorbet supports it),and RBS inline notation next to signature/code too (for peeps complaining about separate files); when X is LSP, ruby-lsp is the standard and already supports "go to definition" (its major hole for a long time), and its plugin architecture allows other other features to reuse the same code AST/index (So that each linter/formatter/type checker doesn't have to parse their own); when X is parallelism, ractors are have actually become performant in a lot of common cases, and it's only missing some GC improvements to be truly non-experimental.

There are new shiny things like ZJIT or Box, but even the core team recommends against using them in production for now. But they'll get better, as its been happening with the things listed above.

No wildly new syntax changes is also a good thing. Should help alternative implementations catch up.

Static typing has come, there's RBS, which has (finally) coalesced (after adding support for inlining in code) as the blessed type notation, supported by both steep and sorbet. Considering that big companies have adopted it, I'd say that the community agrees and has done something about it. But as you can imagine, many ruby apps have been stuck in legacy for years.

About performance, not sure how you think static typing could solve it, but considering the significant investment recently in JITs, in particular YJIT and ZJIT, again, the big apps seem to agree with you and have done something about it?

Even if you ditch CRuby for the JVM, you can still use JRuby, and still leverage the language while not being pulled down by the runtime.

It's not like you're without options.

Lmk when the app launches, will beta test if for free.

What is the real problem being solved here? For all the issues that bundler still has, rv doesn't seem to address most of them. Bundler has been fast enough for a while now, how fast does this need to be? And do we now have to know rust to contribute?

If indirect is salty that the rubygems/bundler didn't turn out yet to be what he wanted, I wonder whether a simpler and faster alternative to bundler written in RUBY wouldn't be the answer, with incremental merges into bundler. Gel was mostly there, even if most never knew about it, but at least it got the bundler ppl to merge the pub grub resolver.

Bear in mind that: the author is part of the ruby core team; json is a standard lib gem; the repo from the json gem was in the original author namespace; the repo had no activity for more than a year, despite several quality MRs.

It took some time to track and get the original author to migrate it to the ruby team namespace.

While I'm glad they to all this trouble, there's only a few who could pull this off. Everyone else would flock to or build a narrative.

OK, I see I skipped that. Nevertheless, I would expect users to read "exactly once" and put an http call in the step. It's the type of knife people their hands with.

> DBOS has a special @DBOS.Transaction decorator. This runs the entire step inside a Postgres transaction. This guarantees exactly-once execution for databases transactional steps.

I stopped here. I know, authors really want to chase the exactly-once dragon, but this won't scale. If the step takes a long time, it'll keep the transaction open with it for that time. The master replica has to bookkeeping that. That state has to be replicated. That will also affect MVVC further on. As your scale grows, you'll see disk usage growing and eventually swapping, replica lags, AND vacuum halting for surges. I hope your uncalled engineers have a steady supply of coffee.

That's not true. Sure, many hot path functions dealing with tensor calculations are done in numpy functions, but etl and args/results are python objects and functions. And most web development libs are pure python (flask, django, etc)

As someone who evangeline Arel where I used to work 10y ago, I can assure you that arel has *never* been considered stable (it also never followed semver), nor has it ever been considered recommended or publicly documented API to use with rails, neither in the time prior to the gem having been moved to the github rails org, nor after. And every rails core team member that has publicly mentioned arel since, afair has always prefaced it with the "private API" warning.

> Sometimes you just need SQL not everything that AR gives you.

I used to agree, until I took a step back and realised how much ruby code ceremony I had to write in order to write, p.ex. A multi insert statement With an expression. It was several character more, and didn't seamlessly trabslate to SQL. I eventually replaced the AREL craft with core sequel, where I'd use it to build the queries and pass the statements to the AR sql execution method. I could have gone with raw sequel too.

> Hanami is a complete Rails replacement. I wouldn’t advocate for that at all.

The top level comment mentioned abstractions that something like hanami already supports. Instead of bending rails, to something it was not built to support, you either pick an alternative tool that does, or you accept what rails does and move on.

The rails core team would tell you NOT to use arel, as it's private API.

The conceptual compression of having activerecord be a database table mapper, entity class, form/input validation, and query builder, it's both its greatest strength and its greatest weakness, depending of the stage of the business. FWIW the ruby community has more suitable alternatives which self serve the kind of abstractions you describe, such as hanami.