alice
Hey,
I’ve listened to a couple tech talks explaining how Ruby was super slow prior to Rails and I am wondering, if Elixir’s syntax is partially inspired from Ruby, how come Elixir is fast? Thanks.
Trending in Discussions
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
Hey folks,
I wanted to share with you a project I’ve been working on for a while: It’s an Open Source (AGPLv3) newsletter tool. Think Ma...
New
Hi there! :wave:
@frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
Fly’s CEO posted this recently - Turn And Face The Strange · The Fly Blog
It says that Fly is going all-in on sprites, which is a worry ...
New
In my third year of college, around 2010, I found Erlang. A few years later, I found Elixir. I liked the ideas at once: many small proces...
New
Hi everyone,
I have 8 years of production experience with Erlang/OTP and I’m just starting to get to know Elixir. What would you learn f...
New
I’ve been tinkering with Lynx (by José) via hold_ledger. I used AI to write the code, a separate specification, the tests, and the Lean p...
New
Other Trending Topics
Hey there,
I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first.
...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly)
AI dream has many faces, but general...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
kokolegorille
Don’t look too much at the syntax, they are completely different…
Ruby is interpreted, Object oriented
Elixir is compiled, Functional language.
If You want speed with Ruby syntax, You might look at Crystal
hauleth
Languages do not have “speed”, never. Implementations of interpreters/compilers have “speed”. And syntax is part of the language, which mean that this do not affect the performance in any way.
lpil
While the syntax is similar more or less everything else works very differently to Ruby, generally in ways that are faster than the approach that Ruby has taken. Thankfully syntax doesn’t have any impact on performance
alice
Hmm, interesting.
But if syntax doesn’t affect performance then why does minifying JS/HTML/CSS code allegedly help with performance?
sfusato
Minifying JS/HTML/CSS code doesn’t help with performance other than the browser can start interpreting it a bit faster (being smaller in size it gets downloaded faster).
NobbZ
Keep in mind, that those languages are also distributed in source, and that syntax does not affect runtime speed, but parsing speed.
And then we also have languages like HTML and CSS that do not have “runtime” speed at all, they are parsed into an internal representation once. Then it’s more or less a static database that gets queried. Only JS makes HTML change, and then the complexity of the databases affect how fast the JS can do it’s job.
lpil
It impacts how long it takes to parse and load the code. In the browser this matters because it happens on every page load! With Ruby or Elixir it doesn’t matter because this happens once before the user has a chance to interact with the program (as it’s not yet serving traffic).
sribe
That’s not really true, as semantics of a language restrict the implementations in ways that deeply affect performance.
For instance in our dynamic languages (Ruby, Erlang/Elixir, Python, Javascript) all “objects” are open maps, which means that every access to an element has to go through some kind lookup. While in C++/Rust/Java, instead of calculating a hash or walking a tree, the same operation is a fixed offset into a single chunk of memory.
Similar differences apply to calling functions. (And modern Javascript JIT goes to great lengths to optimize away those differences; but there are still vestiges of overhead left at runtime.)
hauleth
Still, reflection and run time changes are possible in most of these languages anyway (even in C/C++ as we can clearly see in Erlang via NIFs). So I would still say that in the end, the syntax and semantics have almost no impact on the performance, especially in JITed VMs that are already hot.
sribe
Of course you can build those things in C/C++ (after all, that’s how the BEAM/JVM/Ruby runtimes are built). What you cannot do is get the low-level performance of doing without those in Erlang, Elixir, or Ruby. And you can’t really get them in the Javascript VM, because it still has to allow for the flexibility of change. (As opposed to the Java VM, where you really can get that performance after it’s hot.)
So yes, the semantics of the language absolutely do impose requirements that are reflected in performance, and some of them have huge impacts on performance.