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

Ruby 2.6

anamaria.martinezgomez.name

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Ruby 2.6

#141

Post by akjha »

ken wrote: post #83
tyre wrote: post #59

Earlier quoted context omitted.

Not having `nil` is soooo nice. I can't count the number of `Runtime Error`s because some method isn't defined on `NilClass` that have blown things up in weird edge cases. Knowing exactly what types a method takes and the compiler catching incorrect uses before the code ever runs saves a lot of frustration. Another thing I've enjoyed in Rust include `match` clauses forcing me to define branches for any possibility, e…

There's got to be more to it than "has / doesn't have nil". Lisp has nil, and I rarely if ever see an analogous error there, or even a type error. I have a hunch that single/static dispatch is what tends to cause more problems than merely the presence of nil. It's not nil, but how you use it.

"It's not nil, but how you use it."

Can you elaborate on how multi-dispatch reduces the issue of nil/null?

I also use static type (typescript) to prevent issues with nil and would like to know how I can achieve the same in a dynamic language.

Re: Ruby 2.6

#142

Post by gaius »

alfredmuffin wrote: post #2

Is it a good time to learn Ruby? I mostly do React and Node + Java work professionally, but I've been looking into Ruby as a fun side project language. I would appreciate any anecdotes!

Is it a good time to learn Ruby? I mostly do React and Node + Java work professionally

It can be fun and it's as close as Smalltalk will probably get to mainstream acceptance, but if you are hoping for a lucrative commercial skill then probably you have missed the boat. Ruby is mainly used for two what most would now consider legacy things, Rails based websites and Chef based infrastructure. There is still some money to be made in maintenance of course and will be for a few years but the sun is definitely setting on Ruby. But 10 years ago it was super-hot.

Re: Ruby 2.6

#143

Post by int_19h »

ravenstine wrote: post #136
mikekchar wrote: post #126

Earlier quoted context omitted.

I'm not so sure about the block thing. I mean I like having first class function-like objects, but you've got blocks and procs and both of these are different from bound and unbound methods. I would prefer that there was a single function type, personally. I wonder if I'm missing something, though. Is there an advantage to distinction between blocks and procs that ruby makes?

A block is a proc. ```ruby def foo &bar return bar end foo {} # => # ``` But I do agree that I don't quite understand the need for the distinction between procs and methods, or the need for unbound methods; I would think that methods could just be either bound to one object or another, as unbound methods are useless for the fact that they won't work at all unless they are bound.

I think they rather meant the difference between procs and lambdas (e.g. wrt return).

Re: Ruby 2.6

#144

Post by JamesAdir »

Lordarminius wrote: post #103

Fantastic Christmas present from the Ruby team. Ruby is alive and well despite all the rumors of it's demise. I predict a resurgence in its use over the next few years. Can't wait to examine and try out the new features.

What makes you think there'll be a resurgence in its use in the next few years?

Re: Ruby 2.6

#145

Post by int_19h »

yxhuvud wrote: post #111
Redoubts wrote: post #76

Earlier quoted context omitted.

Languages without ADTs and Optionals just feel impoverished.

Languages without full blown union types feel so impoverished. With good language typing support (including flow typing), optionals feel quite redundant.

But optionals are just a union type (T | None).

Re: Ruby 2.6

#146

Post by klohto »

mmahemoff wrote: post #112
ajmurmann wrote: post #104

Earlier quoted context omitted.

It's mostly how complete the API is and how consistent. For example: * Hash#merge takes a block for conflict resolution. I use this all the time for aggregating counts. * #sample * #unique * Everything has a change in place option by appending "!"

Also, chaining is extremely concise. e.g. "products.map(&:cost).sort.last"

I couldn't resist...

Your example could be improved by using "products.sort_by(&:cost).last"

I try to not use map because often there are methods that already implement filtering. Gotta love Ruby readability.

Re: Ruby 2.6

#147

Post by buckysock »

jashmatthews wrote: post #133
buckysock wrote: post #131

Earlier quoted context omitted.

Thread support in interpreted languages isn’t that parallel to begin with.

JRuby threads are fully parallel and in production use today. CRuby's GIL is an implementation choice rather a property of dynamic/interpreted languages.

I’m wondering.. what is the effect of letting the JVM handle synchronization then ? Wouldn’t they still need to synchronize within JvM ?

Re: Ruby 2.6

#149

Post by lloeki »

alfredmuffin wrote: post #2

Is it a good time to learn Ruby? I mostly do React and Node + Java work professionally, but I've been looking into Ruby as a fun side project language. I would appreciate any anecdotes!

As a Ruby dev on the hiring market until recently Ruby seems to be in kind of the same spot as Perl some time ago: many new/existing Ruby/Rails projects are around, so it's kind of mainstream but not as much as PHP/Node/Java/whatever is which means less job offers, yet not quite niche neither, and there seems to be kind of a slight lack of Ruby devs around, and it can act as a differentiator, even for non-Ruby jobs. There's quite an interesting market dynamic at play here.

Re: Ruby 2.6

#150

Post by viraptor »

jashmatthews wrote: post #133
buckysock wrote: post #131

Earlier quoted context omitted.

Thread support in interpreted languages isn’t that parallel to begin with.

JRuby threads are fully parallel and in production use today. CRuby's GIL is an implementation choice rather a property of dynamic/interpreted languages.

Is it really a "choice" if the alternative is really hard to achieve in practice? It's like calling python's GIL a choice... with numerous projects trying to get rid of it in various ways and never really succeeding to do it while keeping the single threaded performance and the extensions API.
Post reply on HN