[RomanPushkin]

I'm happy to see v4.0, but 2025 was the year I switched from Ruby to Python after gradually drifting back to it more and more. The tipping point was when I had Claude Code automatically convert one of my Ruby projects to 100% Python - and after that, I just had no Ruby left.

I spent over a decade enjoying Ruby and even wrote a book about it. At this point, though, Python has won for me: fastapi, pytorch, langchain, streamlit, and so on and on.

It's a bit sad, but I'll always remember the Christmas gifts, and the syntax that is always so much better than Python.

[pansa2]

> fastapi, pytorch, langchain, streamlit, and so on and on

It's telling that your reasons for switching are all features of Python's ecosystem, not of the language itself. A lot of developers are moving to Python because of its libraries, and in many cases they don't care for the language at all.

That's causing a problem for Python: many of these developers who'd rather be using different languages seem to want to morph Python into their language of choice. The result is that the Python language is pulled in many different directions, and with each release gets increasingly bloated and strays further from its foundations.

Ruby, on the other hand, has a community that's mostly made up of people who actually like the language. That allows it to do a much better job of staying true to its core philosophy.

[thunky]

> It's telling that your reasons for switching are all features of Python's ecosystem, not of the language itself.

Right, because ecosystem beats syntax any day of the week. Plus many of us also think the Python language is nicer anyway. For me I can't get past Ruby's free wheeling approach to import scoping and tolerance for magic.

[tasuki]

Sure ecosystem beats syntax. Ecosystem also beats semantics, but less so. Python has an amazing ecosystem and a pretty nice syntax. Pity about the semantics...

[ngcazz]

That core philosophy is a focus on aesthetics which means that API design in Ruby is much more driven by developer taste than practical considerations (for better or worse)

[empthought]

None of what you say about Python is true. It’s not even plausible. The Python language hasn’t even had any significant syntax changes for four versions now; versions 3.11-3.14 are basically all internals optimizations.

Why would you write something so clearly false?

[chucke]

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

[woodruffw]

> 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

I think Guido left the BDFL role in 2018, and we’ve gotten walrus operators, structured matching, and exception groups since then (just off the top of my head). There’s also been significant language/grammar accommodations towards type annotations.

Overall, I’m of the opinion that Python’s language evolution has struck a pretty nice balance — there’s always going to be something new, but I don’t feel like the syntax has stagnated.

[empthought]

The other poster said “The result is that the Python language is pulled in many different directions, and with each release gets increasingly bloated and strays further from its foundations.” Which is directly contradictory to your (more correct) notion that language changes have slowed and only changes with low or no additions of complexity are worked on.

[aobdev]

Have you worked on different types of Python projects? (Not in different codebases, different types of codebases)

I don’t have any specific complaints about Python syntax because I can force it to get the job done…but homogeneous, it is not.

[empthought]

The falsehood is the phrase "with each release gets increasingly bloated and strays further from its foundations."

It hasn't had any such language-changing release for at least six years. The implication that this is an ongoing process attributable to newer adopters is simply false. It is a process that has stopped, and when it was happening, it was attributable to longtime Python developers.

[jurgenkesker]

This year I also switched from Ruby to Kotlin on my hobby/light commercial backends. I just can't stand the way Ruby is not statically typed, and the resulting insecurity around if everything is actually doing what it should do. Kotlin gives me joy, and performance is actually better (trading memory requirements ofcourse, but that's not a big problem anymore). I still love Ruby, but only use it for simple scripts now.

[blandflakes]

This has sort of been my issue with Elixir. I've been doing Scala for years but I think Phoenix is really the best web story at the moment for how I want to be building web apps. And while I believe that the benefits of static typing somewhat decrease in the web arena, it's still frustrating to have to manage type relationships in my head.

I'm hopeful that the incoming type system work makes me happier there, though I'd also prefer a nicer editor experience than is currently available.

[dmux]

> I believe that the benefits of static typing somewhat decrease in the web arena

I’ve seen this sentiment expressed numerous times and have never found it to be true in my own work (e-comm), do you mind mentioning _what_ type of domain your web apps are in?

Edit: or if not domain, what do you mean by “web arena”

[blandflakes]

I find that if most of my logic is relatively gluey, then the fields in my API boundaries are heavily optional, at which point types add a lot less than they do when most of my logic is more internal, and in cases where what I'm doing is just getting some JSON and doing something with it, I'd rather just have the dynamic shape of the JSON in a lot of cases than have to declare an entire schema/codec.

We have so much boilerplate and tooling to share request/response types between services and it's just... heavy. The same feeling arises when I'm sitting here trying to share a shape between a web app and the backend service, where FINALLY I just want the types to get out of my way instead of having to go through all this ceremony.

And my domain is relatively precise and typeable - streaming video with a deterministic set of parameters.

Generally though I'm more likely to agree with the value of types than to undersell them; I just can't find a ways to describe the above experiences such that they reflect that perspective.

I think it's not that I don't want types, it's that I want simple types that play slightly more dynamically - maps of <string, heterogeneous values>, for example, and reasonable means of interacting with them (like various "safe traversal" operators that some languages have added).

[tasuki]

Have you tried Gleam? It's a simple, strongly typed functional language running on the Erlang VM.

(I also come from Scala and so far, like what I see with Gleam.)

[blandflakes]

Yes; my only critique is that Elixir is already a niche. You could argue it two ways:

1. A niche within a niche is a bad idea 2. If you're going niche, going further niche hardly makes a difference

[duckydude20]

what advantage/disadvantages does Scala/jvm have over Elixir/otp/beam?

i am learning Elixir and liking the concepts. i am coming from kotlin/jvm and i like kotlin, apart from kotlin-coroutines. planning to migration all threading code to virtual threads. but biggest problem is threadlocal.

[blandflakes]

I think they're pretty different, but there are some places where you can compare them:

1. Hiring and job market - the JVM is simply more employable

2. Ecosystem - in general you can expect the JVM to have library support for most things you're going to need.

3. Typing - if you like static types, you're probably going to miss that in Elixir/Erlang. They're working on a gradual type system for Elixir that looks quite pragmatic, so I'm excited to see how that works out.

The Elixir side of things has some real advantages, though. Runtimes like the JVM are slowly adding threading paradigms that start to look like how the beam works, if you squint enough. Naturally, Elixir already has that, and already has technologies that work very well with it. Virtual threads on the JVM are a smart effort that will take a long time to be complete and will always have to take backwards-compatibility into account, especially if you're in Java itself.

Phoenix is also IMO a best-in-class web framework. I don't think it's universally applicable, but if any JVM language had something like Phoenix I doubt I'd be considering Elixir nearly as strongly (due to my affection for types). So while the JVM ecosystem is broader, it's not uniformly stronger.

I also think that "domain" is much broader for JVM stuff. The web technologies there feel pretty baroque rather than empowering, but you can still do web on the JVM, and Kotlin or Scala in particular IMO serve better for systems where the bulk of the code is internal business logic. I think that even if I adopted Elixir entirely, I'd probably retain some "second language" for deeper systems.

[RomanPushkin]

> the JVM is simply more employable

How do you know it? Today you have to re-assess what you've learnt in the past. If you think JVM is "simply more employable" and haven't tested the waters in last 1-2 years, chances are you're just wrong.

The feeling I have: more simpler the tech is (and JVM/Ruby/other CRUD), the highest salary cuts you're getting. And you're actually less employable.

It is that counter-intuitive, because it's one person with a coding agent vs a team in the past.

[blandflakes]

This is patronizing. I'm a professional and am constantly hiring and being hired. The JVM has far more jobs and engineers willing to do those jobs, _and_ in terms of your own employment, a better salary market, and this is not only self-evident, but reinforced by even a cursory investigation into the trends. In fact, your claim is so outrageous (that I'm wrong and that somehow Elixir has more to offer on either side of the hiring bar) that I think the onus is on you to somehow prove it.

[0xblinq]

Just by how much better the editor/IDE support is with Python it is a change worth to do.

I just can’t stand the excessive dynamism of Ruby. I understand some people prefer/enjoy it, it’s just not for me.

[Bayko]

Langchain? I tried using/learning langchain then I found out that it was evolving so fast that even the latest ai models didn't have even remotely up to date information on it! Not to mention the hundreds of Google search results for ---- why do langchain docs suck? I finally switched to haystack and I have been really happy. (Don't work on corporate ai software this is just for personal use)

[nurettin]

Used Ruby for a decade, knew about it for more than that. I still sometimes use ruby syntax to communicate ideas with friends and colleagues.

For me, the killer feature of Python was the typing module and the intellij pycharm community edition being free and RubyMine having a subscription fee.

[nix-zarathustra]

RubyMine is free for non-commercial usage.

[nurettin]

Ah, that must be a recent development.

[michaelcampbell]

It is; last couple months.

[firemelt]

I get the sentiment, pandas, numpy, pytorch

but I still love writing full stack webapp using rails so yeah

thats why I really love pyCall

[lcnmrn]

You should try Falcon too.