Joy of Elixir | Hacker News Reader

Joy of Elixir

joyofelixir.com

241 pointsGordonS84 comments

I've certainly enjoyed Elixir as an nth programming language and the idea of Elixir as a 1st programming language is really interesting.

I know I've seen at least one educator in the community speculate that Elixir (or FP languages in general) could potentially make great 1st programming languages because they're often conceptually easier than OOP languages and in many ways the difficulties people associate with learning them come from the difficulty of unlearning some of the things they already know.

I've actually been discussing this with a couple of people within the community. Been hacking with Elixir for a bit, and in an effort to teach it to people around me who've never programmed I've started compiling my notes into a book.

Would love to share it here in a bit when I have some time to finish things up and get some feedback.

I will say, writing from the perspective of it being one's first language is really interesting, because you just can't assume anything.

I have first hand experience with this actually...

Over the last 6 months or so a good friend of mine has learned to code from scratch. After much deliberation I took a gamble and set him up with Elixir as his first language (largely because he wanted to code so he can work with me on some projects, which use Elixir).

I am really happy with this choice and so is he. Elixir is a language with very consistent ideas throughout and I think concepts like functional transformations, immutability, pattern matching and actor based concurrency are both extremely useful to learn early and very accessible to beginners in Elixir.

Edit:

I didn't think of it when I wrote this comment, but I think the single most helpful thing for beginners (and me!) in Elixir, is the 'h' function. If you run it with any function as an argument in iex (Elixir's repl) you'll get documentation and an example of how to use that function:

  iex(2)> h Enum.map

                              def map(enumerable, fun)

  Returns a list where each item is the result of invoking fun on each
  corresponding item of enumerable.

  For maps, the function expects a key-value tuple.

  ## Examples

      iex> Enum.map([1, 2, 3], fn(x) -> x * 2 end)
      [2, 4, 6]

      iex> Enum.map([a: 1, b: 2], fn({k, v}) -> {k, -v} end)
      [a: -1, b: -2]

Python has the same via help(thing)

As does Clojure with doc. However, neither of these include examples as standard. Idiomatic docstrings tend to be a short string; one sentence or paragraph.

How does your friend deal with Processes, OTP, Supervision trees and so on?

I'm a huge Elixir fan, but always thought it would be a hard first language because of OTP, the benefits of which are kinda hard to appreciate without some experience making production software. Happy to be wrong on that though.

Having the example is really cool. I tend to provide examlme in docstrings for functions I personally write. Would be nice if core functions of other languages did too.

Hi! Thanks for the kind comment :)

I find it an interesting idea too. I mentor people at Culture Amp in Ruby and Elixir and I'm definitely finding Elixir easier to teach for a couple of main reasons:

* It's Just Functions And Data™

* Inheritance isn't a thing

* Functions either come from within the same module if they don't have a module prefix

* Functions from other modules _must_ have a module prefix.

* Immutability, immutability, immutability.

It just _feels_ like there's less to learn with Elixir (foundational wise) than Ruby. It's been pretty nice.

I beg to differ with most of your points:

* Inheritance isn't a thing, but behaviors and protocols are.

* Functions from other modules _must_ have a module prefix, except if the current module has `import` statements at the top or, worse, `use` statements which happen to run macros that in turn `import` stuff again. Phoenix does this with controllers, and it's a mess. A million unprefixed functions available and no clue where they come from. Also, you forgot about `Kernel`.

* Immutability, except when you inherit code that uses Agents all over (which is really just a Java Bean, a mutable object, or whatever you want to call it) and you lose it all again. Process state is mutable, and the smaller your processes are, the more your code starts to smell imperative.

In all honesty, if you add import, use, macros, behaviors and protocols to your list, then all in all there really is pretty much to learn. It's no C++, but I have a hard time calling Elixir simpler than Ruby.

Now, I think these are all good features (except Agents). They just make Elixir less simple, that's all.

I would say the difference is that you can start small. You can start thinking about functions and data and you can build a large amount of software with the simpler abstractions. I would say this is not specific to Elixir but to functional languages. A good amount of my code is just functions and data. Processes, macros, protocols, etc come only when strictly necessary.

When I went to university for CS, Haskell was used in the introductory programming courses and this was one of the main reasons we were told about.

Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new, force them to think about things from first principles rather than lean on acquired habits, etc.

I had already been coding for a long time by that point but it was the first time I saw a functional language and I think it addressed both goals very well.

> Another goal was to take the people who had been learning to code in their spare time and put them on more even footing with those who were totally new

The thinking behind that is usually a bit fallacious, though.

Say the department has been teaching Java in the introductory programming course, and noticed that some people already know most concepts. Then they decide to use a different language to "level the playing field".

First of all, what kind of attitude is that? If some people already know the stuff, just let them take the exam without attending the course, so they can take "Advanced Programming Paradigms" or wherever FP is taught.

I can understand teaching FP first if you think it's conceptually easier, but counting prior experience of some students as a reason to restructure the curriculum for everyone is silly.

Second, using Haskell instead of Java isn't actually leveling the playing field. It just changes who has an advantage from game modders and people who coded their own website to the more mathy types (or people who learned Haskell in high school, like me), who will have an easier time with higher-order functions and the rigid formality of the type system.

When they announced in my OOP course that there'd be a few sessions on other paradigms, I was a bit disappointed to find out that this meant only a bit of Haskell and Prolog, when I'd already written a simple Prolog interpreter in Haskell. Should they have changed the curriculum just because of me? Definitely not.

It was a long while ago now, if you had learnt anything before you got there it was pretty much guaranteed that you'd seen either BASIC or C. :)

The internet wasn't what it is now either so most people who had done some coding before were indeed lacking in understanding of the fundamental principles of what they were doing – I know I certainly was. There may have been outliers yet beyond the "I've been playing with code" crew but I didn't meet any.

I'm not at all suggesting it would be good reasoning today, but I think it helps to show that the underlying idea that FP is a good way to introduce people to code whilst ensuring they develop a strong theoretical understanding was true then and should still be today.

While I applaud creating documentation, books, and guides for those new to the language, there's still a significant accessibility gap in resources. I already know the language, I've already done some basic stuff in phoenix, I've even made my own HTTP API wrapper as its own library. But when it comes to architecting backend systems that aren't tied to phoenix or playing around with IEx, I really feel like I am on my own.

There are erlang books, of which I am reading, though it feels like there's always emphasis on history for backwards compatibility and the other warts that Erlang has with its age. I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern. Things that involve working in memory, processing queues, managing sessions and state, patterns for fallbacks and breakers for services, and so on, that is where I seek more content.

Unfortunately I hear the big BEAM player around, Basho, is shutting the lights--so I can't expect to witness the wonderful presentations their engineers provide at conferences or through recordings of such conferences.

Found this post from June about Basho.

https://news.ycombinator.com/item?id=14621359

It's very definitely dead.

https://www.theregister.co.uk/2017/07/31/end_of_the_road_for...

I feel that Erlang adoption is probably the most realistic growth path for most serious Elixir developers. All of these topics you mentioned (breakers, message routing, etc) have been discussed and developed in the Erlang community for years. The only new thing that Elixir brings to the table in these areas is abstraction and syntax - both of which are arguably not needed in large complex systems.

Source: full-time Erlang developer of 7 years who spent a full year coding Elixir in its v1.0.x days

I told myself I'd avoid Erlang at all costs. Then I decided I needed to know how leex and yecc work, so I got down and dirty w/ Erlang. It's close enough to Elixir that I can stumble through my way through it.

Just the reply I was looking for. I do not have your years of Erlang experience but I've done enough to think I have a feel for the language itself as well as the fundamentals of OTP.

I've looked at Elixir and my feeling is that "it's probably great if you're coming from Ruby but what's the point if you're already invested in Erlang?"

Perversely, I actually like Erlang syntax too.

As many others said in the thread, forget about the relationship between Ruby and Elixir, and give Elixir a try. It is much more than syntax: structs, protocols, the test framework, documentation, tooling... even the new error messages and debugger make a big difference on every day development.

There are reasons for picking Erlang over Elixir but if the reason is that "Elixir does not offer anything beyond syntax", it is likely the person has not been paying much attention.

Yup, I actually hate the Elixir syntax. I've never been a fan of ruby syntax. Granted I find the elixir syntax a step up on ruby. Anyways, Elixir is nice because of its abstractions. While I understand most people come to it from ruby for its familiar syntax.

Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM.

Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can refute it with about as many objective reasons as I suspect you have for making that comment. Our current code base would be significantly shorter if we used Elixir (on the order of 50% less code, conservatively approximated) and is an absolute bitch to spelunk in specifically because it's just Erlang.

There is no reason to create a new project in Erlang (instead of Elixir/LFE) outside of reasons like handing it off to clients or the like and the focus should never be on learning Erlang, but on the BEAM. Any knowledge gained through that is trivially used in one of the more productive languages on the BEAM.

50% less code? Can you provide some more specifics? That seems like a bold claim.

We use REST for both internal and external calls to services (a mistake, in my opinion) and while Erlang actually has frameworks for this, none of them are good and cowboy_rest requires lots of boilerplate. Doing it with Phoenix would cut out lots of entire modules and replace them with functions without paying any real cost.

I like Erlang, but there's no upside to using it instead of something else that runs on the BEAM, apart from making a basic library that you want to use both from Erlang and Elixir (I don't know what the situation for compiling Elixir with rebar3 is).

Effectively, Erlang is to Elixir what Java is to Kotlin, except there are even less performance differences and no compatibility issues. It makes perfect sense to learn Erlang syntax and learning the semantics of it will mean you've learned BEAM semantics, but you might as well do that in Elixir and actually have a better road to it.

Edit: I'd like to add that I find a general lack of tools for dealing with boilerplate in Erlang. It also has a generally outdated functional programming skew in that it doesn't at all facilitate pipelining and this makes it less attractive to make nice abstractions like Plug(0), for example. This is exacerbated by the fact that collections aren't abstracted over, so whenever you end up dealing with them there's lots of sighing and docs checking to see what the argument order was the week they designed that particular module and that particular function in that particular collection module.

0 - https://github.com/elixir-plug/plug

Definitely recommend reading "The Little Elixir & OTP Guidebook"

The focus of the book sounds like pretty much what you're asking for. The first few chapters cover Elixir basics, but its really just a primer -- easily skippable if you already know it. Starts with implementing OTP features from scratch so you can see what they do and why they exist, then dives into how to do it using OTP.

> I'd like to design reliable systems that operate outside of the classic HTTP -> Elixir -> Database pattern.

Then use Erlang. I like and prefer Erlang to Elixir for example. It has a simpler syntax, it's consistent just like Elixir. And you'd be surprised that Erlang for being what 30 years old is being regularly updated and improved Most importantly things are deprecated regularly from the the language and the standard library, as new stuff is added. That's how it managed to still say small and simple. Plus you'll get a lot of resources and reference already created for it.

If you like Elixir, start with it as so many concepts overlap and then you'd pick the Erlang syntax and some conventions later without that much hassle.

I'm actually working on a book which I think covers a lot of what you're looking for (and was what I wanted back when I got started with Elixir a few years ago). I'm covering architectural patterns for the items you mentioned as well as flow control and digging in deep on how to really leverage the fault isolation mechanisms of OTP. I'm the maintainer of Distillery, the release tooling in Elixir, so I'm also covering a lot of the gritty details involved there, such as how to work with hot upgrades and such, as well as dealing with issues in production using some of the excellent operational tooling available.

Unfortunately I probably won't be done until the end of this month, but if you're interested, keep an eye out on ElixirForum.com, since I'll announce it there when it's available.

Do you have a mailing list I can sign up to to stay notified?

I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up.

I echo what Hates_ says, do you have a mailing list so that I may also be notified when things come out?

I hope you don't mind if I just copy my reply to Hates_: "I don't yet, as I've been pretty heads down. I'll put one together this week and reply back once it's up."

I'll make sure to write back to you both :)

Thank you!

is there any news recently about Elixir? I'm asking since recently Im seeing a lot of articles about how to get into Elixir which is really nice since I just started pickup the language as well.

Erlang/OTP 20.0, Elixir 1.5 and Phoenix framework 1.3 were all released in a timespan of 2 months or so - huge improvements to the already great ecosystem.

Two months? Try all within the last 2 weeks!

Erlang/OTP 20 came out June 21[0], so about 5 weeks ago. Makes sense though, Eliir 1.5 was waiting for final release of OTP, and Phoenix was waiting on final release of Elixir, but they'd all had very stable preview releases for a while, so it wasn't a ton of work left on any of them, just finalizing and testing I imagine. I'm super excited to get my side project[1] upgraded to 1.5 and see the new dev conveniences!

[0] https://www.erlang.org/news/114

[1] https://github.com/MasbiaSoupKitchenNetwork/open_pantry

The Phoenix team was waiting for Elixir 1.5 to release the new version of the framework (or at least one of the devs said as much in a talk I watched a while ago).

A good youtube channel:

https://www.youtube.com/channel/UCFKQ85T69sYhifDHF7dnPgw/vid...

Kind of like a quick guide:

https://elixirschool.com http://elixirbridge.org/02_Intro_to_Elixir/01-why-program-wh...

I think Elixir isn't that hard about syntax. Just start to do something and learn it on the go, see how people do it.

I have experience with it, quite nice: https://github.com/yeo/betterdev.link/tree/master/community/...

Which power: http://one.betterdev.link

Nice resources here.. I'll add this Udemy course to the list:

https://www.udemy.com/the-complete-elixir-and-phoenix-bootca...

Does anyone have recommendations for specific Phoenix learning resources?

I've found the guide on the Phoenix website to be enough most of the time.

Wow http://elixirbridge.org seems really interesting! I'm following the official tutorial right now to get the basic down and will go through the book Programming Phoenix

Don't sleep on your Erlang literature: Learn You Some Erlang, Erlang in Anger, Design for Scalability with OTP. Also Little Elixir and OTP Guidebook is pretty short. I haven't read it yet, but Elixir in Action is supposed to be very good, too.

http://learnyousomeerlang.com/

https://www.erlang-in-anger.com/

https://smile.amazon.com/Designing-Scalability-Erlang-OTP-Fa...

https://www.manning.com/books/the-little-elixir-and-otp-guid...

https://www.manning.com/books/elixir-in-action

The Elixir News category on the Elixir Forum (or just the forum itself) is a good place to look for important updates:

https://elixirforum.com/c/elixir-news

I've spent the last year building[1] an open source side project with elixir and phoenix. It's honestly been a pleasure to work with once you get over some of the initial hurdles.

[1]: http://www.achariam.com/elyxel (It's a self plug but I genuinely think it will be helpful to folks)

I've been seeing a lot about Elixir lately. I am curious are people seeing a demand for Elixir in the market?

Or has anyone recently hired for it? If so what did it look like from the hiring side?

I happened to mention interest in Elixir on my LinkedIn page, and now I get hit up by recruiters for it every so often, so it seems so. I haven't heard too much outside of this personal anecdote, however.

At the london meetup last week, when ask if their company recruit and search for elixir devs, everyone raised their hands. Approx 60 to 80 devs. So probably 20 to 30 company....

Side note... the book's logo is mildly similar to the Drupal icon. Might confuse a few people.

https://www.drupal.org/files/druplicon-small.png

There seems to be an unfortunate number of "TODO: Add image here"-type blocks in this. Other than that, a quick glance seems good to me.

Yup, sorry about that! I am a _horrible_ artist and so I'm hoping to rope a good friend of mine in to help with that. He's recently started a new job and so he's been busy. One day there'll be some great images in the book.

Can't wait to see them! I really like the book so far :)

This doesn't improve the current docs or tutorials.

It does if you are an absolute beginner to programming. If you are already seasoned then yes it doesn't add much, it just means you aren't the target audience.

Which the JOE folks make quite clear. Why would anyone assume this was not for complete novices new to programming in general? It seems odd to me.

I find it a very good start for someone new to programming with zero experience and wishing to start with elixir.

There are hardly any books that approach programming elixir from a complete lack of programming knowledge POV. I'm happy to see this!

Thank you for the validation! :) It really helps to see support like this for the project.

Aha, then add more fun through pictures (the drop of elixir thing at the homepage could be the spokesperson). How many people are working on this?

Why is there so much Elixir hype on HN at the moment?

HN shouldn't be used as a propaganda hype machine. I've seen all the language hype cycles,

Year 1:

PHP sucks! Node.js is awesome! Everyone must use Node.js!

Year 2:

Node.js sucks! Go is awesome! Everyone must use Go!

Year 3:

Go sucks! Rust is awesome! Everyone must use Rust!

Year 4:

Rust sucks! Elixir is awesome! Everyone must use Elixir!

... And of course you get the odd Haskell article every so often.

Communities are promoting their stuff too hard - They are setting up their users for disillusionment and disappointment.

Eh, just don't upvote it. Or upvote other PL stuff you do like.

I too feel there is a generational hype cycle at HN. However, I don't see much in the way of "language N sucks" as a precursor to "everyone should use language N1!" Maybe I am just blind to the negativity, but in general, what I see with each hype generation is only the positive side: "everyone should use language N1!"

I suspect with any given hype generation—with each trending language—we're going to see a lot of positive messaging as the fans up-vote articles pertaining to the new hotness. Meanwhile, those who disagree (or simply don't care) probably don't see much value in taking the time to evangelize their disagreement. I'm not upvoting Elixir content, but I'm certainly not going to downvote it either. Why should I care if other people enjoy a platform I don't care about? Good for them!

Also, perhaps as everyone is hyping language N1, those who are using N are simply too busy using N and making a living to keep layering on the hype.

Adding more programming languages just fragments the job market further. That might mean fewer jobs available for other languages and allow software developers less movement between companies.

How many times have you seen a job advert and you think oh wow that looks interesting, I'd like to work there... Oh wait, they use X on the backend, I don't have any previous commercial experience with X so damn, I can't join the company. The more programming languages there are, the more often this will happen. The time for creating and promoting new programming languages is over, we have to move forward and work with the languages whose ecosystems have had 20 years to evolve - This is where the real value is.

I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js adds no extra value to any given project... It only restricts the pool of potential job candidates.

If you use any programming language for long enough, eventually, you will be very productive with it - The language itself doesn't really matter.

Its just a waste because there are already so many languages optimized for the server-side use cases which Elixir aims for and which are already doing a great job.

> [...] allow software developers less movement between companies.

> How many times have you seen a job advert and you think oh wow that looks interesting, I'd like to work there... Oh wait, they use X on the backend, I don't have any previous commercial experience with X so damn, I can't join the company.

Wait, just who are you, then? An intern fresh out of high school? Or do your circumstances impair your ability to learn (I hope I'm not being insensitive)? Are you a programmer?

I ask because it never happened to me, and I never even heard of something like this from non-junior programmers. If the company I'd like to work at uses a language that I don't know (there's actually pretty decent chance if they use something mainstream) I believe in most cases it would be enough to tell them I'll learn the language in a week and after a month I'll be writing decent quality production code. There is no reason - except if I do bad in the interview, maybe? - to not believe me, as that's generally accepted as a standard timeframe for such things. In my case that's a lie, as I can get started with a language in a matter of hours and start writing production code after a few days - but I admit I'm unusual on this.

> I'm certain that using Elixir over Haskell, Go or even JavaScript/Node.js adds no extra value to any given project...

Programming languages are being created for a reason and "adding value" in some kinds of programming tasks is a prime concern when designing them. Different languages make different choices and in effect work better or worse in given circumstances.

Replacing Node with Elixir (any BEAM lang) would immediately give you a true SMP support without using spawned processes, for example, and could possibly shorten and simplify your code if you have many communicating, long-lived services in there. That's an added value, right? The saying "use the right tool for the job" fits here perfectly.

> If you use any programming language for long enough, eventually, you will be very productive with it - The language itself doesn't really matter.

Exactly - so why limit yourself to a single language? How long do you think you will be working? What will you do once you've mastered a language and realize that you have 20 more years to work with it? Wouldn't that make you bored after a while?

> Its just a waste because there are already so many languages optimized for the server-side

There is not a single language which offers the same mix of features as Elixir. It's perfectly possible to have a system which would benefit from the just right mix of features and then not having these features is a tremendous waste as well.

It's not like I don't understand where you're coming from: in my youth, when I was learning C++, I also was frightened by the complexity and believed that it will take years to master it. And it did take years, mostly because it's C++ and I was alone. However, the next language I learned - PHP if memory serves - took me just a couple of months to get good at. Then, when I passed the 20 "langs known" mark, I realized that learning languages is no longer a problem at all and instead made it into a hobby.

In other words, yes, you need some level of understanding of programming to be able to efficiently learn new languages. I think it is better to strive to reach this understanding instead of assuming new languages are bad.

I've been programming for 14 years in about 10 different programming languages... It's a struggle for me to list them all (let alone learn them). I only really needed two of them; all the others were a waste of time because they're so similar to each other.

Learning new languages is not hard for me, I can pick up a new one in a single day and my code could fool someone into thinking that I've been doing it for a while (if you ignore development speed)... But unfortunately that's not true mastery, you can only truly master a language or framework after working with it full time for a couple of years.

It takes a long time to absorb all the intricacies of a language to produce really good software.

You could spend a few years studying French and think that you know it all by the end just because you can talk fluently, but in reality you couldn't even write a basic child's novel, let alone a top-seller, or a Pulitzer prize novel.

It depends on what kind of work you want to produce.

> 10 different programming languages... It's a struggle for me to list them all (let alone learn them).

That's still very little. You can take a look at my site (in profile, the "Languages" page) where I listed PLs which I learned. There's 126 entries on that list (to save you a couple of clicks). I'm not boasting - just offering a different perspective.

> all the others were a waste of time because they're so similar to each other.

If they are so similar, then learning them should be very easy and quick, no?

> I can pick up a new one in a single day and my code could fool someone into thinking that I've been doing it for a while (if you ignore development speed)...

In a single day? So it's not that much effort, is it? Assuming, of course, you won't hit the language which is different enough and your intuitions and experience become useless.

> you can only truly master a language or framework after working with it full time for a couple of years.

You're wrong, in part.

It takes a lot of time to master your first language and a few others in the beginning. Later it can take quite a lot of time to learn your first language with a paradigm you're unfamiliar with.

But languages are similar to each other, can be classified into types and studied in bulk. With enough languages (and frameworks) learned you develop an intuition of what happens and how. With enough different languages known, you develop an intuitive feel for what's the best way of solving a problem in a given language. There's also a bit of theory to be learned, but once you have it down there's really nothing that can surprise you.

Personally, I've had the hardest time when learning J. There are exactly two other languages which are similar (APL and K) and they both are even harder to get into. So the reverse is also true: if you don't know enough about a certain kind of languages, you're going to have a hard time.

In the end, I think we disagree on what we consider mastery. I don't believe you have to remember all the finest details of implementation to say you've mastered the language - as long as you can easily drop down to the compiler or interpreter source, read it and understand without effort. It's all pretty easy then, believe me.

> They are setting up their users for disillusionment and disappointment.

There's nothing wrong with communities promoting themselves. If people don't know about your thing, they can't try it to make their own decisions about whether or not it is worth using.

And it isn't yours or a community leader's or a maintainer's job to protect users from disillusionment and disappointment. If someone actually has a hard fall from realizing that a programming language isn't as great as people said it might be, there are way bigger issues there than the programming language at play -- on the side of the disillusioned, not the language/community.

https://news.ycombinator.com/item?id=1919897

Hacker News is interested in Erlang; it should be in the rules.

Also - just judging by the head of the linked list - PHP programmer?

Go is still great and stronger every day ;)

Yeah it's pretty obvious what's going on...

don't understand why you got downvoted, it's a pretty legitimate concern.

You may however see the whole thing a bit differently :

- node popularized single loop event on the server side, which is great for fast low cpu request processing

- go evangelized simple design, coroutines , unique code formating, and has arguably one of the best stdlib. That's still true today and it's great

- Rust made people realize writing concurrent truelt safe code was possible. Huge advance.

- Elixir helped the community focus again on actor + message passing concurrency. It's fantastic.

All of those concepts are beneficial to learn, for you as a programmer, no matter which language you use.

If for example look at swift evolution, you'll see the current threading model (based on event loops, like node, because of iOS) discussed and compared to the actor model ( like erlang / elixir), but also that some web framework reimplemented go-style concurrency. You'll also see that they're talking about adding semantic for detecting memory sharing patterns (much like rust).

If you've followed all the discussions on those languages for the last two years you know exactly why those conversations are taking places. So all in all it's a good thing communities are advocating the strenghts of their language. It helps everyone improve.

Reply on news.ycombinator.com