Live data from Hacker News

Ruby 2.2.0 Released

ruby-lang.org

21–30 of 82 posts

Re: Ruby 2.2.0 Released

#22
post #9

Ruby seems to continuously move forward. Great to see that they manage to keep this project alive without a python 2vs3 disaster.

Sure, but be aware that if Ruby ever decides to fix the situation with its Strings types/encoding, you'll get the exact same "disaster". At least in the python world this change is now mostly in the past.

Re: Ruby 2.2.0 Released

#23
post #18
post #15

Earlier quoted context omitted.

I'm not sure, most of my Ruby jobs are puppet and chef nowadays.

I promise that puppet and chef are not how the majority of people first hear of Ruby.

That really depends on your field of work. For web developers, maybe not, for admins: yes.

Also, they might not be the thing people hear about first, but they are still heavily driving actual adoption.

(FWIW: I'm chair member of the largest european Ruby non-profit, I speak to a lot of newcomers ;))

Re: Ruby 2.2.0 Released

#24
post #19

Earlier quoted context omitted.

That's what happens when you maintain two versions, one of which has fundamental breaking changes. When the Ruby team makes changes the attitude is generally 'deal with it'. Sure they still do point releases on older versions but only for security issues AFAIK. Python moves forward it just does a poor job of dragging everyone with it.

Sounds about right. Coming from a Python background to Ruby, I think there's more to it though. For example, Ruby version managers such as rvm and rbenv help a lot with keeping the community moving forward. Python has virtualenv but it always felt awkward to me compared to what Ruby has.

You have a plethora of similar tools in the python world as well:

- Pythonz

- Conda

- Pew (disclaimer: I'm the author)

- Virtualenvwrapper

- Pyenv

Etc.

If you argue that people might not move to the latest and greatest as soon as possible due to the fact that people don't build their own interpreter, I can definitely agree with it: python users seem to truly prefer the python version that already comes pre-installed with their linux distribution

Re: Ruby 2.2.0 Released

#25
post #17

Interesting: vfork support. Vfork in most older systems is like fork except it doesn't deeply duplicate all process state immediately (file handles, memory, such), so it can be faster if all the app wants to do is fork/exec. (We had to implement both fork and vfork in minix 2.x in uni.^) But according to SO, most OSes implement fork lazily, so there's not much point in using it when fork will be just as fast without…

Copy-on-write fork is much faster than copying everything, but there is still some overhead setting up the copy-on-write state and dealing with the first writes afterwards, I think in cases where you have large amounts of memory vfork can still be useful.

Re: Ruby 2.2.0 Released

#26
post #19

Earlier quoted context omitted.

Sounds about right. Coming from a Python background to Ruby, I think there's more to it though. For example, Ruby version managers such as rvm and rbenv help a lot with keeping the community moving forward. Python has virtualenv but it always felt awkward to me compared to what Ruby has.

You have a plethora of similar tools in the python world as well: - Pythonz - Conda - Pew (disclaimer: I'm the author) - Virtualenvwrapper - Pyenv Etc. If you argue that people might not move to the latest and greatest as soon as possible due to the fact that people don't build their own interpreter, I can definitely agree with it: python users seem to truly prefer the python version that already comes pre-installed…

> python users seem to truly prefer the python version that already comes pre-installed with their linux distribution

Definitely. It's not that Python doesn't have the tools to switch between versions, but it's not as prevalent as is in the Ruby community. Most Python users will start their program with shebangs like

    #!/usr/bin/env python
or if they want Python 3+

    #!/usr/bin/env python3
while not necessarily using tools like virtualenv and virtualenvwrapper.

I feel like shebangs are not as commonly used in Ruby, instead you use tools and your Gemfile to specify Ruby version.

Re: Ruby 2.2.0 Released

#27
post #9

Ruby seems to continuously move forward. Great to see that they manage to keep this project alive without a python 2vs3 disaster.

Sure, but be aware that if Ruby ever decides to fix the situation with its Strings types/encoding, you'll get the exact same "disaster". At least in the python world this change is now mostly in the past.

What situation is that, out of interest?

As of Ruby 1.9, there's a pretty sensible solution to this in the language, and I haven't had any encoding problems in some time. I appreciate I might have missed something though!

Re: Ruby 2.2.0 Released

#28
post #9

Ruby seems to continuously move forward. Great to see that they manage to keep this project alive without a python 2vs3 disaster.

Sure, but be aware that if Ruby ever decides to fix the situation with its Strings types/encoding, you'll get the exact same "disaster". At least in the python world this change is now mostly in the past.

Can you explain the situation with string types/encodings in Ruby?

Re: Ruby 2.2.0 Released

#30
post #17

Interesting: vfork support. Vfork in most older systems is like fork except it doesn't deeply duplicate all process state immediately (file handles, memory, such), so it can be faster if all the app wants to do is fork/exec. (We had to implement both fork and vfork in minix 2.x in uni.^) But according to SO, most OSes implement fork lazily, so there's not much point in using it when fork will be just as fast without…

Copy-on-write fork is much faster than copying everything, but there is still some overhead setting up the copy-on-write state and dealing with the first writes afterwards, I think in cases where you have large amounts of memory vfork can still be useful.

The point isn't to prematurely optimize for edge-cases, but to tackle real, "hair-on-fire" performance bottlenecks head-on. If that means asking large-scale users to run profiling and getting stats of what's using tons of memory, slowing things down, duplicating work or wasting IOPS, go for it. If it's a dubious return/ effort at the expense of complexity, it might not be worth the investment.

For example, 'FooBarWidget @ Passenger 5 "Raptor" is a well-crafted, thoughtful achievement in terms of app servers.

2.2 Symbol GC also sounds great. I'm just not convinced there is enough innovation to make Ruby an order-of-magnitude faster, use less memory / return memory back to the system.

Post reply on HN