chucke

Claiming "plenty of bugs" without stating any, doesn't really open the thread for constructive discussion, and frankly sounds like unnecessary FUD. Claiming that the ruby community doesn't care about correctness is borderline offensive, at least without evidence that reports are being ignored.

That's disingenuous. Python 3 was released around 2008, rails popularity was still rising. The community refused to upgrade for at least 10y, and several prominent libraries took as much to provide first grade python 3 support.

Ruby 1.8 to 1.9 migration was by contrast way milder. It took 6 or 7 patch releases and around five years to release 1.9.3, the first from the 1.9 series people actually considered stable, but after that the community migrated because it was *significantly* faster than 1.8 . Python 3 on the other hand was slower overall than python 3 at least until 3.6. The fact that the community stuck with python through it all does say a lot about human psychology and sunken cost syndrome.

Mentioning 1.9 migration and ruby being slow? Python 2 to 3 was waaaaay worse and more negatively impactful, and equally slow (slower in most cases).

Ruby never had US market penetrative as perl or python, which were basically invented in the US, and congregated people from the academic realm. These things aren't decided based on meritocracy (no things ever are).

Bear in mind that this article is old. Since then, ruby support a [handle_interrupt mechanism not far from the method described as working in java](https://rubyapi.org/3.3/o/thread#method-c-handle_interrupt)

How is the CONTINUATION frame issue handled? Max number of continuations per stream?

It isn't a big win compared to just calling the method with it:

    meth(foo: 1, bar: 2)

    # even if multiline

    meth(
      foo: 1,
      bar: 2
    )

while needlessly allocating an hash (kwargs optimize that).

1. About Verbosity: that's not common nor idiomatic ruby. You'd much more often see a case statement there, and nowadays with pattern matching. It look like idiomatic python though...

2. About Long Expressions to Detect nil: rails devs have had Object#try fir many ears to avoid that, and &. syntax since ruby 2.3 (10 years?).

3. About Overuse of self, again, clearly the author hasn't done enough python... and that's hardly common, given the many options ruby gives you (ivar access, self-less implicit method calls...)

4. About Collecting Results in Temporary Variables, ruby has supported map/filter/reduce for more than 15 years. This was however quite common code to find years ago from ex-java devs...

5. About Sorting and Filtering in Memory, that's actually the only legitimate problem I can think of. However, I'd hardly consider that Ruby's fault, and more of a superpower of composition of abstractions (datasets to enumerables) which should obviously be handled with care (and perhaps linked against? Does ruboxop support smth of the kind?)

Actual thing I see many times and should be avoided: construction an hash of options first, then pass it as kwargs:

    opts = {
      foo: 1,
      bar: 2
    }
    meth(opts)

!-suffixed being dangerous is a rails convention (throws exception). !-suffixed methods are a ruby convention for instance mutation. Calling mutation dangerous isn't a justification for your argument, as there are intrinsic benefits to using those where justified and contained, such as memory savings.

For payments, not for billing, right? I'd be very surprised otherwise, considering how Stripe's offer for billing is quite inflexible and (at least 6 months ago) offering experimental features.

That's quite the history lesson, thx for the info.

I agree that H2 is defacto better than H1, and easier to implement when compared to H3. However, I'll call out the 2 biggest time sinks of the RFC: stream prioritisation and server push. Both of which had narrow application, and incomplete/inefficient specification. H3 seems to have ditched both. My question is, how did this ever end up in the final RFC? As both seem like the kind of thing that could have been easily disproved in SPDY deployments, as well as just asking people doing HTTP for a living.

As much as the default behaviour is questionable, I don't fully agree with the assessment: this is in fact a curl documentation problem.

As a multi-protocol lib, curl does not in fact implement all of them directly, instead relying on transitive dependencies which act as "backends" to outsource, in most cases, decoding the low-level bits. For some of the protocols, and for good reason, it incorporates support for multiple alternative libraries.

The downside of that approach is that it is hard, if not impossible, to ensure common behaviour across independent backends which may not cover all of the same features, provide incomplete APIs, or, such as in this case do not provide a way to patch some of its default behaviour. Libressl is not a bit-for-bit reimplementation of openssl, and are under no obligation to mimic its API fully (however convenient that would be for us all).

In such cases, and given the reluctance of upstream to fix it, curl is left with 2 possibilities: drop support for said library, or document the quirk. Given the downside of breaking user code of following the former, it should at least do the latter.

All this being said, I do agree with the main sentiment that this is a flawed approach from a security standpoint of libressl, and there's probably reason to open a CVE, but it should be on libressl.

> I didn't mean as it's the same thing, I meant there's significant overlap across the ecosystem for both. The most obvious example is numpy, and the role of narray as an almost native type.

> According to the 2023 Stack Overflow Developer Survey[1], Django is more than twice as widely used as Ruby on Rails.

Even I'd consider SO surveys relevant, it'd still be a niche, just a bigger niche than rails.

Most other languages don't have knifes at all. What do you call the interface{} madness in go?

Yes, it is only machine learning. Trying to separate it from the scientific community is creating a wall that does not exist. Besides, barely anyone uses python for 2d games or microcontrollers (out of hobbyist programs, and ruby also has a stack there with mruby or dragonruby, which have professional adoption mostly in japan), and you can't say with a straight face that python is a meaningful player in the Web application space, beyond its niche (and async python is a s**show).

> OIDC solves problems for OAuth2 like "every Identity Provider has different endpoints" with OpenID Connect Discovery

Not really: https://www.rfc-editor.org/rfc/rfc8414.html

And security (basic auth is as good as sending clear text passwords).

Metasploit? Logstash? Docker-sync? Vagrant? Jekyll?

> If you rewrite it anyway, might as well use something else than ruby.

You just said the company is a rails shop, why would you force a new language on everyone who already invested in understanding ruby?

The getaddrinfo interface does not expose the fd so you can monitor for readiness. Several languages have the same problem with it, some with similar solutions (go outsources getaddrinfo calls to a thread pool)

Pry and byebug paved the way in a lot of ways for this work, but they break in fundamental ways across a range of use cases, such as multithreading, multifiber, or quirk around exception handling. While these are all fixable, so we're the lack of standard quality tooling , which is quietly being addressed by irb and debug gems.

You're spot on. You can see its influence in a lot of tooling coming after, such as several package managers (from yarn to cargo), java collections syntax, go structural typing, python's gunicorn, JVMs invokedynamic (introduced for jruby originally), among others I can't remember from the top of my head. Several new languages were created, or benefit from the collaboration of ex-rubyists, from elixir to rust to node, which greatly influenced their approach to developer ergonomics. Even if the world would refuse to stop using ruby forever (which will never happen, why would it...), its influence would last for a long time, after which it'd be rediscovered again after the mandatory forgetfulness cycle.

I agree, with the implicit "build it in-house with OIDC certified 3rd party dependencies ". The foundation already goes a long way towards providing conformance suites and several certificates. I don't understand how we came into this status quo of "I'm just gonna outsource users data, XP and all to this company I have little transparency over, and its gonna be fine because I don't waste time maintaining infrastructure for auth which is my core business, much better to maintain the several sync points, settings pages they won't possibly do, and waste man hours inquiring about why this user password changed when they are telling us it didn't, and I can't tell them to ask Auth0?"

Skip tests.

Thank you for coming to my Ted talk.

It sounds like programming is a "means to an end" and you don't cate that much about the plumbing as you do about the outcome, so you use python out of convenience and not out of taste? If that's so, fine, but you don't seem to have much "stake" in the discussion.

> I can honestly say I couldn’t have done the same with Ruby because the Ruby ecosystem and tooling didn’t support such impact size in my (and many similar) domains.

But did you give it an honest try, or is that an assumption? While no ecosystem I at python's level in the ML space, Ruby's contributions are not necessarily non-existent, and you'll find a few options when you actually look for it (sidenote: the pgvector extension for postgresql has been created by a prominent ruby ML developer)

And I never heard of TypeORM until now, which means that it's not boring tech in my eyes. I find it hard to classify anything in the node world as boring, considering the infamous churn rate. Popular yes, boring no.

SQS limits you further in other ways. For instance, scheduled tasks are capped to 15m (delaySconds knob), so you'll be stuck when implementing the "cancel account if not verified in 7 days" workflow. You'll either reenqueue a message every 15m until its ready (and eat your the SQS costs), or build a bespoke solution only for scheduled tasks using some other store (the database usually) and another polling loop (at a fraction of the quality of any other OSS tool). This is a problem well solved by sidekiq, despite the other drawbacks you mention.

Bottom line, there is no silver bullet.

You're implying that those languages made actual building products easier. I think we know by now they didn't. Go is a language which preaches building your boilerplate than reusing it. Produces very little of the economies of scale requires to build compelling products. It has other advantages, and the single binary thing captured a niche in infrastructure software, but that's it outside of Google. Rust is still young, jury is out, but it's already considered a big and hard to learn language, and that's not going to change soon. It'll eventually find a niche.

Ruby is still a great way to start it up. Consider that in 2006-2008, it's deployment story was horrible. Since then, the ruby ecosystem bootstrapped lockfiles, 12 factor app manifesto, and a lot of the conventions we all take for granted nowadays. And while there are certainly enough arguments to bikeshed on, its still a rock solid ecosystem.

Evan Phoenix is saying it for even longer, and created rubinius as a means to prove it :) (it has since been abandoned, but Chris's truffleruby ported rubinius core and stdlib implementations, so it's great that they've all been feeding each other for quite a while)

Great point. Not just writing ruby, but writing more performant ruby. I found that we several "here's how to implemented this GoF pattern in ruby" to "thank" for a lot of the unoptimized code we see around.

I'd assume that the benchmark is showcasing the gains of the async model, more than making a point that native python is faster than C. The issue is ultimately: how much of the functionality available through libpq is not yet backported to asyncpg (i imagine it's nonzero, but Idon'tknow the answer). Which is why the pragmatic in me still prefer a middle layer like libpq in between.