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

91–100 of 133 posts

Re: Ruby 3.0.0 RC1

#91

Post by cutler »

vinceguidry wrote: post #51
lukeschlather wrote: post #45

Earlier quoted context omitted.

Well, the problem is that Rails (and ActiveSupport) is borderline idiomatic Ruby. I imagine the vast majority of Ruby codebases use them. And honestly I don't even know how vanilla Ruby stacks up to Python, it's almost an inconceivable idea (though I left Ruby behind some years ago.)

Rails is dominating Ruby less and less every year. There are plenty of alternative web frameworks to use, and Rails is a really heavy-weight thing to include if you're not building a website. I'll pull in an ActiveSupport module every once in awhile but so few of the things I write are websites that need Rails.

There's no evidence for this in the job market. Most Ruby jobs are Rails jobs.

Re: Ruby 3.0.0 RC1

#92

Post by dragonwriter »

raverbashing wrote: post #70
ben-schaaf wrote: post #64

Earlier quoted context omitted.

> .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list This seems like an odd complaint: Both languages use hash maps to look up methods/attributes, which aren't inherently sorted. Looking at the implementation `dir` in python does an explicit sort, which just seems like arbitrary behaviour.

It's not an arbitrary behaviour if you want a well behaved result from it. Same with Python dictionary keys which used to have no intrinsic ordering. Especially when dir() is more used in interactive applications (and sure, sometimes programatically like in plugin architectures, etc)

Because Ruby uses fairly deep metaprogramming much more, idiomatically, than does Python, while “dir() is more used in interactive applications” may be true, that does not imply that “#methods is more used in interactive applications”. And, anyhow, an interactive application that wants the information it asks for will quite often wan’t to impose an organization other than alphabetic ordering.

Re: Ruby 3.0.0 RC1

#93

Post by PointyFluff »

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…

It's a mish-mash language like perl and should die the same death.

Re: Ruby 3.0.0 RC1

#94

Post by spaced-out »

izietto wrote: post #13

I really dislike this: {b: 0, c: 1} => {b:} p b #=> 0 It is so weird that a variable named `b` is initialized after an hash-key-like symbol is referenced (`b:`). It's something you've never seen in Ruby before and that I hope I'll never encounter along my career as Ruby on Rails developer.

Does anyone know the reasoning for adding this? The link doesn't discuss that. As someone who worked primarily in Ruby ~5 years ago, it just seems like useless complexity to me.

Re: Ruby 3.0.0 RC1

#95

Post by pjmlp »

cutler wrote: post #90
abernard1 wrote: post #48

Earlier quoted context omitted.

Totally. Another thing is that outside of scientific data applications, ordinary data processing apps at scale have been map-reduce for a long time. That's an inherently functional paradigm that's closer to Python. Having parallelized heavily OO Ruby code across machines by unrolling it into functions that could be sent data payloads... that's not a fun thing to sell in an OO culture. In Python you're kind of already…

Functional paradigm closer to Python? I think you mean procedural as Guido has openly professed his distaste for all things functional to which Python's crippled lambdas bear witness. Ruby, on the other hand, with its procs, blocks and lambdas, supports an elegant functional style even if it is implemented in OO.

All of which go back to Smalltalk blocks and collections.

As for Python, Guido might not like it, but Python has enough features to do FP, in spite of crippled lambdas.

Re: Ruby 3.0.0 RC1

#96

Post by pjmlp »

abernard1 wrote: post #65
mumblemumble wrote: post #60

Earlier quoted context omitted.

I don't think that would really be too bad, TBH. Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project. All you really have to do to translate map and reduce into an OO paradigm is have the map and reduce operations take objects that implement specific interfaces instead of functions that have a certain signature.

> Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project. Yeah, but that required everybody learning a different style of programming that wasn't OO ;-). The problem is for "map", you have to get rid of shared state and the interleaving of state and time. Interleaving state and time is basically the only thing objects do beyond providing a namespace and polymorphism. Ther…

Smalltalk collections have map reduce, and it is as OOP as it gets.

Re: Ruby 3.0.0 RC1

#97

Post by pjmlp »

bestinterest wrote: post #82
sandGorgon wrote: post #23

I look at Ruby and I think of Dart. Not from language semantics perspective..but specialisation in a very narrow usecase and around DX. But really unbeatable in that usecase. all racehorses are one-trick really.

I feel sort of similar for most languages, low level? Rust/C/C++ 'corporate' work? Java/C# Android? Kotlin iOS? Swift ML / Data statistics? Python

Which is why the best option is to be polyglot and not silo as "X Developer".

Re: Ruby 3.0.0 RC1

#98

Post by abernard1 »

cutler wrote: post #90
abernard1 wrote: post #48

Earlier quoted context omitted.

Totally. Another thing is that outside of scientific data applications, ordinary data processing apps at scale have been map-reduce for a long time. That's an inherently functional paradigm that's closer to Python. Having parallelized heavily OO Ruby code across machines by unrolling it into functions that could be sent data payloads... that's not a fun thing to sell in an OO culture. In Python you're kind of already…

Functional paradigm closer to Python? I think you mean procedural as Guido has openly professed his distaste for all things functional to which Python's crippled lambdas bear witness. Ruby, on the other hand, with its procs, blocks and lambdas, supports an elegant functional style even if it is implemented in OO.

So I'm using a simple, deliberately not correct version of "functional" because a lot of people don't know the difference.

I don't like it when people break out their monocle and pipe and complain about this or that being true functional :-). I really do just mean "procedural functions + return by value instead of mutation" here.

It is completely normal to have a python script that is just ordinary functions, without state being enclosed in a class and accessed via `self`. This "My First Program" behavior scales extremely well, both from a parallelism perspective, as well from a complexity perspective. OO features can be applied iteratively on top of that.

With Ruby--syntax aside--it is just very rare to see people only write functions or private_class_methods. The "Everything is a Class" mantra is very strong, and there's lots of rich behavior in Ruby attached onto what would be considered primitives or basic structs in Python.

With data science specifically, this natural way of pushing simple procedures, primitives, structs from Python down into C has lots of performance benefits. Because those functions are "flat", you don't have to traverse the call stack routinely and lose performance there.

Re: Ruby 3.0.0 RC1

#99

Post by abernard1 »

pjmlp wrote: post #96
abernard1 wrote: post #65

Earlier quoted context omitted.

> Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project. Yeah, but that required everybody learning a different style of programming that wasn't OO ;-). The problem is for "map", you have to get rid of shared state and the interleaving of state and time. Interleaving state and time is basically the only thing objects do beyond providing a namespace and polymorphism. Ther…

Smalltalk collections have map reduce, and it is as OOP as it gets.

Parallelize smalltalk collections across multiple machines without a distributed coordinator (reduce). Even the pedantic original version of smalltalk OOP has this problem.

map-reduce and functions do not require coordination until reduction. map doesn't require a serialized mailbox (like actors), or worrying about ordering in time. Smalltalk requires a consistent state and the location of where to send messages is important. Distributed map is stateless. All versions of OOP concern themselves with state encapsulation, whereas map is state elimination. map is functional.

Re: Ruby 3.0.0 RC1

#100

Post by pjmlp »

abernard1 wrote: post #99
pjmlp wrote: post #96

Earlier quoted context omitted.

Smalltalk collections have map reduce, and it is as OOP as it gets.

Parallelize smalltalk collections across multiple machines without a distributed coordinator (reduce). Even the pedantic original version of smalltalk OOP has this problem. map-reduce and functions do not require coordination until reduction. map doesn't require a serialized mailbox (like actors), or worrying about ordering in time. Smalltalk requires a consistent state and the location of where to send messages is i…

Smalltalk map reduce works across VM processes, there is nothing in CS literature that requires map reduce to be a cluster only algorithm.
Post reply on HN