chucke

Maradona was left-wing friendly, same as Sócrates, which is somehow seen more positively by the crowds. And while Sócrates gets credit for participating at rallies and protests and actually walking the walk, I've never seen Maradona rallying with the people, just benefitting from Cuban public health service.

Despite having been a politician, Pelé rarely discussed preferences, as he was aware of repercussions to his image. In that regard, he can be compared with Michael "republicans also buy sneakers too" Jordan.

Small nitpick: Maxime Chevalier-Boisvert is the creator of YJIT and the BBV optimization technique that underpins it. Shopify is the company which employs her and funds its further improvement.

Microsoft didn't start pouring bucks into improving ruby yet. Their focus has recently been on JS, C# and python.

Python improvements are on par with ruby, and ruby has a JIT, which means that upside fir real world improvement is much higher.

Python has no static typing. It has type annotations, which a few 3rd party static analysers such as mypy use. Ruby has had the same since 3.0 with rbs. The ecosystem may be less mature, but it exists, and Python's isn't necessarily perfect.

Python async is terrible. You have to colorize functions, opt out from a significant part of the ecosystem which either does not support async, or is very unstable, and completely relearn how to do debugging / performance measurement. Ruby has smth better since ruby 3.0, via the fiber scheduler, which supports running network related code asynchronously with *no changes or special function annotations*.

Ruby packaging has been figured out since 2007, and has been influencial for other ecosystems, being the first mainstream language adopting lockfiles.

If you prefer using Python, you are entitled to your opinion and choice. But those arguments are all FUD.

Rubygems supports precompiled binaries, so as long as those exists, it's unnecessary.

Benchmarks will eventually come out. However, put this into perspective.

Ruby has a JIT. Python doesn't. Until it does, its performance is fundamentally capped by it.

Ruby has two viable alternative runtimes, one that sees a lot of production usage (jruby) and another one which can run the same code as CRuby (truffleruby). Both do not have a GIL. Both have multi-tier JITs, and a huge upside. Most of the ecosystem is known to test compatibility with jruby, and the effort to do the same with truffleruby is well underway.

Compare that with python, where not running Cpython comes with a lot of asterisks, mostly because the ML ecosystem that brought it to massive popularity can only run in Cpython.

Ruby has overall more upside.

They would. Some of the constraints were senseless. You used to not be able to use class variables, even if they were already initialized and frozen. However, using static variables, and worse, changing them, was fine.

Ruby uses a lot of pure lazy memorization. That's an aspect I'd like to see more accepted. A system that enforces rather than recommends, is a less usable system.

Celluloid was an actor library which worked well with most ruby code. This is not the case for ractor. For starters, the ruby standard library is itself incompatible with ractor. Go ahead and try using logger inside one. Beyond that, a lot of mature libraries would have to be rewritten to fit ractors, and that's quite risky. Something as simple as a connection pool has to be done completely differently. That's a big red flag, considering that the value of ruby is its ecosystem.

I actually tried making the libs I maintain ractor compatible. I recorded the constraints and suggested removing some of fhe annoying ones. Some got accepted, but it's not enough.

ractors, due to its "no shared or immutable only memory" constraints, is fundamentally incompatible with 99% of ruby code in the wild. I don't see it getting much adoption until some of those constraints are relaxed.

1.0.0 has been released.

Switch to ruby and have all of the prototyping capabilities, way more fun, less surprising behaviour, and none of the package management shenanigans.

But kafka isn't a standard message queue, and therefore won't make onboarding easier except for the ones who already know it, which is not a significant majority, right?

Or at least we'll have to agree on the definition of standard here. For the equivalents of SQL, I'd say we have AMQP or MQTT, and kafka does not seem to support any (my goggling tells me it has its own protocol); deployment-wise, it doesn't seem easier to set up than, let's say, SQS; while used and supported in most common languages, most queue/job frameworks do not seem to support it OOTB (looked into ruby, python, php, javascript), so you'd have to write your own custom kafka handling code from scratch. So what would make it easier than just riding postgres?

I've worked for a while now in the field and I never worked with kafka. Nor most of the peers I've worked with. And I wouldn't even call it the most used message queue or data stream solution, so I don't understand why people treat it as ubiquitous software. SQL, on the other hand, is. And while it's certainly not built for message queues, that's not the point of the article.

Now you have to pay for 2 services instead of one (elasticache is not cheap), and you may need to account for two differently configured redis instances (setting it as cache store requires a different configuration than setting it as a job queue).

You'll also need to code for two integrations (orm + whatever you're using redis with), which may be a solved problem or not, depending of your stack. And even then, still more complex than just postgres, and more error prone considering you'll either have to ignore enqueue reliability, or find a complex way around it.

Stripe also allows a header to declare the version, which is how you should upgrade (test each endpoint one by one, and when they're all migrated, upgrade the account api version).

I personally find this a much saner way to declare api versions (version in header). Specially if the platform supports Webhooks which have urls in the payload: if your API declares version in the path, which version do you use in the webhooks urls?

As bad as strong parameters is, it was still, at the time, a decent improvement over its predecessor, attr_accessible.

Which? Apart from the twitter case, which was ages ago and largely overblown, there's no case that I can remember of ditching ruby for tech X because "for scale". There are lots of examples of companies using other tech rather than ruby, but usually for different reasons (python ML tooling, go for some performance bottleneck, Java for hiring).

As others said, is a layering violation. What that commandment means in practice? Essentially, you can't just udp your way around the protocol, and do frame comparison to test robustness of the protocol, you have to care how it looks like when encrypted. And you now need to use a subset of the TLS spec which most widely used implementations in the wild consider private API. So most QUIC implementations are built on some broken fork of openssl. This leads to fewer implementations, which means concentration of power (spec is not king, the implementations rule the protocol) and narrower attack surface for exploiters. And we all lose.

Not following what you mean. This server is from a shopify employer (major enough?). This server makes quite impressive improvements in terms of memory usage. Moreover, shopify is contributing a production grade JIT to the CRuby runtime.

Both downsides are fixed by using http/2, right? Heartbeat seems trivial to implement using HTTP/2 PING frame. And you already mentioned the stream sharing, which IMO is much better than the state of each tab on the same website opening its own TCP socket, pretty much a resource exhaustion hell (browsers didn't implement websockets on top of h2 last time I checked).

Websockets do have an advantage over SSE: they get binary streams instead of text.

It definitely correlates. Ruby is not the culprit though. It uses and abuses memory as fairly as other similarly GC backed dynamic languages. The issue may be rails and the monolithic pattern, which favours rapid feature development and postpones optimization for when necessary, or one can no longer realise that snippet you wrote 2y ago fetching data from the db scales well for 5 objects, but not 500 objects, but you forgot about that already.

Ruby has a generational GC which already supports compaction, but not in a production ready continuous way, which means most usages have it turned off, and memory pages tend to overcoming and stay fragmented for long running processes. Python has the same issue and node AFAIK.

> If one thing can be gotten from that incident is forcing GitHub to create finer OAuth scopes and per repository.

Just noting that gitlab has supported per repo tokens for ages. Yes, it's really useful, as this incident can attest.

When is RBS support coming?

Browser install wizards already configure the default chosen language to the OS language, which should already be the preferred language, so I'd be very surprised if that was the reason they never bothered to fix this behaviour.

My theory is that yes, they don't lose business because of this so why fix it, but mostly because the most valuable country-markets in the world tend to be monolingual, and the US is the most profitable of them all. And everyone uses Google despite of this because well, what else?

Why not just use numo, Ruby's own numpy?

I don't read the script, script reads me.

operationally, makes sense. but the inevitable moment (if you survive) you need to migrate to smth else depending on a different queue system, it'll be a pain to retrofit the code relying on db-level transactions and locks.

I believe you're downplaying the potential here (and I'm overplaying it). A particular blockchain you could immediately verify home ownership online via some sort of signature with the public key from a seller seems like providing the same type of guarantees. Is it 100% safe? Certainly not. But considering your notary might be a fraud, a scammer or just not very good at what he does...

Compare the example with withdrawing money: you can go to an ATM and withdraw money for no fee, depending of the country. Do it in the bank, there I an associated fee.

The legal system would still have to adopt it though. And it's an industry less prone to digital innovation. And there is no financial incentive, as there is no narrow profit margin you need to optimize. So yes, it may never happen.

Blockhains can be as simple as an API. See the 7 layer stack in the Nexus blockchain (you definitely don't need to go smart contract all the time).

I think the author exaggerates a bit the tone. Sure, 10 years is a lot of Internet time. But the steam engine took 50 years to become viable. Then the industrial revolution was a period of 80 years. Put that into perspective.

I guess, by speculative, you mean the cryptocurrency craze.and I can agree is a speculative bubble, an MLM scheme. But then you also have https://cyber.ee/resources/news/digital-identity-and-blockch... . You'll soon have CDBCs. And when it's here, you'll barely remember what this conversation.

Your bitcoin might be worthless by then.

I'm thinking of a blockchain where the ledger is public read (for verifications) and write-constrained. How can you verify the.legitimacy of the introduced data? Probably some other tool. But it being federated across countries would have the nice property of non-gatekeeping. There are politics in play, but if the UN is possible, só is such a system.

This is all just my theoretical assessment, anyway. And I agree that other standards and toolchain is necessary to add value. Blockchains don't do KYC nor identity verification and a lot of other things.