3 ms·
I've used both Go and Elixir so here's my thoughts: Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a
by rubiquity 11y ago
I've used both Go and Elixir so here's my thoughts:
Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all taken care of at compile time.
Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't.
As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang.
If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].
- bpicolo 11y agoYou can handle misspelled variables/bindings/function names in Ruby/Python/JS by linting. That's a class of errors that's easy to avoid anywhere with a good text editor.
- 15155 11y agoDue to the extremely dynamic nature of Ruby, I'm not aware of any linter that can catch misspellings when interacting with class or instance variables, dynamically-defined methods, etc. It's an entirely different level of statically-verifiable correctness.
- bpicolo 11y agoI know of class/instance variables working for py linters. Dynamically-defined methods, no, but those are hard to reason about even for humans so it's best to avoid them entirely.
- lobster_johnson 11y agoPattern matching will only get you so far without static analysis, though? For example, if I have a function that returns {foo}, and I change it to return {foo, bar}, then a pattern match on its return value that does {Foo} -> ... will fail at runtime, and the compiler won't pick it up, right? In a statically type language (such as Go), changing the number (or type) of return values will result in compilation errors until all callers have been updated.