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

Ruby 3.0.0 RC1

ruby-lang.org

Post reply on HN
Print view View original

111–120 of 133 posts

Re: Ruby 3.0.0 RC1

#111

Post by namelosw »

atomicnumber3 wrote: post #10

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…

> "if you're going to even think about threads, just use Java or go" since concurrency is so nice there.

Concurrency in Java is not very great although there are some improvements in these years. The actor model (Ruby 3 / Erlang) is on par with CSP model (Go) though they have different trade-off and scenarios.

Re: Ruby 3.0.0 RC1

#112

Post by Lio »

derefr wrote: post #53

First pattern matching, and now type-hinting and message-passing actors. Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby? Not to say I’m not grateful! I’m mostly an Elixir dev, but since the Erlang Runtime System sucks at POSIX (bad at pipelines, bad at exit codes, bad at trapping signals, etc.) I personally switch to Ruby when I need a glue language. It…

Much as I'd like to switch to Elixir I see hardly any contracts calling for it right now. i.e. for every 300 or so Ruby gigs there'll be about 2 or 3 Elixir ones.

Ruby will never be Elixir or Erlang but if you can improve an existing thing why wouldn't you? Adding useful features from Elixir/Erlang to Ruby seems worthwhile, even if it doesn't get you all the benefits.

There will likely to be much work that won't be rewritten from scratch that would benefit and money to be made doing so.

Re: Ruby 3.0.0 RC1

#113

Post by pizza234 »

chrisseaton wrote: post #56
lloeki wrote: post #26

Earlier quoted context omitted.

I believe you’re confusing Ruby with Rails. While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic. As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.

> While these can eventually come in handy sometimes, they are by and large seldom used I don't think they are seldom used in practice - I think large parts of the Ruby ecosystem use them pervasively, even if you disregard Rails. But even if we don't agree on that - it's missing the point. The point is you pay for much of Ruby's metaprogramming, even if you aren't using it. So not using it doesn't help you. A concret…

> The point is you pay for much of Ruby's metaprogramming, even if you aren't using it.

I don't think there has been any meaningful attempt at assessing the performance of Python vs Ruby.

If we consider the benchmarks game, their performance is comparable.

I assume that PyPy is faster, but whether to consider it representative of Python's general performance is arguable.

Re: Ruby 3.0.0 RC1

#114

Post by pizza234 »

arp242 wrote: post #20
atomicnumber3 wrote: post #10

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…

I worked with both Python and Ruby daily for several years, both quite a few years ago and now just write the occasional scripts in those languages (small scripts, maintenance of older projects, patches for various projects when needed, etc.) I much prefer Python for this. As an occasional Python/Ruby programmer I find it's just so much easier to work with. Ruby has a lot of features, which is part of its appeal, but…

After five years without programming in a language, one will inevitably forget syntax and/or concepts, that's not something specific to Ruby - there isn't a presence of "sharp corners" more than any other language.

Actually, Ruby's selling point, during the golden times (I guess it was around the mid-2000s), was actually the simplicity and human friendliness of it.

I guess (but it's hard to prove anything in this sense) that Python came out earlier as human-friendly scripting language (1991 vs. 1995), and Ruby didn't provide any killer feature - until Rails came out, but that caused Ruby to "be" Rails, while Python had other areas of application, for example operating system tools.

Re: Ruby 3.0.0 RC1

#115

Post by pizza234 »

pelasaco wrote: post #73
Lio wrote: post #33

Earlier quoted context omitted.

> my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I could see reasons for preferring Java over Ruby but concurrency isn't one of them considering that Concurrent-Ruby running on JRuby gives you access to all of Java's concurrency tooling.[1] 1. https://github.com/ruby-concurrency/concurrent-ruby

you can still go with jruby and have best of both worlds.

I've tried on a project, but incompatibility with some libraries (gems) made it impossible. I guess it's very much like PyPy.

I think parallelism is just not part of the Ruby ecosystem anyway, at least in the present (possibly in the future, who knows).

Rails released officially support for multithreading long ago, but it was broken. And there is a Ruby global lock, anyway (3.0 will have true parallelism, although in alpha).

Re: Ruby 3.0.0 RC1

#116

Post by jeltz »

raverbashing wrote: post #58
jeltz wrote: post #44

Earlier quoted context omitted.

I would argue that is a good thing since it allows for performant access when you do not care about order. If you do not care about order you do usually not even have to allocate an array which means lower memory use. And how hard is it to write. Dir[path].sort Ruby lacks polish in certain areas but this is not one. A d I would argue Python can be pretty tough in places too.

Not that Dir, I mean as in .methods/.instance_methods (or dir(instance) in python ) I fixed it in my original comment

Then I understand your complaint even less. I almost never sort the output from methods and I do not think I have ever sorted the output from instance_methods during my over 10 years as a Ruby developer.

Re: Ruby 3.0.0 RC1

#117

Post by pelasaco »

pizza234 wrote: post #115
pelasaco wrote: post #73

Earlier quoted context omitted.

you can still go with jruby and have best of both worlds.

I've tried on a project, but incompatibility with some libraries (gems) made it impossible. I guess it's very much like PyPy. I think parallelism is just not part of the Ruby ecosystem anyway, at least in the present (possibly in the future, who knows). Rails released officially support for multithreading long ago, but it was broken. And there is a Ruby global lock, anyway (3.0 will have true parallelism, although in…

Well the parallelism issues doesn't exist in the jruby world, but yes, gems with C extensions normally don't work out of the box with jruby, but in another hand you can call java straight from ruby. That's so powerful and often better than the gems - if you know how to right ruby and wrap the java classes with ruby! So as many times said along this thread, ruby isn't rails. I have a project running in a government agency with jruby. It was a port of an old Java SWT application and we rewrote it in jrubyFX. The project was such a pleasure!

Re: Ruby 3.0.0 RC1

#118

Post by ric2b »

dragonwriter wrote: post #103
st1x7 wrote: post #16

Earlier quoted context omitted.

Does some of it feel kind of redundant? I suppose that people have different reasons for learning languages but as someone who knows Python, Ruby is one of the languages on my not-to-learn list since it would neither allow me to work on anything that I can't work on now or introduce some new and interesting language paradigm.

> as someone who knows Python, Ruby is one of the languages on my not-to-learn list since it would neither allow me to work on anything that I can't work on now or introduce some new and interesting language paradigm. Python is a pervasively procedural (to the extent that it likes hiding OO features behind procedural interfaces), statement-oriented programming language with multiple-inheritance style OOP, and a struc…

Meh, as someone with quite a bit of experience with both of them they are very similar, you don't learn much from switching from one to the other, compared to switching to something like C/Haskell/Kotlin.

Re: Ruby 3.0.0 RC1

#119

Post by arp242 »

pizza234 wrote: post #114
arp242 wrote: post #20

Earlier quoted context omitted.

I worked with both Python and Ruby daily for several years, both quite a few years ago and now just write the occasional scripts in those languages (small scripts, maintenance of older projects, patches for various projects when needed, etc.) I much prefer Python for this. As an occasional Python/Ruby programmer I find it's just so much easier to work with. Ruby has a lot of features, which is part of its appeal, but…

After five years without programming in a language, one will inevitably forget syntax and/or concepts, that's not something specific to Ruby - there isn't a presence of "sharp corners" more than any other language. Actually, Ruby's selling point, during the golden times (I guess it was around the mid-2000s), was actually the simplicity and human friendliness of it. I guess (but it's hard to prove anything in this sen…

To be clear, it's not that I didn't write any Ruby for 5 years: I just didn't write a lot of it.

And yes, I've also forgotten plenty about Python; but in Ruby there's just so much more to forget. I've retained much more of my Python knowledge.

Re: Ruby 3.0.0 RC1

#120

Post by Rochus »

Rochus wrote: post #25

In case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... and http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... . I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%). See here for more information abou…

Meanwhile I was able to run the benchmark on MRI Ruby 2.1.0 and compare with 3.0.0 RC1; here are the results: http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub...

Ruby 3.0 RC1 without JIT is factor 1.2 faster than Ruby 2.1.0; Ruby 3.0 with JIT is factor 1.4 faster than Ruby 2.1.0. So definitely less than factor 3.

Unfortunately the benchmark didn't work with Ruby 2.0.

Post reply on HN