> Steve: We chose Elixir because we were looking for a system that was easy for programmers to understand and could take better advantage of our servers. I was intrigued at Elixir’s combination of friendly syntax, powerful metaprogramming features, and incorporation of the Actor model.
Am I wrong or is this guy in some sort of bubble where only functional languages are taught?
Is it though? I've been using dynamic langs my entire career, and static ones too!
I feel like statically typed langs, (I'm looking at you Java), are a bit more stubborn to work with, especially around API design, prototyping, greenfield stuff.
I do like langs like Haskell and Standard ML where they are statically typed, the the type system is mathematically sounds, and the types are inferred.
I want my type system to be inferred and bomb proof or to just get out of the way.
Its the best of both world.
* Reading and understanding code is much easier because the types are written down. You spend much less time figuring out what variables can contain.
* Navigating code is much faster because tools like go-to-definition, code completion and find-all-references work reliably
* Refactoring code is a lot easier - or in large projects actually tractable. In large dynamically typed projects something as simple as renaming a variable can be an impossible task.
* Obviously the one people talk about most is catching bugs. The degree it does that depends on how strong the typing is (e.g. Rust will catch many more bugs than Java). But they will all catch the embarrassing things that dynamic languages can't like typos and missing arguments.
If you've only ever written short greenfield projects you might not appreciate some of these benefits as much as you should because you wrote all the code yourself so all the details are still in your head. It's a bit like saying seatbelts are an unnecessary pain because you haven't ever been in a crash.
> types are inferred
Some local type inference is good, but Haskell / ML style global type inference is kind of the worse of both worlds. You have to satisfy the type checker, which is harder because global solver errors are always harder, and you don't get the documentation benefits of static types because the inferred type is frequently a generic type.
Rust went with local type inference only for very good reasons.
I want to point out goto definitions do work for a number of dynamic langs.
This is all preference. Ive also worked on ruby on rails projects that are 15 years old with 500K LoC
i admit changing stuff can be pretty sketchy if your project doesn't have great test coverage. but that all ultimately comes down to the culture of the programmers working on that code base.
I think things like dynamic/ vs weak typing or functional vs imperative have a much greater impact on code quality/ease of coding than that of static vs dynamic.
I personally think programming in Java, c# is painful, but a lang like Crystal or Standard ML to be very pleasant. and vice versa, i think vanilla javascript is painful for all the reasons you mentioned but langs like Ruby, Erlang, or Elixir to be very pleasant.
“Some languages have a greater association with defects than others, although the effect is small.” Languages associated with fewer bugs were TypeScript , Clojure , Haskell , Ruby , and Scala ; while C , C++ , Objective-C , JavaScript , PHP , and Python were associated with more bugs.
> I want to point out goto definitions do work for a number of dynamic langs.
Not reliably. It can work in a small subset of situations. For statically typed languages it always works.
> “Some languages have a greater association with defects than others, although the effect is small.” Languages associated with fewer bugs were TypeScript , Clojure , Haskell , Ruby , and Scala ; while C , C++ , Objective-C , JavaScript , PHP , and Python were associated with more bugs.
This is mixing up too many things. For example C++ has a relatively decent static type system, but obviously it's going to have way more defects than memory safe languages.
Totally hear you on the static typing benefits, but let's zoom out a bit. As I mentioned before, I've got experience with both dynamic and static languages, and I think we're missing some nuance here. Specifically, I wanna bring functional vs. imperative and strong vs. weak typing into the mix.
JavaScript's weak typing does it no favors, agreed. But that's not a universal dynamic language issue. Ruby, for example, doesn't have those type coercion headaches.
Now, about Haskell and Standard ML—these guys offer a different flavor of static typing. It's not the Java-esque rigidity; it's more flexible and, dare I say, enjoyable.
On the tooling front, I've seen dynamic languages with solid IDE support and go-to-definition features. It's not a static-only perk; it's about the ecosystem's maturity.
That study is a neat data point, but it's not the whole picture. We should consider multiple variables like paradigms and type strengths, not just the static vs. dynamic lens.
I do also want to say in the defense of Elixir (and Erlang), with the advent of the dialyzer lib, it's a gradually typed language, and soon to be (fingers crossed,) a lang with a pretty unique type system. It will be both dynamic but have the same guarantees as a statically typed lang.
I think Elixir is closer to an easier to read Lisp than to Haskell. In fact if someone claimed to know Rust, but couldn't figure out Elixir then I'd simply assume they were lying about their Rust experience.
Monads and Haskell is not a requirement to understand a functional programming language.
Also, I find it hard to believe that anyone who knows N+1 programming languages would have a hard time understanding Elixir quickly, it looks like most mainstream programming languages used today, with slightly different syntax for some things.
As much as I love Elixir, it's really not just "basically Ruby with some slight modifications". The syntax is similar at a glance, but there are some major design differences (e.g. immutability); solving the same problem in Elixir and Ruby can require a completely different structure to your code.
No monads though. No pure functions, no Option types, pretty much no recursion in practice. Really it’s got none of the stuff that makes some FP languages hard to learn. (Except maybe “no for loops”).
That's true - Elixir is simpler to learn than, say, Haskell. All I'm saying is that it's not a trivial jump from Elixir to Ruby, despite the superficially similar syntax.
I don’t think eg ruby->go is a bigger jump. Learn defer, structural typing, interfaces vs learn to replace all loops with map/filter/etc + pattern matching. Feels similar, no?
> it's basically Ruby with some slight modifications.
It /looks/ like Ruby in a lot of ways, but treating it like Ruby w/ modifications is a mistake that I've seen lead to a lot of really bad usage that (at best) fails to take advantage of the underlying Beam VM, and at worst [and more commonly] actively works against it.
I picked it up pretty quickly as primarily a JS dev at the time.
I’ve also worked on several projects where I’ve pair programmed with a dev new to the language. They’re usually pretty productive within a few days. Not writing their own DSLs or going deep into OTP, but productive in terms of writing application code.
Phoenix is pretty straightforward for those who have experience with Rails, Laravel or a similar full-stack web framework.
Rust screams Erlang influence, but maybe it's just me. IIRC, in the beginning they even tried to put in a green threading VM for tail calls, which seems insane for something that you want to be a systems language.
> Steve: We chose Elixir because we were looking for a system that was easy for programmers to understand and could take better advantage of our servers. I was intrigued at Elixir’s combination of friendly syntax, powerful metaprogramming features, and incorporation of the Actor model.
Am I wrong or is this guy in some sort of bubble where only functional languages are taught?