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

181–190 of 197 posts

Re: Ruby 4.0.0

#181

Post by tasuki »

thunky wrote: post #155
pansa2 wrote: post #70

Earlier quoted context omitted.

> 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 mo…

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

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

Re: Ruby 4.0.0

#182

Post by tasuki »

blandflakes wrote: post #83
jurgenkesker wrote: post #66

Earlier quoted context omitted.

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…

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

Re: Ruby 4.0.0

#183

Post by tasuki »

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?

Re: Ruby 4.0.0

#184

Post by __float »

rco8786 wrote: post #168
anamexis wrote: post #166

Earlier quoted context omitted.

Is Sorbet not what you’re describing? And RBS is officially part of Ruby…

Neither of them integrate annotations into the language. They’re both bolt-ons and it shows, badly. If either of them were good developer experiences one would have caught on. But they’re both way off the beaten path in terms of what engineers expect in a type system and not in a good way. Type annotations in the language as syntax. Static type checker with an emphasis on inference. Compiles into Ruby so that it inte…

You might find https://blog.jez.io/history-of-sorbet-syntax/ interesting, written by one of the primary contributors to Sorbet.

Sorbet is a bit different from TypeScript because it has runtime type checking, not just static.

Re: Ruby 4.0.0

#185

Post by mrinterweb »

pmontra wrote: post #55
mrinterweb wrote: post #15

Earlier quoted context omitted.

There is [RBS]( https://sorbet.org/ ) (part of ruby 3) and [sorbet]( https://sorbet.org/ ). To be honest, these aren't widely used as far as I am aware. I don't know if it is runtime overhead, ergonomics, lack of type checking interest in the ruby community or something else. Type enforcement isn't a big part of ruby, and doesn't seem to be gaining much momentum.

> lack of type checking interest in the ruby community IMHO if we wanted to write types in our programming language we would not have chosen Ruby for our programming tasks. We would have chosen one of the zillion of other languages. There were a lot of them when Ruby got traction about 20 years ago and many other languages have been created after then. It's not surprising that one of the main proponent of typing in R…

I too feel the type safety concern people have with ruby is overblown. The number of actual wrong type related issues I encounter is hardly enough to justify the costs of strong typing. The biggest type issue is with `nil` values and `NoMethodError` on `nil`. Guard clause or safe nav operator is usually sufficient protection for that. That said, I usually don't find myself needing to write that much defensive code for those cases.

Re: Ruby 4.0.0

#186

Post by h14h »

It's not overstating it to say I owe my entire SE career to Ruby.

Without it's accessible syntax, I don't know that I would have ever managed to overcome the initial "I have no idea what's going on" barrier. For whatever reason when I started out I found excess boilerplate & ceremony very overwhelming, and Ruby was the first language where I felt the joy of discovery more often than the frustration of cluelessness.

Although I've found myself gravitating away from object-orientation and towards languages that lean into functional principles, I will always hold a lot of fondness and respect for Ruby. For my brain and learning style, it's hard to imagine a better first language.

It's very cool to see how far it's come since 2.x!

Re: Ruby 4.0.0

#187

Post by RomanPushkin »

blandflakes wrote: post #180
duckydude20 wrote: post #178

Earlier quoted context omitted.

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.

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…

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

Re: Ruby 4.0.0

#188

Post by digitaltrees »

mierz00 wrote: post #177
digitaltrees wrote: post #174

Earlier quoted context omitted.

We might release it as a framework of gems. We created an Abstract controller that handles all of the typical behavior for a resource, auth, filtering, pagination, tenancy, import/export, serialization etc. Then we expanded rails generators to cover ALL typical behavior. And the markdown file calls the generators. It was a bit complicated to model polymorphic behavior but we got it working thanks to Ruby/Rails. But t…

What do the markdown files look like?

Defines the resources, attributes and relationships. That’s it.

Client first_name last_name organization:references

Organization name tax_number has_many:Clients

Re: Ruby 4.0.0

#189

Post by prh8 »

prh8 wrote: post #139
codesnik wrote: post #121

Earlier quoted context omitted.

eh, it's just a little celebration. Let Matz have it.

One issue is gems which are locked `ruby For a more concrete example, the grpc gem locks Ruby versions ( 3.5, whereas we are able to do 3.5-preview1). So unless I feel like doing a lot of grunt work (which I don't), I can't even test Ruby 4 in our app until they release a new version. And while I recognize this is an issue with the gem, it is a consequence of choosing to do 4.0.

For future readers, I mistakenly referenced the grpc gem; I was thinking of the gem `gruf` which is a grpc framework

Re: Ruby 4.0.0

#190

Post by blandflakes »

RomanPushkin wrote: post #187
blandflakes wrote: post #180

Earlier quoted context omitted.

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…

> 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,…

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.
Post reply on HN