Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 4.0.0

ruby-lang.org

Post reply on HN
Print view View original

191–197 of 197 posts

Re: Ruby 4.0.0

#191

Post by blandflakes »

tasuki wrote: post #182
blandflakes wrote: post #83

Earlier quoted context omitted.

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…

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

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

Re: Ruby 4.0.0

#192

Post by digitaltrees »

tasuki wrote: post #183
digitaltrees wrote: post #29

Ruby is amazing. I recently built a layer on top of Rails that can generate an API from a single markdown file. I did the same thing in python but it was much harder and JavaScript would have been a beast. Ruby can meta program like nothing else.

> Ruby can meta program like nothing else. Have you heard about Lisp?

(((((((Heard)))))))

I might have forgotten a (

Ruby is clean. Which I love.

Re: Ruby 4.0.0

#193

Post by zingar »

qaisjp wrote: post #163
zingar wrote: post #144

Earlier quoted context omitted.

Very curious to hear about the specific cases where types make tests unnecessary. I spend my working life swapping between Ruby and typescript projects and the typescript project is utter garbage with poor test coverage that needs a day of human QA for every build whereas the Ruby project is well tested such that we know that CI passing means it’s good to be released.

Types don't make testing in general unnecessary, but it removes a class of error handling that runtime type checking handles for you. You can really trust the types when using Sorbet. (I also work in a 40m+ loc non-rails ruby codebase that is almost entirely typed with Sorbet.)

Haha “tell me you work at Stripe without telling me you work at Stripe”

Re: Ruby 4.0.0

#194

Post by tasuki »

digitaltrees wrote: post #192
tasuki wrote: post #183

Earlier quoted context omitted.

> Ruby can meta program like nothing else. Have you heard about Lisp?

(((((((Heard))))))) I might have forgotten a ( Ruby is clean. Which I love.

Lisp is the cleanest language out there! It has one construct: parentheses. It's simpler than Ruby.

Wrt "forgetting" parentheses, the Lisp people have ways around that: they set up their editors so they operate on the expressions and can't "forget" a paren. They operate on the logical blocks (which is easy (because of the parentheses)).

Re: Ruby 4.0.0

#195

Post by empthought »

aobdev wrote: post #123
empthought wrote: post #72

Earlier quoted context omitted.

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?

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.

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.

Re: Ruby 4.0.0

#196

Post by zingar »

danmaz74 wrote: post #150
zingar wrote: post #145

Earlier quoted context omitted.

Interesting: how is CC in your experience at writing tests and then using them to avoid mistakes?

When writing non-vibe-coded software I use CC a lot to write tests, but I have a skill to tell it not to create redundant tests, which otherwise it tends to do, and I have to check them anyway to ensure that they cover what needs to be covered, and sometimes to trim them down. When vibe coding, what I noticed is that CC tends to make mistakes which it does catch with tests and fix on its own, but my hope is that usin…

Very interested to read the blog post about the results.

Re: Ruby 4.0.0

#197

Post by lern_too_spel »

nirvdrum wrote: post #162
lern_too_spel wrote: post #141

Earlier quoted context omitted.

Everything being mutable by default, including strings, is about as big a foot gun as you can find in a high level language.

Having immutable objects by default isn’t incredibly commonplace outside of functional languages. It certainly isn’t unique to Ruby and seems out of place in a discussion comparing Ruby to Python. Fortunately, you can defensively freeze any objects you’re passing around to avoid the most common issues with mutable objects. Immutable strings is a more popular programming language feature and Ruby has a mechanism for o…

> With that said, the magic comment is a wart

Not only a wart but a massive foot gun, not shared by any other language, as I said. It is incredibly common to create hash tables using strings as keys, and Ruby makes this dangerous by default.

> Having immutable objects by default isn’t incredibly commonplace outside of functional languages

They make it easy to create immutable objects. Python has tuples and immutable data classes. Strings are immutable.

> The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.

In the meantime, this ridiculous foot gun that no other language shares exists. That is a fact, and the fix being hard does not make it any less of a fact.

Post reply on HN