Live data from Hacker News

Ruby 2.6

anamaria.martinezgomez.name

121–130 of 164 posts

Re: Ruby 2.6

#121

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…

Groovy. Probably because Groovy borrowed quite a lot from Ruby.

Apache Groovy even borrowed its name from Ruby -- it's really Gruby, if you get what I mean. And of course Grails started off as a clone of Rails.

Re: Ruby 2.6

#122

Earlier quoted context omitted.

I don't think you got that index calculation right. -1 in array of 5 elements is located at 5-1 == 4, not at 1%5 == 1.

I don't follow your point. We're concerned with the value of -1 % 5, not 1 % 5. There's no definition of the modulus operator on which -1 % 5 = 1.

Phrasing issue, I think. I understood "Negative `i` indexes the element" as `i` itself being positive. Like you'd say "negative 1 indexes" (i is 1), not "negative -1 indexes" (i is -1)

Re: Ruby 2.6

#123

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.

I can't type up a full answer right now, but for me, a strong type system is about being able to model my domain and bake all of my assumptions about that domain into the types I define.

It's a lot easier for me to reason about and avoid edge cases when I can (more or less) verify at compile time that invalid states are impossible.

This is about more than just catching null values, and also encompasses things like mutually exclusive fields, and access control.

If you're interested, I gave a talk once that dives into these ideas more effectively than I can express in this comment: https://github.com/ShaneWilton/programming-with-types-talk/b...

Re: Ruby 2.6

#124
post #48

Earlier quoted context omitted.

> CPU intensive ones Truffle Ruby ? https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

From the Truffle readme: > TruffleRuby is progressing fast but is currently probably not ready for you to try running your full Ruby application on. However it is ready for experimentation and curious end-users to try on their gems and smaller applications. > TruffleRuby runs Rails, and passes the majority of the Rails test suite. But it is missing support for Nokogiri and ActiveRecord database drivers which makes it…

> Emphasis mine

Do we think that's what `jb3689` meant by CPU intensive.

Re: Ruby 2.6

#125
post #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?

Blocks are essentially just anonymous functions.

Re: Ruby 2.6

#126
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!

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?

Re: Ruby 2.6

#127
post #81

Earlier quoted context omitted.

Aren't they like arrow functions in JavaScript?

Just parameters that are functions, except that you can only have one per function. I still fail to see the advantage of blocks over being able to pass functions as arguments like in other languages.

One nice feature of blocks is that `return` will return from the enclosing function, rather than the block, so you can write:

    def find(x, l)
      l.each do |y|
        return y if y == x
      end
    end
Where in Lisp you'd use (return-from find x) and in other languages you might pass in a continuation or use a special return value protocol. It's a nice solution for higher order functions that are supposed to feel more language-level.

Also, you can pass functions as arguments like in other languages; lambdas behave like you would expect them to.

Re: Ruby 2.6

#128
post #87

Earlier quoted context omitted.

https://re-find.it ?

I'm talking about the flat namespace.

While I understand the sentiment that all the functions aren't necessarily grouped as in OO languages, I think the Clojure functions are harder to group because they're more general. That's not necessarily the strongest argument, but it is so much more obvious in OO because you always have the object to group by compared to functional languages.

Re: Ruby 2.6

#129
post #106
post #38

Earlier quoted context omitted.

Try Crystal and you get the joy of Ruby enumerables together with a static type system.

Crystal is definitely not production ready, I mean a language without thread support...

Yeah, it’s only now MT schedulers is work in progress to bring multithread fibers to Crystal

https://github.com/crystal-lang/crystal/pull/7214

Re: Ruby 2.6

#130
post #21

Earlier quoted context omitted.

I'm not sure about this being good for coding in non-latin. It might actually encourage behavior to mistreat ruby constants as regular variables. IIRC constants are not really constant, but only visual help for reading code and ruby just issues a warning on reassignment and these warnings are not shown by default. I can totally imagine new devs just trying out non-ascii variables, see it not crashing and then actuall…

> I can totally imagine new devs just trying out non-ascii variables, see it not crashing and then actually writing all their code using constants. Ruby already supported non-ascii identifiers for variables; 2.6 added support for non-ascii first characters of constants, which must still be capital letters, as had always distinguished constants from variables. It doesn't make anything non-ascii a constant, it just mak…

I wasn't aware of non-ascii variables. I was thinking about UTF support for Japanese characters, when I read the change. There is no concept of lowercase/uppercase. 日本語 is this a constant or variable?
Post reply on HN