Elixir is often said to have similar syntax to ruby but this is overstating it -- Elixir chooses a similar set of tokens in its grammar to Ruby ('def', 'if', na

Elixir is often said to have similar syntax to ruby but this is overstating it -- Elixir chooses a similar set of tokens in its grammar to Ruby ('def', 'if', naming rules, list/array literal delimiters, atoms/symbols, map keys) but the actual higher level syntax for the most part is very different. (And obviously the semantics have nearly nothing in common as others have mentioned.) Some clear syntactic differences (that clearly show that the design decisions were driven by building a good language over erlang, that happens to tokenize similarly to ruby, not a ruby-looking erlang powered language): - ruby uses sigils on variables to confer metadata, no similar syntax in Elixir on bindings - access modifiers are different (private vs defp) - map syntax is different (%{} vs {}), tuple syntax doesn't exist in ruby. (could have been swapped if ruby-syntax was a higher goal vs idiomatic erlang being the driving motive) - function definition syntax is slightly different, but arguably more consistent in Elixir (no do in ruby) - most of the control flow operations in ruby do not exist as macros in elixir, or have wildly different syntax and vice versa. the only exception i can think of is the humble "if" statement, which is generally avoided in elixir if it can be anyhow - closures and anonymous function syntax greatly differ - the entire syntax of pattern matching and deconstruction in elixir does not exist in ruby - no ternary operator in elixir - pipelines are central to elixir, no syntax in ruby I think Elixir's successful adoption by ruby programmers despite having nearly nothing in common with ruby than a similar choice in tokens for parsing (and even then, only when erlang doesn't pull in a different direction) show that just choosing similar tokens to a language can be a good strategy to enticing developers from that language without actually having to make any impactful design decisions (in either syntax or semantics) to favor that goal over others.