or javascript, that is procedural first rather than asynchronous?
it really bugs me that there isn't one quite like it, i'm just dying for something like that.
or javascript, that is procedural first rather than asynchronous?
it really bugs me that there isn't one quite like it, i'm just dying for something like that.
What’s your issue with symbols in particular? They seem pretty harmless to me.
I know it was in place early on for memory / performance reasons but as of Ruby 2.2, there are zero-performance gains using symbols over strings. Unfortunately it's too late to deprecate them since it's a widely adopted practice.
When I teach Ruby, I try to evangelize how simple Ruby is but always hits the breaks whenever I have to explain Symbols.
And ultimately, no matter how much I try to ignore, I just can't stand how this looks:
opts = { adapter: :mysql}
It looks like a double wall of some sort which is fine for those who are used to it but not for those beginning. (Especially those coming from other languages like Python, PHP, and JS)
Symbols also cause occasional havoc when using 3rd-party libraries because they all have different preference of when to use it and when not to.
So IMO, there are no benefit of Symbols and it just creates confusion more than anything. And that is really the point I am making. I have a hard time reasoning with those PHP/Python folks why Symbol exists and it shouldn't really be that way.
> as of Ruby 2.2, there are zero-performance gains using symbols over strings
This is verifiably false. Run this on a newer Ruby and you will see symbols are faster:
``` require 'benchmark'
hashes = [] 1_000_000.times { hashes << { some_key_name: 1, 'some_key_name' => 2 }} Benchmark.bmbm do |x| x.report { hashes.map{|h| h[:some_key_name]} } x.report { hashes.map{|h| h['some_key_name']} } end ```
But that isn't the reason symbols are useful. They signify intent as a constrained set of alternatives. Strings can take on any value, symbols should be limited to a set of things you know. Strings can be modified in-place, symbols are immutable.
`opts = { :adapter => :mysql }` is perfectly valid for scenarios where you are using symbol values. But the shorthand syntax for symbol keys was added later, and I agree is a bit ugly.
If you are generating symbols from input or from strings then they lose some value.
It is easy to explain the existence of symbols in Ruby especially if you are giving proper merit to the Smalltalk lineage. Erlang also has symbols for a lot of the same reasons and most would agree they are very useful there.
As others have pointed out - this is demonstrably false.
# frozen_string_literal: true
a = ('fo' + 'o').to_sym
:foo == a
b = ('fo' + 'o').freeze
'foo' == b
The second comparison is a 1.5x slower than the former. This is because if a string comparison fails on identity, it then has to check characters. Symbols are always interned so can always stop as the identity comparison.But I actually just like them as they convey intent - a symbol is a string I know about as the programmer. A string is a string that is runtime data.
e.g. you would typically do { id: 1, name: "aboutruby" } where id and name are symbols, instead of { "id" => 1, "name" => "aboutruby" } with strings.
But really I don't see the point of removing the symbols.
You would need to get used to doing some things manually which are automatic in Ruby.