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

Ruby 3.0 Preview 1

ruby-lang.org

Post reply on HN
Print view View original

61–70 of 207 posts

Re: Ruby 3.0 Preview 1

#61

Post by chrisoverzero »

reader_mode wrote: post #17

>Rightward assignment statement is added. >fib(10) => x This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a…

>.NET went with non-standard SQL-like names (select/where) […]

Which names do you believe are standard?

Re: Ruby 3.0 Preview 1

#62

Post by burlesona »

wrp wrote: post #59
reader_mode wrote: post #17

>Rightward assignment statement is added. >fib(10) => x This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a…

Ruby has been referred to as Smalltalk meets Perl, and the problem of dealing with other people's code is one of the main things that kept me in the past from using Perl on text processing projects. The problem of collaborating in Perl was lessened a lot by adhering to Damian Conway's Perl Best Practices. Is there anything similar for Ruby?

Rubocop and you're done. It's the first thing I'd add to any team project just because life's too short for an inconsistent codebase.

Re: Ruby 3.0 Preview 1

#63

Post by andoriyu »

jasonhansel wrote: post #29

Question: will the nonblocking scheduler start to make Ruby concurrency competitive with e.g. Node.js and Go? Currently Ruby mostly uses heavyweight threading mechanisms that cause trouble for I/O-bound microservices.

Well, ruby was able to be concurrent for a while now. It has lightweight cooperative threads, it has reactor loops. The problem was/is/will be - lack of gems that support either of them.

EventMachine was a nightmare to work on and to work with, but with fibers it and some wrappers you could write some neat code. Most library were making a lot of bad assumptions - "there is a GIL and i'm running on a full thread and also wtf are threads in general, never heard of it?"

Almost no one in ruby world thought about writing a better code to make application faster, it was always about either finding a better gem or adding more application servers. Here is the closest ruby has been towards concurrency https://github.com/igrigorik/em-synchrony guess why it never took off.

Ruby 3.0 is a first step towards having libraries being aware that they are in on fiber and not thread.

Re: Ruby 3.0 Preview 1

#64

Post by philwelch »

reader_mode wrote: post #17

>Rightward assignment statement is added. >fib(10) => x This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a…

Ruby can also be an extremely decision-fatiguing language to write code in.

Re: Ruby 3.0 Preview 1

#65

Post by philwelch »

chrisoverzero wrote: post #61
reader_mode wrote: post #17

>Rightward assignment statement is added. >fib(10) => x This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a…

>.NET went with non-standard SQL-like names (select/where) […] Which names do you believe are standard?

Not who you’re responding to but from context I would assume map/filter, as he said.

Re: Ruby 3.0 Preview 1

#66

Post by rco8786 »

This is all great stuff. I’m rather meh on RBS, mainly because separating types from code is less than ideal but I like the potential here.

But the right hand assignment operator. What on earth. Nobody asked for that and nobody wants it. Why.

Re: Ruby 3.0 Preview 1

#67

Post by rpastuszak »

chrisoverzero wrote: post #61
reader_mode wrote: post #17

>Rightward assignment statement is added. >fib(10) => x This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a…

>.NET went with non-standard SQL-like names (select/where) […] Which names do you believe are standard?

Arguably, select/where are less familiar than map/filter to many. I'm not saying that either is a standard, but I can imagine the confusion if you come from say, JS background.

Re: Ruby 3.0 Preview 1

#69

Post by djur »

rco8786 wrote: post #66

This is all great stuff. I’m rather meh on RBS, mainly because separating types from code is less than ideal but I like the potential here. But the right hand assignment operator. What on earth. Nobody asked for that and nobody wants it. Why.

What's strange is that it seems to have been an offshoot of the pipeline operator (|>) work from last year[1], which was originally proposed as having an assignment syntax like

  foo |> bar(20) |> (x)
where x is assigned to. People didn't like that syntax, and there were issues with = being higher precedence than |> [2]. This new right-assignment operator was created in response to that [3].

The weird thing is that the pipeline operator got killed, so the original reason for r-assign no longer exists. It looks to me like there's just some people on the Ruby team who took a shine to it.

[1]: https://bugs.ruby-lang.org/issues/15799 [2]: https://bugs.ruby-lang.org/issues/15799#note-22 [3]: https://bugs.ruby-lang.org/issues/15921

Post reply on HN