One difference in Java was that you could slice out the middle of a string (you just kept the start and end of the array, iirc). I wonder if that difference makes this approach workable for Ruby, or if that implies that one team made a mistake.
Thanks for the comment! <3
However, I’m not sure I can think through how it changes the performance trade offs of sharing.
If you are trying to reimplement an existing VM/standard library then you may also need to honour the expectations of developers. If they expect creating a substring to be an O(1) operation and code against that expectation then you probably need to honour it.
Also, his talks are excellent; his closing keynote for RailsConf in particular seems worth recommending, as it was about his work speeding up Rails using kind of similar string optimizations/caching:
Granted that's worse that it'd be for MRI, as it includes allocating actual objects even for Fixnum and Symbol (MRI uses tagged values for both and just pretend they're "real" objects), though I added caching for both that cut hundred of thousands of allocations..
1) If you intern all strings, then you're guaranteed to have one copy of "Hello World", which this doesn't (you could concatenate "Hello" and "World" twice).
2) String interning doesn't let similar strings share the same array. The Ruby trick lets you have
So far I’ve been more convinced by Crystal than Elixir as the next language for a Ruby developer.
And that's when the Static Typing Is The One True Way person parachutes in. :)
My suggestions are: simple to average web apps, stay with Ruby (Rails) or Python (Django); complex, look into Elixir (Phoenix.)
I never used Crystal so I can't say anything about it.
I'm curious because my personal experience has been very much the opposite. I've built nothing but small projects using Phoenix, and I've considered it to be a very straightforward companion whenever I've needed to add a web interface to my Elixir apps.
There's not just Phoenix' deceptively Rails-ish approach, but also Elixir as a functional (and somewhat strange?) language, and while you can do without knowing much about OTP, it's not exactly invisible.
On top of that, I find that all the best packages embrace this weirdness. Ecto is wonderful, and by far my favorite 'ORM', but it's very different from the more common ORM's. splitting up the view layer in templates and views is, in my opinion, a step up from the Rails approach. But it took me a while to adjust. The sparing use of macros is also 'weird', but again I find it a step up from what came before.
I kind of feel the same way about Elixir/Phoenix as I do about functional programming in general: Whether it's actually as complicated as it is often said to be or not (perhaps just a matter of 'what we learned first'?), I find that once I got over the hurdle of learning the building blocks and mindset, the stuff I could do felt more fun, more expressive and less brittle, and the approach is starting to infect all the other coding I do.
At the same time I completely understand that if you're comfortable with Rails, and it does the job, or if you use a lot of gems that might not have a (mature) equivalent in Elixir, there's no good reason to bother unless you need channels, perhaps. I have the luxury of being able to use my own tech for many projects, as well as the time available to dive into the Elixir/Phoenix ecosystem.
There is a dedicated contingent promoting Crystal in every thread about Ruby. Don't really know that we need any more (better, perhaps, but not more.)
> Basically Ruby with C performances.
Well, vaguely Ruby-ish syntax, without the dynamic features or ecosystem, and with a static type system.
> So far I’ve been more convinced by Crystal than Elixir as the next language for a Ruby developer.
Not sure what that has the do with the subject here, which has nothing to do with either Elixir or the next language for a Ruby developer.
Language (or tool) evangelism with no connection to be thread beyond offering an alternative to a language mentioned in the thread is basically a uniquely geeky form of threadcrapping, and its really not any better than any other threadcrapping.
Go to Elixir if you actually want to learn more, expand your mind, and are tired of bugs that can only occur in a mutable OOP language. And if you want to take advantage of the extra guarantees provided by a functional language, such as functional immutable datastructures making concurrency idiotproof.
Maybe rein it in a bit.
Seriously, try converting over a decently complex script to crystal from ruby, you'll run into complicated problems.