Hacker News Reader

Comment by dorianm | Hacker News Reader

For comparaison, Ruby 3 is gonna introduce a pretty big breaking change (frozen string literals) but they already shipped a way to optional enable it by-file (magic comment) and globally to the ruby interpreter (just a parameter) so that all the libraries and projects can slowly fix it in a compatible manner (often just calling .dup is enough).

So that's when it's time for Ruby 3 the transition will be pretty painless.

More info: https://wyeworks.com/blog/2015/12/1/immutable-strings-in-rub...

(Frozen string literals allows strings to be in memory only once and not having to reallocate each time, so a pretty big memory and cpu optimization)

(Also for instance rubocop already recommends adding the magic comment to all ruby files)

View on HN

(Frozen string literals allows strings to be in memory only once and not having to reallocate each time, so a pretty big memory and cpu optimization)

Isn't this the purpose of symbols in the language? This seems like a pretty basic optimization, surely there were good reasons not to introduce it in earlier versions.

e.g. 1000.times { "hello" } creates strings 1000 times but: 1000.times { "hello".freeze } only one time.

The thing about frozen strings is they can't be changed "inline":

e.g. : "Hello".freeze << " world" doesn't work but "Hello".freeze + " world" does because it creates a new string.

(It's funny because << is often recommended as an optimization)

Magic imports from __future__ are the usual way of turning on features in Python.

The incompatibilities introduced in Python 3 weren't done that way to save on implementation effort among other reasons.

Maybe python2 --enable-print-parentheses and other flags could have been useful to slowly detect future issues on python 2 code.

Python 2.6 has from __future__ import print_function.

There the saving of implementation effort would be not supporting print statements in 3.0.

Nice it actually gives "SyntaxError: invalid syntax", but then it affects all the imported libraries so I still prefer the per-file way as a transition.

__future__ imports are per file. A few posts up you were proposing an interpreter-wide switch. Did you change your mind?

Awesome. I think both are great, first doing file-per-file and once it's working switching the global switch is a pretty good transition workflow.

This is a quite good example about myself. After I realized that too many people around Ruby do not understand the concept of immutability, I stopped to care about the whole ecosystem around it.

If this catches up, it is worth to give the Ruby a fresh look.

There are a few immutability options, for instance Hamster: https://github.com/hamstergem/hamster/blob/core/README.md

Reply on news.ycombinator.com