HN user

chucke

261 karma
Posts4
Comments166
View on HN

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.

Ruby 4.0.0 7 months ago

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).

Ruby 4.0.0 7 months ago

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.

Ruby 4.0.0 7 months ago

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.

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.

I wonder whether the reason for this is a lack of available certified oauth libraries on top of which to build a provider at the time it was built, which led most of these examples to roll their own, with the obvious flaws. There isn't yet such a certification for oauth, although the oidc federation certifies and lists a bunch of them: https://openid.net/developers/certified-openid-connect-imple... (I maintain one of them). Which is the next best thing.

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.

In ruby, the sequel database toolkit is vastly superior to activerecord, and that is a subject of discussion here and there. The difference is that rails is what most rubyists use at work, unlike in python, where choices are more diverse.

FYI rbs-inline is maintained by the rbs creator, and will eventually be merged into mainline, once the inline syntax alternatives are set in stone. All to address the main complaint you mentioned above.

No, they only have time for features and productivity, which is, as you pointed out earlier, what rails is good at.

Calling Cortes genocidal is also quite farfetched, considering that he conquered the Aztec territory, despite being vastly outnumbered, because every native tribe and settlement they found on the way banded together to overthrow the Aztec.

I wouldn't call the Aztecs genocidal either, despite the ritual sacrifices, brutal treatment of other peoples, and everybody in mesoamerica who came to know them hating them so much that they preferred the uncertain fate of joining the white bearded men from the east.

China can produce most things cheaper than anyone. Economically, it's pointless to compete with them. However, if too many think the same, you get bottlenecked and compete for access to the supply, which raises prices. You bevome also politically subservient to China.

Oh I don't dispute that. Despite the documented atrocities, the number of.native deaths by disease are greatly exaggerated, Charles V did write the precursor document of the human rights bill (after getting wind of what went about in Peru), and the Spaniards did promote marriages with natives. Studies of racial superiority the kind of which were prevalent at the end of the 19th century didn't come from Spain either.

History is not a black and white frame that we should either be proud or disgusted about. The fact that the Spanish state promotes such historical wash-ups says more about its current leaders.

FWIW the columbus expedition was considered a great failure at the time. He did fail to reach the indies by the west, and the couple of "indians" he brought to court was little compensation for the lack of lucrative spices. Reaching Lisbon first on the way back was also a disaster, prompting an immediate ultimatum by the portuguese by violation of a treaty, which led ultimately to the tordesilhas treaty which left the kingdom of castille and aragon out of the spice trade. He felt the failure so personally that he sailed back 4 times looking for a passage to the great sea beyond the new world, failing every time and becoming so embittered in the process, that he eventually lost his allies in court. It was only 40 years and lots of failed settlements after the columbus expedition that Spain hit proverbial jackpot and found the gold and silver which made the nation extremely wealthy in Europe, for a time. By then, the new world already had a new name: the Americas. The greatest of the hostorical humiliations, named after an ordinary italian cartographer, rather than the legendary captain which reached it in the first place.

Enshrining him as Spaniard will be of little consolation for his name.

Indeed. Portugal got by in Europe while it could advertise its services as significantly cheaper (Italy and Greece did the same). Romania, Poland and all will live to see another nation take its place, and if not finding a way to produce high value add products and processes, face the same kind of stagnation as Portugal.

Nobody says you need http, sqs, grpc, and queue

I give it to you that, we're it not for microservices, I wouldn't need as much of http, sqs, etc, as well requiring making sense out of all of it via tracing/metrics/logging...

I've worked enough with microservices and heard enough managers preaching the same "cattle not pets", "small focused services", and similar, enough to know that high turnover or several rounds of layoffs, unreasonably high cloud bills and clients frustrated with high latency, often caused by several services, is the inevitable outcome.

Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.

The equivalent to passport in ruby is called omniauth. Having used both, don't really find a huge upside in the former compared to the latter, just different APIs.

That's pretty cool, the examples are quite simple to digest.

Of course, the main argument against it is that you require access to the underlying fds, which most libraries in the ecosystem abstract you away from, so there's no way to use p.ex. net-http with this (without some serious patching and low-lever ivars access). That makes its application limited.

Nevertheless, it's very interesting, thx for sharing. I'm of the opinion that it's about time ruby ships a default performant fiber scheduler

My interpretation of what the author wants, is essentially lightweight threads in the kernel, standardised a lá POSIX , that every proglang could use as a primitive.

That'd be sweet if this were a well understood problem. Unfortunately, we're still finding the sweet spot between I/O Cs CPU bound tasks, "everything is a file" clashing with async network APIs and mostly sync file APIs, and sending that research to the kernel would mean having improvements widely distributed in 5 years or more, and would set back the industry decades, if not centuries. We learned this much already with the history of TCP and the decision of keeping QUIC in userspace.