Live data from Hacker News

Ruby 2.6

anamaria.martinezgomez.name

81–90 of 164 posts

Re: Ruby 2.6

#81
post #42

This will be fun. I’m glad we now have some performance improvements to some common methods. For those considering playing with Ruby, you should! One thing I’m surprised not many has mentioned what makes ruby unique and awesome, BLOCKS!

Aren't they like arrow functions in JavaScript?

Re: Ruby 2.6

#82

Ruby used to be my most beloved language. I've since developed a strong appreciation for good type system. However, working with collections of any kind in Ruby is just such a joy. The methods around it are so well thought throug and make writing code a joy that in most other languages just would be tedious. On top of that the Ruby team is constantly working on making that aspect even better. I truly don't understand…

Can you comment on why a good type system became so important to you? I can understand the value in interfaces but not really in any other context.

The === for Range and Datetime serves as a one example, with a good type system they wouldn't be directly comparable.

Re: Ruby 2.6

#83
post #59

Earlier quoted context omitted.

Can you comment on why a good type system became so important to you? I can understand the value in interfaces but not really in any other context.

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.

Re: Ruby 2.6

#84

What is the complexity of set operations on arrays? This seems a bit too much sugar to me, to the point where people will end up writing inefficient code because they will thing these methods are more performant than they really are. Usually, I like to see explicit conversions to sets to make the performance characteristics explicit.

In most real world applications, the cost of doing an in-memory data manipulation like this is negligible compared to I/O, waiting for the database etc. It's already the wrong language for someone who wants to squeeze out every CPU cycle, and imo it's a Good Thing for a language upgrade to embrace its strengths ie syntax sugar in the case of Ruby, as long as the perf hit isn't out of control. I'd agree developers sho…

I might be more receptive to this if this was added to all collections, then, rather than just arrays. (Maybe it was? I don’t write Ruby, so I don’t know for sure. Maybe Ruby doesn’t have a generic “collection” protocol?)

Re: Ruby 2.6

#85

Ruby used to be my most beloved language. I've since developed a strong appreciation for good type system. However, working with collections of any kind in Ruby is just such a joy. The methods around it are so well thought throug and make writing code a joy that in most other languages just would be tedious. On top of that the Ruby team is constantly working on making that aspect even better. I truly don't understand…

The only collection I wish Ruby improved upon is a simple Lisp style linked list. Kind of amazed JS has an easier way to do cdr than Ruby: const list = [ 1, 3, 4, 2, 8, 5]; const [fst, ...snd] = list; But I suppose that's just a result of JS implementing pseudo-pattern matching.

    head, *tail = *list
Has worked since 1.8. Don't ask me how I know that :-P

Re: Ruby 2.6

#86

Ruby used to be my most beloved language. I've since developed a strong appreciation for good type system. However, working with collections of any kind in Ruby is just such a joy. The methods around it are so well thought throug and make writing code a joy that in most other languages just would be tedious. On top of that the Ruby team is constantly working on making that aspect even better. I truly don't understand…

The only collection I wish Ruby improved upon is a simple Lisp style linked list. Kind of amazed JS has an easier way to do cdr than Ruby: const list = [ 1, 3, 4, 2, 8, 5]; const [fst, ...snd] = list; But I suppose that's just a result of JS implementing pseudo-pattern matching.

How is this different than splatting (my lisp is not so great.)?

https://repl.it/repls/EcstaticLamePaint

Re: Ruby 2.6

#87

Earlier quoted context omitted.

what bout clojure?

Clojure's stdlib is unintuitive, and `into` is the poster child. It's easy to find what's available in Ruby: https://ruby-doc.org/core-2.5.3/Enumerable.html Good luck with Clojure: https://clojure.github.io/clojure/clojure.core-api.html

https://re-find.it ?

Re: Ruby 2.6

#88

What is the complexity of set operations on arrays? This seems a bit too much sugar to me, to the point where people will end up writing inefficient code because they will thing these methods are more performant than they really are. Usually, I like to see explicit conversions to sets to make the performance characteristics explicit.

> This seems a bit too much sugar to me, to the point where people will end up writing inefficient code because they will thing these methods are more performant than they really are.

Real-world performance and asymptotic complexity aren't the same thing.

> Usually, I like to see explicit conversions to sets to make the performance characteristics explicit.

The performance problem with this approach (for certain problems) when you have input arrays and want an output array is that Array->Set and Set->Array conversions are not free, and even if this is better in asymptotic complexity, you aren't always operating at the extends where asymptotic complexity dominates, so you can end up with code that is both excessively verbose and unnecessarily nonperformant just to make asymptotic complexity more apparent.

Re: Ruby 2.6

#89

Earlier quoted context omitted.

The only collection I wish Ruby improved upon is a simple Lisp style linked list. Kind of amazed JS has an easier way to do cdr than Ruby: const list = [ 1, 3, 4, 2, 8, 5]; const [fst, ...snd] = list; But I suppose that's just a result of JS implementing pseudo-pattern matching.

head, *tail = *list Has worked since 1.8. Don't ask me how I know that :-P

Damn, I should have remembered that. Especially considering I had a project where I had to trawl through the ruby parser including multiple assignment rules.

Re: Ruby 2.6

#90

Earlier quoted context omitted.

Depends what you want to do, 90% of what I code in is python or Ruby, and I'll switch to C when I want performance. I've done a lot of rails (Ruby), Django (python), and flask (python) work in web development. Much prefer rails, eaiser, and better thought out. I have several websites with hundreds of thousands of visits a year, it is fine (all the frameworks are). I have had to do some inline C to speed up my Ruby in…

You should give crystal a go for the parts you need to be performant! You can even prototype those parts in ruby and easily convert to crystal when it becomes necessary. We’ve found a really nice balance, with business logic and interfaces in Ruby/Rails and crystal for AI/data processing.

Oooh, that sounds interesting. Where would be a good place to start with Crystal assuming I specifically want to use it for AI/data processing with Rails business logic / interfaces?
Post reply on HN