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

New Features in Ruby 2.4

blog.blockscore.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: New Features in Ruby 2.4

#41

Post by windor »

RVuRnvbM2e wrote: post #38
windor wrote: post #27

Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant. Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing. Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?

Have you used concurrent-ruby? https://github.com/ruby-concurrency/concurrent-ruby

Yes, from the beginning, and there exists celluloid which try to implement actor model. The fact that concurrent-ruby cannot be truly parallelized just disappoints me. The same idea of Future,Promise applied to Ruby doesn't gain the benefit. At last, it's just a method of writing 'better' code, not getting better solution.

Re: New Features in Ruby 2.4

#42

Post by xutopia »

windor wrote: post #27

Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant. Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing. Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?

You should check out Elixir. It is heavily inspired by the Ruby language yet makes concurrency easier than many other languages.

Re: New Features in Ruby 2.4

#43

Post by xutopia »

windor wrote: post #27

Ruby is the first language I really like. The core concept of the language is small, just not easy to get, but the change on how to programming is significant. Sadly, Ruby is not the language for the multi-core world, and many advantages of using it is disappearing. Although Ruby is changing, 2.3, 2.4, maybe 3.0, but what's the difference?

You should check out Elixir. It is heavily inspired by the Ruby language yet makes concurrency easier than many other languages.

Re: New Features in Ruby 2.4

#45

Post by sundarurfriend »

mark_l_watson wrote: post #40

Great to see my favorite language evolving! I also use various lisps, Java, Haskell, Typescript, JavaScript, Python, etc., but I am happiest when coding in Ruby. Unfortunately, most of what I do now is machine learning, and Python wrappers for underlying C++ code have by far more support than Ruby. (Ruby does have some great ML projects and libraries though).

I'm on a similar boat, and am eagerly awaiting production-ready releases (and wider adoption) of both Crystal[1] and Julia[2] languages. Crystal for the Ruby-ish syntax, and Julia because it seems to be shaping up into a language I like even more than Ruby.

[1] https://github.com/crystal-lang/crystal [2]

Re: New Features in Ruby 2.4

#46

Post by sundarurfriend »

nazgob wrote: post #30
dkarapetyan wrote: post #9

These are all great but when are we getting optional typing? If the js ecosystem wasn't a clown operation my language of choice would be typescript instead of ruby.

It's not on agenda and it will never happen. There are so many languages with fine typing, why break a dynamic one by adding stuff to it?

> It's not on agenda and it will never happen.

I believe Matz has said that it is on the agenda for Ruby 3.0: that it will have static typing and that it will be optional.

Re: New Features in Ruby 2.4

#47

Post by toolz »

Why do the old match operators now implicitly set a global variable? I feel like in a year I'm going to be debugging some really weird race conditions because of that change and I can't see any value in it...if I want to use the value of a match operator I'll _always_ save it to a local variable.

Can anyone shed any light on this, because my first attempts at grok'ing this change have me really blown away.

Re: New Features in Ruby 2.4

#48

Post by Lukas_Skywalker »

toolz wrote: post #47

Why do the old match operators now implicitly set a global variable? I feel like in a year I'm going to be debugging some really weird race conditions because of that change and I can't see any value in it...if I want to use the value of a match operator I'll _always_ save it to a local variable. Can anyone shed any light on this, because my first attempts at grok'ing this change have me really blown away.

They have been setting the global variable before. This is not a new behaviour. I think it was to match Perls behaviour iirc

Re: New Features in Ruby 2.4

#49

Post by pmarreck »

toolz wrote: post #47

Why do the old match operators now implicitly set a global variable? I feel like in a year I'm going to be debugging some really weird race conditions because of that change and I can't see any value in it...if I want to use the value of a match operator I'll _always_ save it to a local variable. Can anyone shed any light on this, because my first attempts at grok'ing this change have me really blown away.

Ruby has ALWAYS set certain $global_vars based on a match. This borrowed (directly) something that Perl did/does, as well. This is not a new behavior. See docs: http://ruby-doc.org/core-2.2.3/doc/globals_rdoc.html for "global", "predefined" or "magic" variables. That documentation has existed for many, many versions (not just 2.2.3, per the URL).

If you have issue with this sort of thing, you should go to Elixir. ;)

Post reply on HN