Live data from Hacker News

Elixir v1.10

elixir-lang.org

111–120 of 141 posts

Re: Elixir v1.10

#111
post #110
post #51

Earlier quoted context omitted.

Elixir (really, the Erlang VM it's built on) is designed for highly concurrent, reliable systems. For my org, building a distributed webapp, we chose it over the languages you listed because of how much you get "out of the box" with Elixir. Saša Jurić's talk "The Soul of Erlang and Elixir" ( https://www.youtube.com/watch?v=JvBT4XBdoUE ) is a good introduction to why someone might choose Elixir. The payoff is the slid…

I hadn't seen that slide, it's pretty compelling. Is there a story for typechecking or a typed language that runs on BEAM? This is one aspect that holds me back a little.

Erlang's type checker Dialyzer has an Elixir wrapper called Dialyxir (https://github.com/jeremyjh/dialyxir). As someone coming from C++, Dialyzer leaves a lot to be desired—I still miss C++ type checking—but it's better than nothing.

The Norm library (https://github.com/keathley/norm) is an attempt at higher-level, more expressive type checking which I think shows a lot of promise, but I've not adopted it in a real project yet.

Re: Elixir v1.10

#112

I’ve been using elixir for about a year now. It really makes writing API code joyful. The pattern matching concept works so well for handling the variation that happens in API request handling. I also love working with Plugs. The pipeline nature of elixir translates directly into how you manage a request/response, and the plug abstraction pattern allows you to be explicit about what should happen, and hide the detail…

Reading the update to Enum.sort, I could see in my head how easy a change this would be in elixer.

Supporting a different second parameter (a symbol rather than a function) can be implemented with another function that pattern matches to :asc or :desc. They can each call the original function(s) too.

In many other languages you'd start `sort` with a conditional and that function would need to handle every case. Not here. Each function worries about itself and what it can handle.

There's a beauty and practicality that Elixir hits so well.

Re: Elixir v1.10

#113
post #79
post #76

Earlier quoted context omitted.

It's called "arity": https://elixir-lang.org/getting-started/basic-types.html#ide...

not sure how i made it through my entire CS degree without learning this term. either that or i just don't remember it. anyways, thank you! this is really useful even outside of Elixir.

I've honestly never heard anyone who isn't an Elixir programmer use it. I wouldn't worry about not having heard it before.

Re: Elixir v1.10

#114

I've been tempted a few times to dip my toes into Elixir -- I like the language and the BEAM concepts, but in my environment I always bump into the following concern.. Ecto v3 has been out for more than a year now, and there are still only two supported adapters.. MySQL and Postgres. In my environment, I use a lot of MSSQL and SQLite in addition to Postgres, and those adapters haven't been successfully ported over to…

I guess it depends on your needs and motivation... we recently completed the transition from Ecto2 to Ecto3, and while not totally trivial in our case, I think you could do in a way that wasn't hard if you maintained compatibility with both from the start, so that only config had to change. But also, what are your requirements for using SQLite and/or MSSQL? Are you looking at porting existing projects, or new service…

SQLite is really handy for smaller use cases and being able to spin up a new project quickly and without dependenices. TBH I'm kind of surprised its missing from the list

Re: Elixir v1.10

#115
post #79

Earlier quoted context omitted.

not sure how i made it through my entire CS degree without learning this term. either that or i just don't remember it. anyways, thank you! this is really useful even outside of Elixir.

I've honestly never heard anyone who isn't an Elixir programmer use it. I wouldn't worry about not having heard it before.

It's much more common than just Elixir programmers. It's a common concept in computer science, particularly in functional programming or languages which permit function overloading on arguments.

https://en.wikipedia.org/wiki/Arity

Edit to add: I've heard and used arity for at least 10 years, in particular in the Clojure community. I've heard of Elixir and understand it shares some common ideas with Clojure and Ruby, but never been a part of its community.

Re: Elixir v1.10

#116

A very interesting language on powerful platform with a promising web framework. Many saw it, myself included, as a Ruby / Rails Improved, and expected its quick growth. Unfortunately, initial enthusiasm a few years ago did lead to its wide adoption. I talked with a couple of companies that jumped on it initially, but later decided to move to Java, Kotlin, Go. The main reason was difficulty to hire engineers to scale…

I started a new job a month ago that is all Elixir, with no prior Elixir experience, and honestly it's been completely fine. My only advantage was that I had used a functional language (Elm) for a while before it, so I was used to a functional approach.

Re: Elixir v1.10

#117
post #115

Earlier quoted context omitted.

I've honestly never heard anyone who isn't an Elixir programmer use it. I wouldn't worry about not having heard it before.

It's much more common than just Elixir programmers. It's a common concept in computer science, particularly in functional programming or languages which permit function overloading on arguments. https://en.wikipedia.org/wiki/Arity Edit to add: I've heard and used arity for at least 10 years, in particular in the Clojure community. I've heard of Elixir and understand it shares some common ideas with Clojure and Ruby,…

In functional programming classes at the uni you probably wouldn't hear this because if they teach Haskell which I assume most do, every function always takes just one argument. That's because functions are curried by default.

I personally haven't really heard this mentioned anywhere outside of the Erlang/Elixir sphere.

Re: Elixir v1.10

#118

Earlier quoted context omitted.

Weird, on the Elixir forums and slack channels there seems to be a fair number of developers working or wanting to work in Elixir. Perhaps the initial uptake in interest outpaced the developer interests in some areas. It'd be interesting to know what the community is like in Europe. Based on the recent formation of Dashbit [1] and larger companies like PepsiCo (?!) among others openly jumping onboard I think means El…

I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great... I see comments like This: >A very interesting language on powerful platform with a promising web framework... I talked with a couple of companies that jumped on it initially,…

Honestly I think you are doing things backward. With all due respect to the fantastic platform and vm that the erlang folks built, it's just not as joyful as elixir. And I feel like writing legible and organized code is easier in elixir since it's opinionated, about everything from directory structure to documentation to tests, and a couple of detailey things like structs are easier to read than records and macros are more sensible than string preprocessing

Re: Elixir v1.10

#119

A very interesting language on powerful platform with a promising web framework. Many saw it, myself included, as a Ruby / Rails Improved, and expected its quick growth. Unfortunately, initial enthusiasm a few years ago did lead to its wide adoption. I talked with a couple of companies that jumped on it initially, but later decided to move to Java, Kotlin, Go. The main reason was difficulty to hire engineers to scale…

Not specific to Elixir I think. There are not a lot of people proficient (or even having some experience) in functional programming, and there are not a lot of companies using functional programming neither (1/100? 1/1000?). The chicken and egg problem.

Outside of map/reduce, which honestly even juniors out of bootcamps learn these days, I don't understand the claim that functional programming is hard. It's easier, and usually safer, because you have to keep less things in your head while you're coding.

Re: Elixir v1.10

#120

Earlier quoted context omitted.

I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great... I see comments like This: >A very interesting language on powerful platform with a promising web framework... I talked with a couple of companies that jumped on it initially,…

Honestly I think you are doing things backward. With all due respect to the fantastic platform and vm that the erlang folks built, it's just not as joyful as elixir. And I feel like writing legible and organized code is easier in elixir since it's opinionated, about everything from directory structure to documentation to tests, and a couple of detailey things like structs are easier to read than records and macros ar…

Definitely agree, though I respect the effort/desire to learn Erlang first given the fact the first time I saw Erlang code I was so confused/put off by it, the syntax was so foreign (not c-like, not lispy), variable names up capitalized, atoms are bare words, source files are just tons of functions, the tooling isn’t anything like modern languages (though since Elixir and hex/mix, that situation has gotten way better), then you’ve got all the OTP behaviors which are entirely unique to Erlang/BEAM, Erlang’s documentation though excellent and extensive isn’t by any means beginner friendly (IMO), and to top it all off, unless you’re coming from another pure functional language you have to deal with working in a new paradigm. Basically, Erlang is intimidating, which is unfortunate because how powerful BEAM and the OTP behaviors are.

However, Elixir wraps up the power of the BEAM and OTP in a much more approachable package. The syntax is much more familiar (thanks Ruby), provides tooling on par with (and better than some) popular modern languages, the language itself also provides more modern user friendly features (macros, pipe operator, protocols, etc). All with a community that is very beginner friendly and willing to help.

If you want to make use of OTP/BEAM, Elixir is by far the best way to enter. When you learn Elixir, you will also learn the major OTP behaviors and concepts (Supervisors, GenServers, Applications, Registry). Eventually you’ll find that there are even more goodies in the beam not directly exposed by Elixir (genstatem, ets/dts/menisia,timer,digraph — are a few of my favorites). Fortunately though, you can call Erlang modules/code directly from Elixir (and vice-versa), so you’ll then eventually dip your way into playing with Erlang modules as needed and when you approach the docs after having experience with OTP with Elixir, you’ll notice a lot of things are familiar and the Erlang docs become much less intimidating.

Basically Elixir is a much easier entry point to Erlang. Erlang is a great language, but very different with a lot of new concepts and which can kill your motivation to learn how awesome the BEAM is, so if you want to learn Erlang, by all means give it ago, but if you find yourself frustrated/confused with it, try Elixir for a while, then come back to Erlang and I bet it will be a lot easier.

When I initially saw Erlang, I was put off, the docs were confusing and I would avoid them at all costs, always try to look for an Elixir wrapper. Now after having worked with Elixir a lot? I frequently find myself going to the Erlang docs first to find a solution instead rather than hex or whatever. I can easily grok my way through an Erlang projects source, which previously was completely foreign to me. Will I ever likely write anything serious in pure Erlang? Probably not. Am I saying if you learn Elixir you will also just pick up Erlang? Absolutely not. What it will do though is make the process of learning Erlang (if that’s the goal), and it’s absolutely massive built in library of tools/abstractions/patterns that no language I’ve seen comes close to replicating an order of magnitude easier.

Post reply on HN