[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 17169



File: 1466463564972.png (41.2 KB, 300x231, elixir.jpg)

No.17169

How the hell is nobody talking about this great language here on >>>/λ/ ?

Resources:
http://it-ebooks.info/search/?q=elixir&type=title

  No.17170

because it is shit

it's literally just for noobs that can't cope with erlangs syntax

  No.17171

The last Elixir thread died because of a severe lack of activity.

I'm a Lisper, so I would just use Lisp-Flavored Erlang if I wanted to try an Erlang-like language.

While I'm at it though, what does Elixir do that makes it so great?

  No.17172

Eww, a python-looking language that runs atop a VM of a language that had already a better syntax

>>17171
>... so I would use an Erlang-style DSL written in CL
fixed

  No.17176

Guys remember that not everyone has the time to be learning complex syntax.
If you need to program something simple, there is no need to learn all the intricacies of a language.
Languages like Python (or Elixir) serve a purpose. I don't understand why having more languages to pick from is a bad thing.

  No.17177

>>17169
Why do you think this language is so good?
What makes it unique, as your post seems to imply?

  No.17188

Most of the interesting stuff is shared with Erlang,
that is, BEAM and OTP.

That being said, Elixir adds good things on top of it,
like macros, string handling, the `with` block, the
pipe operator, etc

Only think I actively dislike about Elixir is the
pin operator. Variable matching should be the default,
like in Erlang.

>>17176
Erlang's syntax isn't complex, I actually find it really cohesive, almost no special cases.

  No.17189

What I would actually like to see is a
language with the same runtime guarantees
as Erlang-OTP but with a ML/Haskell type
system.

There is Pony (http://www.ponylang.org/),
but I haven't looked too much into it to
say

  No.17197

Lainchan seems to really really hate anything that's good at web development, and is pretty elitist around anything that isn't lisp or scheme, from my experience.

Elixir is kind of cool. The BEAM VM is a really cool technology that it's nice to have outside of Erlang. It'll be really interesting to see if it takes off in a way that erlang never did.

Slightly off topic, I'm surprised people in this thread seem to think syntax of anything would ever be a stumbling block.

Do people really not learn languages just because of the syntax?

Oh and inb4 durr hurr brainfuck etc etc, they're tired joke languages that haven't been funny in at least a decade.

  No.17198

>>17197
>Lainchan seems to really really hate anything that's good at web development, and is pretty elitist around anything that isn't lisp or scheme, from my experience.
Well, there's probably more Lispers here than any other type of programmer.
I wouldn't say there's much bias though. There's plenty of people that like plenty of languages. I've not really seen anything I would consider elitism. This board is very civil.

It is my opinion that a language shouldn't be centered around web development. Any good language would probably be fine for it, along with many other uses.

>Slightly off topic, I'm surprised people in this thread seem to think syntax of anything would ever be a stumbling block.

I don't know the syntax of Elixir. Would you say it's an ALGOL-like?
Syntax is a big deal. Much complicated syntax can severely impact someone's ability to learn and remember a language.
Some languages only expose language features through syntax, which can make metaprogramming and other cool features more difficult to work with.

>Do people really not learn languages just because of the syntax?

I do. Simple syntax seems better in most cases. Take the order-of-operations, for example; it's easier to use a language that has extremely simple order-of-operations. Lisp uses prefix notation, Forth uses postfix notation, and APL uses infix, but the order-of-operations is uniformly right-to-left and superscalar operations are still easy because almost everything operates on arrays or can be made to easily.

I'm getting off-track though. Where is the Elixir standard document? I would like to take a look at it, see how long it is, and see how Elixir handles the qualities I've mentioned above.

  No.17200

>>17197
>Lainchan ... is pretty elitist around anything that isn't lisp or scheme, from my experience.
I wouldn't know what percentage of the users are like this.
But the lisp general was moved over here from /g/ for obvious reasons so the lispers all come here. And most of them are smug and loud about it. Just don't mind them.
>Do people really not learn languages just because of the syntax?
I am the one who complained about the python syntax. I don't mind people using the language they feel best at home with. I was just pointing out that it is no improvement in syntax whatsoever. I personally like more the ML syntax so I might be biased.
So, sorry if I came out as biased with my post. I didn't see the point but I guess you can write Erlang VM assembly if you like

I should add:
It's the internet. People are going to tell you what you like is shit, whatever it is. Don't listen to those people, don't follow the crowd blindly, do your thing. Those who are louder are more likely to be heard, but are the ones that you shouldn't listen to because they're too busy complaining to do worthwhile stuff.

  No.17201

>>17198
>I don't know the syntax of Elixir. Would you say it's an ALGOL-like?
Decently so, with some deviations. At least if one's experiences with ALGOL-derived languages is via more recent incarnations (Python, Ruby, JavaScript, PHP). You could write Elixir using an aggressively imperative flow within your function definitions, but if you lean heavily on pattern matching, as you are encouraged to do, it would feel a little alien to anyone not experienced with that. Except perhaps Rubyists, due to Ruby's unconventionally powerful switch statement--or rather, Ruby calls it a "case" statement.

One of the _only_ things I dislike about Elixir is that they allow reassigning variables. I always admired the "equals sign emulates mathematical equality" aspect of Erlang. Allowing re-assignment is certainly more familiar/less confusing to people coming from ALGOL-descended languages.

For anyone not familiar, the idea is called "single assignment" and an example is if you run:
a = 1
b = a
b = 2
You would get an error on the third line. Having already declared b to equal 1 via its equality with a, trying to declare "b equals 2" is mathematically false, and hence an error.

>It is my opinion that a language shouldn't be centered around web development.

I think there is a distinction to be made between the phrasing "good at web development" in >>17197 and "centered around web development". A language is capable of being good at web development if it has a baseline ease of text wrangling (useful string libraries, decent regex engine) and half-decent built-in facilities for networking and concurrency.
Where languages become known for being "good at web development" is mostly when the community/ecosystem strongly supports tying together all the bric-a-brac that web development tends to rely on. Database drivers, common application architectures, templating engines and what-have-you.

I'm not sure what it would mean for a language to be "centered" around web development. Maybe if the standard library was designed such that it avoided implementing anything that wasn't useful in a conventional web stack? I'm not sure I know of any such languages besides PHP.

I think what >>17197 is saying, is that if the community/ecosystem around a language tends to include (or even promote) libraries and tools which support web-viability it will tend to take flak from people whose needs and focus do not include web development, and thus whose language choice similarly diverges.

  No.17213

>>17200
>It's the internet. People are going to tell you what you like is shit, whatever it is. Don't listen to those people, don't follow the crowd blindly, do your thing. Those who are louder are more likely to be heard, but are the ones that you shouldn't listen to because they're too busy complaining to do worthwhile stuff.

Words to live by.

  No.17214

>>17201
Is there any reason why you don't like re-assignment?
I mean.. I don't understand why you would prefer to have less flexibility.

  No.17215

>>17172
The syntax is heavily inspired by Ruby and _not_ by Python. The differences should be obvious…

>>17198
>Simple syntax seems better in most cases. Take the order-of-operations, for example; it's easier to use a language that has extremely simple order-of-operations.
Do you have a source for this? Like a study or something similar or is this just your personal experience which may just count for you and not for everyone else.

>>17201
>I dislike about Elixir is that they allow reassigning variables.
Just to make this point clear: You don't reassign variables in Elixir. You're just creating a _new variable_ with the name of the old one (like a' in a mathematical context). If you passed your old a to a function and override your a with a new value the function still has the old a.
I'm not sure if I like this practice but it's definitely free of side-effects.

>>17214
Elixir is designed for highly concurrent programming - which wasn't really said itt - that means you have hundreds or thousands of concurrent processes/threads which are managed by the BEAM-VM (sounds scary, I know, but just werks - really). So if you just passed a variable (or better called a constant for the people with non-functional background) to multiple processes and each works with your value and then one process changes your value shit will brick.
A very fast forward explanation of this could be found in the 'Getting Started'-Guide[0].

At the end some words to these "web-only"-myth: I read myself into Elixir in the last summer and did some small projects to learn the language where the biggest one was an IRC-Bot with some features which still runs today. So I haven't touched one of those fancy web-frameworks so far and won't say it's a web-language. The "Programming Elixir"-book which I used had irrc not one chapter (or even an example) for this purpose. Of course you're free to use a framework like Phoenix and make some fancy web-shit but that's just a part of what Elixir has to offer.

[0] http://elixir-lang.org/getting-started/processes.html

  No.17221

>Do you have a source for this? Like a study or something similar or is this just your personal experience which may just count for you and not for everyone else.
No, but I would think only one or two rules for the order of operation would be easier to remember than, say, 15, which some languages actually have.

  No.17228


  No.17240

>>17221
Just learn the basics. For the most part it's pretty intuitive: numeric to numeric operators get evaluated first (e.g. +, -, /, *: you should know PEMDAS for this), numeric to boolean second (e.g. >, <, etc: equality in general is usually handled with an operator at this level of precedence, e.g. ==), and boolean to boolean next (e.g. &&/and, ||/or, etc). This is easy to memorize because it's the natural order that values generally fall through in practice-- there generally are no operators that convert boolean to numeric (though some languages allow for + etc to do this, it's not often seen in practice anyway), so naturally the higher precedence should be given to the operators that generally get evaluated first. For example, imagine if we had to write `x == (y + 3)` all the time: almost never do we mean `(x == y) + 3`, so the former example is what should be parsed from `x == y + 3`.

Think about it: you already have 4 levels just in normal arithmetic, and programming languages have assignment operators, bitwise operators that are scattered (hint: they're one level below the logical/"short circuit" version of the operator), boolean operators with different levels (and is higher than or-- this is mimicked with bitwise operators too), ternary operators, etc. If you just memorize the basic rules you're already 4/5ths of the way to understanding everything, and the last 1/5th of knowledge you gain you probably shouldn't use anyway, so as to not confuse other programmers. Memorize the rules, not every individual level operator by operator.

  No.17241

>>17228
The implementation of that language is very simple, but the interface to its functionality is complex.

>>17240
General arithmetic is easy enough in part because it's been hammered into most of us since youth.

I simply don't want to learn a language that would operate like this.

>the last 1/5th of knowledge you gain you probably shouldn't use anyway, so as to not confuse other programmers.

I'm of the opinion this simply shouldn't ever be the case.

  No.17243

>>17241
>General arithmetic is easy enough in part because it's been hammered into most of us since youth.
I don't like operator precedence either (I prefer Lisp's syntax) but this isn't a serious problem. If you're choosing not to learn languages because of something like this you're missing out on a lot. There are more interesting things to worry about than syntax.

  No.17244

>>17200
Hopefully I didn't offend, my post was more directed at >>17170 since dismissal of new languages without any kind of elaboration seems really counter-intuitive to discussion.

>>17215
>that means you have hundreds or thousands of concurrent processes/threads which are managed by the BEAM-VM

I find this really interesting, does it work somewhat like goroutines or fibers? I'm struggling to conceptualise it against something like yoru standard thread.

I really like the idea of the BEAM VM though, I once saw a talk where someone essentially, for lack of a better word, ssh'd into an erlang program to see all the inner processes. Really cool.

>>17243
>There are more interesting things to worry about than syntax.

I couldn't have said this better myself.

  No.17245

>>17201
>I'm not sure I know of any such languages besides PHP.

You could also maybe put node into that category? It's kind of a strange case to begin with though and definitely feels a lot more professional than PHP.

  No.19285

Elixir will become the dominant web language. Right now node.js is big only because its using callbacks as a trick to fake concurrency. Elixir has real multiprocess concurrency and so can maintain connections for a long time though things like websockets, whereas callbacks have to be executed as quickly as possible or it will hold up the entire server.

Clojure gained a lot of ground as being the one functional language that everyone tried to use for general purpose programming, including web programming. For all of Clojure's popularity, it has failed to become mainstream because Clojure's homoiconic syntax is too difficult to reason about for regular programmers. Elixir's syntax is very Ruby-like, it will be an easy transition for many programmers. Erlang's syntax is soykaf and you can tell it was purposely gimped to only work on telecommunications (ie no string types).

  No.19286

I'm seeing a lot of Elixir and Elm jobs going around the place, though I've used neither myself.

  No.19304

>>17169
Surprised nobody mentioned Elixir's macro system. It's quite lispy and much like in CL you can implement your own control structures quite easily.

  No.19305

>>19285
Node.js is big because javascript is big. Javascript is big because netscape navigator included it.

Technologies don't become commonplace because of their inherent quality. They become commonplace because they were at the right place at the right time when standards are picked.

  No.19306

>>19305
>Node.js is big because javascript is big.
no thats not true, even if Javascript were an obscure language it would be the best language to implement a concurrency system built on callbacks because Javascript functions are inherently object based without being tied to classes which makes them much more independent than what you could implement with Python, Ruby, Java, C#, etc

  No.19309

>>19304
the macro system is nice, but if youre going to use a lot of macros it would be better to use a language with homoiconic syntax. Such a language exists for the Erlang platform, its called Lisp Flavored Erlang, its a Lisp that compiled to Erlang.

  No.19311

>>19306
Too bad javascript is the only language that isn't Object Oriented!
Not like things such as lisp, haskell, ML, perl, lua, forth, etc exist.

  No.19319

>>19306
This. Javascript stayed at the forefront because of the asynchronous nature of DOM events and other network events (Ajax) that require a function to be passed. An in keeping Node uses this system and the fact that V8 was/is highly optimized to use an already existing javascript implementation to perform server side tasks.

It's a really good choice on Node's behalf. This allowed front end developers, which was the only purview of Javascript at the time, to move to the back end logic of a 'web app'.

  No.19321

>>19311
>CL, ocaml, perl, and lua don't have objects
are you high?

  No.19323

>>19321
lets not feed the OO troll, these Java/C#/C++ enterprise gurus are all butthurt because their skillsets are becoming obsolete so they constantly spam 'me too' posts on anything having to do with modern programming

  No.19332

for those who are interested here is an interview with the creator of Elixir:

http://softwareengineeringdaily.com/2016/04/18/elixir-erlang-jose-valim/

I've never used Elixir (and Erlang only briefly years ago) myself but is an enlightening interview

  No.19337

>>19321
>without being tied to classes which makes them much more independent than what you could implement with Python, Ruby, Java, C#, etc
Python is inherently OOP, Ruby is inherently OOP, Java is inherently OOP. I don't know anything about C#
CL is not inherently OOP, perl is not inherently OOP, ML is not inherently OOP, I don't know about OCaML
you said
>the best language to implement a concurrency system built on callbacks because Javascript functions are inherently object based without being tied to classes.
I don't know what you mean there by "object-based" but there's certainly a reason functions are not tied to classes in javascript: it's not inherently OOP like python, java, ruby, which are the ones that you happened to mention.
Essentially, you were saying something along the line of
>this non-OOP language is the best because it doesn't have [restriction] from [List of OOP languages]

  No.19355

>>17215
>Do you have a source for this?
Not the same guy, but...
Don't need one! Children are taught PEMDAS all over the world. There is no one living in the first and second worlds who haven't grasped the idea of PEMDAS yet. This makes syntax using PEMDAS inherently better than syntax using prefix notation or whatever, simply by virtue of the fact that you have to learn a whole new syntax for *simple arithmetic expressions.*

This is just an example, but I intend to illustrate that many standards and design choices in syntax are not as arbitrary as you assume. It's not a matter of opinion. It's not the same thing as choice of colorscheme. There are, in fact, syntax choices that are inherently easier for everyone to grasp.

  No.19365

>>19355
That depends on the person. I have dyscalculia, so I've always had trouble parsing code and expressions that rely on order of operations.
I find the Lisp style much more natural, since there's no possible ambiguity. I could never understand why some people have trouble with it.

  No.19454

I'm lucky enough to get to use Elixir/Phoenix for prod and so far it's been great.
It's good as a babbys first functional language (easy to tutor new coworkers), fast to prototype with and scales like hell. It does take some time to adjust your thinking to OTP though.

  No.19613

And what is special with that language?

  No.19620

File: 1477299334541-0.png (305.01 KB, 69x200, プロガール・1.png)

File: 1477299334541-1.png (72.21 KB, 106x200, プロガール・2.png)

>>19355
prens, basically.

lots of verbosity, uniformity, repetition, and irregular structuring => a language that is very difficult to skim

elixir a best, though. good symbol variation, distinct syntactic roles, and well, structured code layout, with consistent use of indentation.

pretty sure it's just a difference between being visual-oriented and auti^H^H^H^Htext-oriented, same as some people hating syntax highlighting as a "distraction" while others have a tough time working without it.

  No.19621

>>19620
derp, meant for >>19365

  No.19788

>>19337
Actually, JavaScript is object oriented without using classes. JavaScript: The Good Parts explains it decently.

The O in OCaml stands for "objective", by the way. Also, object orientation is part of ANSI Common Lisp and is part of the type hierarchy iirc.

  No.19815

>>17169

Elixir is a pretty fun language, but I have been running into some issues with it (and these same issues do exist under Erlang, so no buli pls).

So, my domain is trying to write a game engine (why? because fuarrrk you that's why!)--this has some inherent workloads that color the problems I'm running into.

First and foremost, Erlang/Elixir/BEAM will *never* be top-of-the-line when it comes to numerics. IEEE754 floating point is not fully supported, there is no real support for NaN (a value important for interop), and arithmetic exceptions are handled differently than we're used to in other languages.

Furthermore, collections of numbers (say, for vectors) are stored in either cons-lists (ala Lisp), maps (hashmaps), tuples (array of pointers to numeric values), or keyword lists (array of tuples acting as an attribute list). This means that the numbers themselves are stored discontiguously in memory, and as such prevents the use of modern SIMD instructions.

You can work around this with binaries and NIFs, but that has other problems--especially from a development standpoint.

Second, memory is immutable. This means that certain workloads--updating a framebuffer, doing vector arithmetic of any real size--are by their nature going to create a lot of garbage. This has negative impacts on performance, to the point of breaking everything.

Third, Elixir supports arbitrary precision integers. This is fine and all, but when you try and move those values into a fixed-width integer (for, say, a binary message used for interop) the runtime elects to truncate instead of saturate, and so the resulting fixed-width int will often just contain the lower bits (assuming you've picked the correct endianess) of what you'd prefer to be an 0xffffffff pattern or similar.

~

It's a wonderful language, but there are some things that make it a little rough in certain problem domains. That's just the nature of the beast. :)

  No.19819

>>19815
Thats pretty impressive that you made a game engine in Erlang/Elixir. Using any interpreted language to make a 3D game I think would use wrapper libraries to do math instead of handling it natively. Erlang/Elixir should really only be used for make servers to support multiplayer.

  No.19820

>>19819

Am making, not "made"--but thank you for the compliment. :)

The basic architecture is that the game logic and networking and all that should live in Elixir, and then I run some applications/GenServers that port out to native code to handle input event collection, graphics, and sound.

Theoretically one could write an Elixir TCP client for X and thus never touch native code, but I lack the patience for that.

  No.19931

>>19820
You could generate a library using macros from the xcb specifications like guile-xcb does.

  No.20021

>>17172
>python looking
How? It doesn't look at all like python.

For context, I'm pro-python anti-elixir, not the other way around.

  No.21600

There is a really short book/videos set called "Take off with Elixir":
https://bigmachine.io/products/take-off-with-elixir/
The guy is charging $40 for it which is way too much. If anyone can find a download link or has this and can upload it to a download site I appreciate it