[chmln]

This went past me as the post is filled with a lot of claims with no reasoning to back those up. It is not a critical evaluation of the language, but rather sounds like a "fanboy" piece, for the lack of a better term.

> Memory efficiency is much better than most other languages (with the exception of Rust, but Elixir is miles better at Error handling than Rust, which is a more practical feature IMO

How exactly are arbitrary runtime exceptions better? Any elixir function you call has the potential to crash. Meanwhile with Rust, your function returns a `Result` if it can error, and callers are then forced to handle those by the compiler, either via pattern matching or ergonomic error propagation.

Rust has runtime panics, but those are for rare unrecoverable errors and are not at all used for conventional error handling, reserved usually for C FFI, graphics code, etc.

[josevalim]

I am not sure I would say one is better than the other, but they are very different.

As you said, in Rust you are forced to handle errors by the compiler. In Elixir, you actually don't. In fact, we even encourage you to [write assertive code](http://blog.plataformatec.com.br/2014/09/writing-assertive-c...). This is also commonly referred as "let it crash". In a nutshell, if there is an unexpected scenario in your code, you let it crash and let that part of the system restart itself.

This works because we write code in tiny isolated processes, in a way that, if one of those processes crash, they won't affect other parts of the system. This means you are encouraged to crash and let supervisors restart the failed processes back. I have written more about this in another comment: https://news.ycombinator.com/item?id=18840401

I also think looking at Erlang's history can be really interesting and educational. The Erlang VM was designed to build concurrent, distributed, fault-tolerant systems. When designing the system, the only certainty is that there would be failures (hello network!) so instead trying to catch all failures upfront, they decided to focus on a system that can self-heal.

I personally think that Erlang and Elixir could benefit from static types. However, this is much easier said than done. The systems built with those languages tend to be very dynamic, by even providing things such as hot code swapping, and only somewhat recently we have started to really explore the concepts required to type processes. But a more humble type system could start with the functional parts of the language, especially because I think that other techniques of model checking can be more interesting than type systems for the process part.

[nelsonic]

@chmin thanks for the great feedback! ;-)

I did not write the post for general consumption, more as a reply to the question from the person as indicated in the first paragraph of the thread ... I really did not expect it to end up on HN. ¯\_(ツ)_/¯

100% Agree that there is a lack of "critical evaluation" and it borders on "fanboy" ... It's not a scientific or statistical analysis because I did not find any data I could use to make a an argument either way.

My experience with Elixir, JavaScript, Ruby, Java, PHP, etc. is based on doing the work in several companies big and small and I don't consider myself an "expert" in any of these languages. I have felt the pain of having to maintain/debug several large codebases with incomprehensible/impenetrable and untested code over the years and I find Elixir to be the most approachable of the languages I am fluent with.

I wish there was an objective way of assessing the day-to-day experience of living with a language ... have you come across such a measure that isn't based on the opinions of, as you say, "fanboy" users?

You appear to have superior knowledge/experience of Rust. Have you written any tutorials or blog posts sharing that knowledge? I would love to read your work. Is this you: https://github.com/chmln ? If it is, https://github.com/chmln/asciimath-rs looks cool! (nice work! :-)

[chmln]

Hey, thanks for chiming in!

I didn't mean the "fanboy" remark to be personal on any level. I just thought that some particular comparisons were unfair.

There are numerous valid points in the piece and I don't see much wrong in sharing the joy of working with a language, even if it's a little biased.

> I wish there was an objective way of assessing the day-to-day experience of living with a language ... have you come across such a measure that isn't based on the opinions of, as you say, "fanboy" users?

At least the "scientific" comparisons of programming languages I've come across have been questionable at best. Each language has its strengths and weaknesses, big or small, so wholesale comparisons are complicated further. Thus people have to rely a lot on opinions and real-world experiences of themselves and others.

> You appear to have superior knowledge/experience of Rust. Have you written any tutorials or blog posts sharing that knowledge?

Thanks for the compliments, and that's indeed my profile. Unfortunately I haven't had the time to blog at all, but perhaps I will someday get around to it.

[chillaxtian]

I really think that you don't need to utilize italics to make yourself appear like you care.

[awgm]

I found the emphasis helpful

[davidw]

Erlang's error handling is... kind of different and takes a while to really grok and work well with. It's not so much about individual functions, as how the system as a whole recovers from failure.

[crimsonalucard]

Most people (especially from type unsafe languages) haven't figured out that the Option type with pattern matching actually eliminates a whole class of runtime errors. They just see the match operator and types in general as a syntactical nuisance.

   fileString = checkFile("sample.txt")
   if(fileString == null){
        //handle error
   }

If I showed the above pattern to typical javascript, python, ruby or elixir programmers at any company, 99% of them won't be able to identify why this pattern is bad, they see it as a necessity and rely on the programmers skill to catch that potential null (or exception depending on the implementation).

In fact, you dear reader, might be one of those programmers. You might be reading this post and not understanding why the above code is an unsafe and a bad style. To you, I say that there are actually compilers that automatically prove and force you to handle that potential null not as a logic error but more as if it was a syntax error.

That guy who advocates unit tests at your company doesn't understand that unit tests only verify your program is correct for a test case. These compilers provide PROOF that your program is correct and can eliminate the majority of the tests you typically write.

The code above is unsafe not because of the developer, it is unsafe because of the nature of the (made up) programming language.

In elixir, python and javascript you will inevitably have to follow this unsafe pattern.

[vonseel]

Well, yes, but that guy who advocates unit tests might understand all of this and the shortcomings of the chosen programming language, and that is why he advocates unit-testing. Careful who you are criticizing here :)

[crimsonalucard]

I never discounted unit tests. I advocate it as an important feature in a project. I'm saying you need significantly less when you have the types of checks I talk about in place. :)

The guy I'm criticizing here is a certain breed of person who advocates unit tests but suffers from a logical flaw in his reasoning. He advocates unit tests like a mad man but he uses an unsafe, untyped language for the entire project. Javascript is the worst offender here.

Unit tests are a safety first philosophy that is employed at the inconvenience of writing tests. However, it makes ZERO sense to employ unit tests as a safety net without type checking as a feature that proves your program is absent of type errors. Remember unit tests only verify a test case works, the safety features I talk about in my post actually Prove your program correct.

This is a huge flaw in engineering paradigms that I see permeate the industry today. People literally are ignoring a feature that proves a major part of your program correct and they are advocating the entire program be safe guarded with a weaker check (unit testing). I advocate we use both.

We see thousands of python, ruby and nodejs projects with massive unit testing overhead on top of the project itself. What these advocates don't realize is that you can get rid of 80% of these tests with a type safe language. I urge you to check the unit testing involved with a golang project vs javascript. There's usually a significant difference in size. For robust applications the unit testing suite of a javascript app is much much bigger in size.

I end with a quote from a guy who used logical methods to prove the absence of bugs in his programs rather then rely on hundreds of unit tests.

"Testing shows the presence, not the absence of bugs." - Dijkstra (1969).

[vonseel]

I understand your viewpoint, but aren't you assuming that the "guy advocating unit tests" has the option of choosing a type-safe language? In my experience, the programmers rarely have the power to choose the programming language. In fact, they were probably hired because of their expertise in the language already being used.

Just saying, if I'm writing Python and advocating unit-tests... even of TypeError exceptions and similar problems that would be avoided by using Golang... it's probably because I know these are common problems in Python/JS/non-type-safe languages, and I probably don't have the power to choose a different language than the one already being used by my company/development organization.

[crimsonalucard]

For python you can use type annotations with an external type checker such as mypy or flow for js.

To implement type checking in js or python would add a layer of unparalleled safety for a fraction of the development time involved with unit tests.

Yet I would say 90% of developers are unaware of this contradiction and go on piping about the extreme importance of unit tests while completely ignoring type checking. They value safety but are too naive to know what safety means.