Live data from Hacker News

Ruby: We have decided to go forward to 3.0 this year

github.com

91–100 of 134 posts

Re: Ruby: We have decided to go forward to 3.0 this year

#91

I’m excited about performance improvements but thrilled at the idea of adding types. Has anyone here worked with Sorbet or a prerelease 3.0 in Rails and able to share some notes?

Our team has been using Sorbet at getcensus.com for almost a year now, and I'm generally very happy with it though it's not perfect. Like most non-trivial Rails apps, our test suite takes a while to run, so I like having Sorbet to catch "dumb" issues without having to run the full suite. Running `srb tc` to check types is incredibly fast and seems to be scaling well as our codebase grows. It catches the obvious stuff…

sob on sorbet-rails

j/k. sorbet-rails maintainer here. I agree with the assessment that sorbet doesn't go out of the way to support some Rails feature, eg method overloading or scoping block accurately. Sorbet tool is opinionated about some of the design choices that makes it hard to support Rails' extensive use of meta-programming. That said, Sorbet is still useful in checking the custom code we write on top of Rails and their interactions. It may be hard to type the model files themselves, but we can type-check the code making use of the models! Recently, I started a new project on Rails and it's quite fun building it with type from scratch :D

I find Sorbet a very helpful tool for development. I hope people will give it a try and contribute to tools around it (sorbet-rails included) so that we have great tools to use!

For those who are interested in the topic, I outlined some of the technical challenges with using Sorbet on rails here https://medium.com/czi-technology/static-type-checking-in-ra...

Re: Ruby: We have decided to go forward to 3.0 this year

#92
post #14
post #12

Earlier quoted context omitted.

It sure does blow up your logs if you're using rails with 2.7.1.

Have you updated? Pretty sure all the warnings have been fixed now.

Can't update at work, there's a few breaking changes :/

Re: Ruby: We have decided to go forward to 3.0 this year

#95
post #82

Earlier quoted context omitted.

JavaScript really does take over everything.

I know this is a joke, but we’re legitimately running v8 as a PHP extension in production on high-traffic sites. It’s actually quite good for server-side JS rendering when you’re working inside an existing PHP framework (WordPress, in our case).

Mind linking anything on how you’re doing that? We’d looked into a couple years ago but it seemed quite complicated from a setup perspective.

Re: Ruby: We have decided to go forward to 3.0 this year

#96

Earlier quoted context omitted.

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

most Linux distros still have Python 2 as the default though, right?

CentOS 8 and the latest Fedora doesn't even come with Python 2 installed.

Re: Ruby: We have decided to go forward to 3.0 this year

#97

Earlier quoted context omitted.

At that rate, next you're going to tell us that Go is going to get generics.

Or JavaScript getting a new name. (Or Java getting new maintainers...)

Now you're really dreaming (on both of those).

:-D

Re: Ruby: We have decided to go forward to 3.0 this year

#98
post #70
post #33

Earlier quoted context omitted.

Look for tenderlove’s comments on TruffleRuby. The performance is at the expense of memory.

In Ruby, as in NodeJS, the GIL pushes you to scale horizontally. The memory footprint of Hello World becomes a big problem, because the number of copies you run will be proportional to the number of cores you have, not the number of machines. You get no benefit from moving from an 8 core box to 16 or 20 cores. I suspect if they do manage to pull off more concurrency in Ruby 3, that vertically scaling machines will ma…

NodeJS is single-threaded while Ruby has native threads and "fibers" - what makes you say you wouldn't be able to utilize additional cores in Ruby?

Re: Ruby: We have decided to go forward to 3.0 this year

#99

Earlier quoted context omitted.

most Linux distros still have Python 2 as the default though, right?

No, Ubuntu 18.04 shipped with Python3 as the default.

Not true. Vanilla 18.04 LTS ships with no Python installed by default and the main repos `python` package is 2.7. Same for Debian 10. Ubuntu 20.04 switched the `python` package to Python3.

Even conservative CentOS (where Python is a base dependency for the system, as opposed to the above) is on Python3 as of now though.

As far as I am aware, Debian 10 buster is the last mainstream LTS distro to default to python2. Should change next year with Debian 11.

Re: Ruby: We have decided to go forward to 3.0 this year

#100

Earlier quoted context omitted.

Python3 has really been the norm since 3.4, which was released in 2014. After that it took another year until most major packages were updated to Python3, but that happened at some point in 2015. By 2016 there weren't many packages left that weren't Python3 compatible, or that didn't at least have Python3 replacements.

most Linux distros still have Python 2 as the default though, right?

AFAIK the remaining notable one is Debian. Ubuntu LTS moved to 3 with 20.04.
Post reply on HN