chucke (u/chucke) - Readit News

chucke commented on Ruby 4.0.0 ruby-lang.org/en/news/202... · Posted by u/FBISurveillance

empthought · 2 days ago

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 · 2 days 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).

chucke commented on Ruby 4.0.0 ruby-lang.org/en/news/202... · Posted by u/FBISurveillance

rco8786 · 2 days ago

Fairly hardcore rubyist here. Ruby-lsp is excellent. But in no way is RBS becoming standard. Maybe it will, I don’t know. But adoption is very, very low as of today. Rbs-inline is just someone’s pet project and has very little activity (though it does appear that the person who wrote it is trying to implement it directly into Rbs now, which would be great)

Personally I can’t see any comment based typing system gaining real traction.

chucke · 2 days 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.

chucke commented on Ruby 4.0.0 ruby-lang.org/en/news/202... · Posted by u/FBISurveillance

chucke · 2 days 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.

chucke commented on Friendly attributes pattern in Ruby brunosutic.com/blog/ruby-... · Posted by u/brunosutic

dlisboa · 2 months ago

Just want to reiterate what the sibling commenter said, it's dead on with my experience.

Static typing would be the main thing teams would've been better off with. I was big on dynamic languages, love Clojure/LISPs and still work with Ruby and JS today, but you just can't trust 100 developers with it. Last company I worked for I ran the dev team and did some bug analysis: conservatively 60% of bugs were things a simple static type system would've caught.

Very few business logic bugs. We had loads of tests but these simple bugs still popped up. Someone in team A would change a method's return type, find and replace in the codebase, but miss some obscure case from team D. Rinse and repeat. Nothing complicated, just discipline but you can't trust discipline on a 500k LoC codebase and a language with no guardrails.

Performance would've been the other main advantage of static typing. While most people think their Rails app will be IO-bound forever that's really downplaying their product. In actuality every company that mildly succeeds will start to acquire CPU-bound workloads and it'll come a point where they are the bottleneck. One might argue that it is at this point you ditch Ruby but in reality no one really wants to run a polyglot company: it's hard to hire, hard to fill in gaps, hard to manage and evaluate talent.

People underestimate the impact of performance on the bottom line these days with phrases like "memory is cheap; devs are not". Like the sibling commenter put it the monthly cloud bill on that last company would've paid about 20 dev salaries. Most of that was for the app servers. That for an app that served about 500 req/sec at peak. You can imagine the unnecessary pressure that puts on the company's finances.

Better choices would've been Go, Rust, even something on the JVM.

chucke · 2 months ago

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.

chucke commented on Lisbon Airport is turning away private jets inbound for the Web Summit engadget.com/big-tech/the... · Posted by u/rock_artist

Johnny555 · 2 months ago

>Setting aside the environmental impact of flying private, you'd think all those brilliant minds could come up with some kind of solution beyond flying further away and driving into Portugal. Maybe a jet that hundreds of people can charter at once?

Seems like there's a business model here -- create a company that owns large aircraft and have some kind of booking engine that lets people book seats on those airplanes. Maybe have those planes travel on a fixed schedule to let people plan travel in advance.

chucke · 2 months ago

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

chucke commented on Rv, a new kind of Ruby management tool andre.arko.net/2025/08/25... · Posted by u/steveklabnik

chucke · 4 months ago

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.

chucke commented on Ruby 3.4.0 ruby-lang.org/en/news/202... · Posted by u/aaronbrethorst

bendangelo · a year ago

Most gems with native extensions won't work. Gems that listen to filesystem changes like guard can be buggy. I recommend using Mac or Linux for Ruby on Rails development.

chucke · a year ago

The listen gem works on windows: https://github.com/guard/listen?tab=readme-ov-file#listen-ad... . Not sure whether guard builds on top of it.

chucke commented on Optimizing Ruby's JSON, Part 1 byroot.github.io/ruby/jso... · Posted by u/todsacerdoti

akira2501 · a year ago

What I love about this article is it's actual engineering work on an existing code base. It doesn't seek to just replace things or swap libraries in an effort to be marginally faster. It digs into the actual code and seeks to genuinely improve it not only for speed but for efficiency. This simply does not get done enough in modern projects.

I wonder if it was done more regularly would we even end up with libraries like simdjson or oj in the first place? The problem domain simply isn't _that_ hard.

chucke · a year ago

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.

chucke commented on Dear OAuth Providers pilcrowonpaper.com/blog/d... · Posted by u/franciscop

chucke · a year ago

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.

chucke commented on Running Durable Workflows in Postgres Using DBOS supabase.com/blog/durable... · Posted by u/kiwicopple

KraftyOne · a year ago

Yes, that's why the @DBOS.Transaction is just for database operations, which (hopefully!) you've already optimized to not take unreasonable time. These are guaranteed to execute exactly-once. For other, potentially longer-running operations, use @DBOS.step, which is at-least-once. Documentation:

Transactions: https://docs.dbos.dev/python/tutorials/transaction-tutorial

Steps: https://docs.dbos.dev/python/tutorials/step-tutorial

chucke · a year ago

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.