
Programming languages to watch: LiveScript, Julia, Elixir - philippelh
http://adambard.com/blog/3-languages-to-watch/
======
enobrev
This may possibly be intentional, but seems a bit confusing. The original name
of Javascript was LiveScript when initially released with Netscape in the 90s.

[http://en.wikipedia.org/wiki/JavaScript#Birth_at_Netscape](http://en.wikipedia.org/wiki/JavaScript#Birth_at_Netscape)

Edit: It seems it is intentional:

"LiveScript was one of the original names for JavaScript, so it seemed
fitting. It's an inside joke for those who know JavaScript well."

[http://livescript.net/#name](http://livescript.net/#name)

~~~
tracker1
That is my single biggest issue with the LiveScript name... Not that most
people know this, it still bothers me a lot.

Though, I'm one of the ones who had the same kind of problem when Mozilla
named their new browser Firebird (before becoming Firefox).

------
gordonguthrie
If you are into functional programming and new functional languages we have a
good little conference called Mostly Functional going on @ Turing

[http://mostlyfunctional.com](http://mostlyfunctional.com)

We have two presentations on languages targeting the Erlang VM, Elixir and
Joxa, as well as other goodness...

(Disclaimer, I am the organiser)

~~~
goostavos
Whoa! Are those going to be recorded and made available? I would _love_ to see
the presentation on Building A Robot Army Of Raspberry Pis!

~~~
gordonguthrie
Yeah, erk, well reminded, I must get onto that. I am organising the event, and
doing that talk and I haven't finished writing the software yet...

~~~
goostavos
Self-serving self promotion: I work for a small little shop that does
conference recordings, so If you need help figuring out that side of things,
you can shoot me an email at chris at intelliquestmedia dot com.

We're based in the States, but the owner is a Brit. I'm sure he'd jump at an
excuse to head back and do some recording in the UK.

------
lubomir
What this article calls currying is actually partial application.

Partial application is a technique where you take a function that requires n
arguments, pass in the first one and get a function that needs n-1 arguments.

Currying is a technique where you take a function that takes n arguments and
turn it into a function that can be partially applied. E.g. in Haskell it
works with tuples as arguments. There is function 'curry :: ((a, b) -> c) ->
(a -> b -> c)' and its counterpart 'uncurry :: (a -> b -> c) -> ((a, b) ->
c)'.

~~~
adambard
You get a function that can take N arguments and return a value, or 1 to N-1
arguments and return a function representing a partial application, which
itself exhibits the same behavior:

    
    
       add3 = (a, b, c) --> a + b + c
    
       x = add3 1
       y = x 1
       z = y 1 # z = 3
    

If you look at the compiled code, it _is_ actually an abstraction over a
partial application, but at that point is that not just an implementation
detail?

~~~
lubomir
I agree it is not really important.

The main difference between the two I see is that partial application
basically binds a certain argument to a fixed value, while currying only
changes the way the function is called (thus allowing for easier partial
application). It is easier to see on a function with more than two arguments.
Imagine f:(A×B×C)->D. Currying it will yield f':A->(B->(C->D)), so you would
call it as f'(1)(2)(3). On the other hand, partially applying on first
argument it would yield f'':(B×C)->D.

------
why-el
Just for the record, Elixir was favourably reviewed by the creator of Erlang
itself.[1]

[1][http://joearms.github.io/2013/05/31/a-week-with-
elixir.html](http://joearms.github.io/2013/05/31/a-week-with-elixir.html)

------
gnosis
To me, much more interesting than _" a language targeting the Erlang VM..
[that] mostly imports Erlang's syntax"_ is:

Lisp Flavoured Erlang:

[http://www.trapexit.org/forum/viewtopic.php?p=40268](http://www.trapexit.org/forum/viewtopic.php?p=40268)

------
laureny
Of all the "Javascript.next" languages I hear on a regular basis, it seems to
me Microsoft's Typescript is the one most likely to become successful, if only
because every time I read an article about it, most of the comments are
extremely positive about it and it looks like there are already some fairly
large projects written in it.

In comparison, I don't see a bright future for Dart nor Livescript (although I
secretly root for Dart because I have more confidence in Google to take this
language somewhere interesting).

------
terhechte
I really like Julia. I'm currently playing around with it whenever I find some
spare time. I don't see it as a competitor to R, I think it could well be
something along the lines of Python or Go.

It is LLVM based, and already really fast even though it is still a 0.2 and
the JIT seems to have a lot of room for optimisation.

Whats more, it seems to offer just the right blend of language features: \-
Easily include C libraries via a simple ffi [1] \- It is homoiconic like Lisp
and thus allows for fantastic macro facilities [2]

\- It has solid parallel programming support via a Coroutines implementation
(Tasks) (similar to Goroutines as far as I can tell)

\- It is a non-pure functional language

\- In contrast to Go it has generics, so functional constructs like map,
apply, drop, reduce, fold, partition & friends are already in there (or can
easily be implemented) [3]

\- It has optional types, so that you _can_ assign types and the compiler will
check for it and mark errors and will be able to create optimised code, but
you don't have to [4]

\- Running external programs is a joy [5] (Example: a=readall(`echo hello`))

The community seems to be very alive. There's a simple web framework called
"Morsel" and I've recently set it up against a couple of contenders from the
web framework benchmark (cpoll-cppsp, phreeze, and some others), and even
though it is still a version 0.2, the performance for the json serialization
benchmark would be pretty close to Scalatra (I yet have to publish these
numbers, will do so soon).

I really hope that Julia will grow, as I love the choices that went into the
design of the language, and it would be a shame if it would be only a
replacement for R instead of something much bigger, as it is such a nice
language.

[1] [http://docs.julialang.org/en/latest/manual/calling-c-and-
for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-
code/)

[2]
[http://docs.julialang.org/en/latest/manual/metaprogramming/](http://docs.julialang.org/en/latest/manual/metaprogramming/)

[3] [http://docs.julialang.org/en/latest/stdlib/base/#general-
col...](http://docs.julialang.org/en/latest/stdlib/base/#general-collections)

[4]
[http://docs.julialang.org/en/latest/manual/types/](http://docs.julialang.org/en/latest/manual/types/)

[5] [http://docs.julialang.org/en/latest/manual/running-
external-...](http://docs.julialang.org/en/latest/manual/running-external-
programs/)

~~~
Synroc
I don't know if you have any experience with it, but how would you compare it
to clojure?

~~~
terhechte
I bought a Clojure book and started going through it, and I have some limited
experience with ELisp and Racket. I really like lispy (is that even a word?)
languages, so I tried to get into Clojure, also because I really like the
ideas behind ClojureScript and the various libraries for it. So far, my
experience has been mixed, I guess because I didn't read enough, or maybe it
is my unfamiliarity with anything jvm-related (having never been a Java guy),
as that's also something I constantly run into when I'm doing Scala. I'll try
to write a bit more in Clojure, but so far Julia felt easier to get into, and
I really like the ability to use types so that stupid errors don't result in
runtime issues.

There're way too many interesting languages these days :)

~~~
gtani
There's a few threads on SO that try to summarize what you need to know if you
haven't programmed in java before(and, yes, it's a decent amount), e.g. what a
JAR is, classpath, -server vs. -client, -Xmx and Xms, GC options etc.
Alternatively, ask on reddit, IRC or the mailing list

[http://stackoverflow.com/questions/5721496/learning-java-
so-...](http://stackoverflow.com/questions/5721496/learning-java-so-i-can-get-
at-clojure)

[http://stackoverflow.com/questions/11358929/what-should-a-
sc...](http://stackoverflow.com/questions/11358929/what-should-a-scala-
developer-know-about-java-and-or-the-jvm)

[http://www.reddit.com/r/Clojure/comments/1ev4u5/what_do_i_ne...](http://www.reddit.com/r/Clojure/comments/1ev4u5/what_do_i_need_to_learn_about_java/)

~~~
terhechte
Thanks! These look very helpful! I'm currently doing quite some Scala and the
problems are very similar, so I bet that these will help me a lot.

------
noelwelsh
Nice selection.

Livescript looks like it fixes some of the warts of Coffeescript while also
raising the level of abstraction.

Julia is something I've already been looking at. I'm a bit torn on it -- it
has vastly fewer libraries than Scipy and R so I don't know if I'm ready to
"wear the hair shirt". At this point in life I'm more concerned with doing
stuff with existing libraries than building the libraries myself.

Elixir I'm less excited about, because I'm not so excited about Erlang. I feel
that Scala provides all of what I'd want from Erlang, along with better
sequential performance.

~~~
ihnorton
_it has vastly fewer libraries than Scipy and R_

The incredible PyCall.jl package allows use of existing Python libraries from
Julia with automatic object translation, including no-copy use of NumPy
arrays:

[https://github.com/stevengj/PyCall.jl](https://github.com/stevengj/PyCall.jl)

There is also heavy work on a Julia IPython kernal, which is under testing
right now and very close to release.

------
AndyKelley
Shameless plug: My 2d canvas-based game engine supports LiveScript out of the
box:
[https://github.com/superjoe30/chem/](https://github.com/superjoe30/chem/)

~~~
ZoFreX
Thanks for the link, this looks like a fun way to try out LiveScript! :)

~~~
AndyKelley
Enjoy. To use LiveScript just use the .ls extension instead of .js. That
includes chemfile.js (chemfile.ls for livescript)

------
sinkasapa
I hope that some Elixir features make it in to Erlang but I guess I'm one of
those rare people that likes the Erlang syntax a lot better. I don't really
understand the hate for it, it seems so clear and specific. Anyway, if people
want choices for an Erlang like experience, without the Prolog syntax, check
out LFE:

[https://github.com/rvirding/lfe](https://github.com/rvirding/lfe)

~~~
rhizome31
The thing I don't like about Erlang's syntax is that often I have to change
the character at the end of the line when I need to move a line. It makes
refactoring more tedious. I have no problem with it when reading code :)

------
oinksoft

      Some other cool features of Elixir:
        ...
        * List comprehensions
    

I'd just like to point out that Erlang has list comprehensions as well.

~~~
adambard
Shh! I know, the list just looked dumb with only two items.

~~~
reeses
Feeling a little Rick Perry this morning? :-)

------
_sh
The language I'm most interested in currently is kernel: mathematically
underpinned by the vau calculus, with a smart creator and steward, and a
better abstract model for macros than even Racket's stellar syntax-parse.
Implementations abound.

[http://en.wikipedia.org/wiki/Kernel_(programming_language)](http://en.wikipedia.org/wiki/Kernel_\(programming_language\))

~~~
takikawa
> and a better abstract model for macros than even Racket's stellar syntax-
> parse.

To clarify a little bit, `syntax-parse` is actually not its own model for
macros but is a sophisticated front-end for Racket's underlying macro system
(described in this paper:
[http://www.cs.utah.edu/plt/publications/jfp12-draft-
fcdf.pdf](http://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf)). Also
see Jay McCarthy's blog article that tries to clarify this:
[http://jeapostrophe.github.io/2013-07-22-123list-
post.html](http://jeapostrophe.github.io/2013-07-22-123list-post.html)

Racket's macro system and Kernel's fexprs are pretty fundamentally different,
so I don't think the comparison is very apt. In particular, Racket's macros
can be entirely compiled away.

~~~
_sh
While true, I was comparing macro APIs from a usability perspective and should
have avoided the term 'abstract model'.

My point was the _mental model_ I refer to when using $lambda is simpler and
easier to understand than my mental model for syntax-case, syntax-rules,
syntax-parse and friends. The very fact that 'Racket's macros can be entirely
compiled away' complicates my mental model which must now accommodate
'phases', compile-time/run-time dichotomies, require for-syntax, etc.

------
ambirex
When looking at languages like LiveScript (or CoffeeScript) I say to myself:
"Javascript has been around for 18 years, how long will this be around for?"

Not saying not to use it, but my use case has to overcome that question.

~~~
noelwelsh
With Coffeescript (I don't know about Livescript) the compiled output is close
enough to hand-written Javascript that, if Coffeescript suddenly disappeared
into a black hole, you could use the compiled output as source if needed.

~~~
adambard
Livescript is a fork of Coffeescript, and LS 1.2 purports to have improved the
JS output for readability, so I think you'd be ok.

~~~
AndyKelley
Livescript is technically a fork of coco[1] which is a fork of Coffeescript.

[1]: [https://github.com/satyr/coco/](https://github.com/satyr/coco/)

------
bayesianhorse
Julia is in a weird place. It improves in speed over R and Python, but the
head start of both of these languages is strong. Also it will be some time
until julia can provide equivalent support for GUI and Web programming.

~~~
adestefan
Julia fits well as the next step from Matlab. I've already seen groups of
engineers across various disciplines that have turned to Julia instead of
Matlab.

------
acjohnson55
How is currying better than partial function application (particularly with
keyword arguments)? If your function isn't commutative, then it seems to give
greater importance/flexibility to the first arguments.

~~~
gohrt
As usual, the terms are misused.

Any discussion of currying vs partial function application needs to start by
explicitly stating what the author intends each to mean.

~~~
acjohnson55
Fair enough, but is currying "better" than partial function creation in some
way?

------
kenjackson
I've been playing with TypeScript a fair bit lately. Really like it:
[http://www.typescriptlang.org/](http://www.typescriptlang.org/)

Haven't used LiveScript yet.

~~~
lightblade
I was a bit torn between LiveScript and TypeScript. But after using both a
bit, I think I like LiveScript better.

I feel TypeScript doesn't offer much beyond static type checking, and this can
be compensated by using closure compiler together with LiveScript.

------
pc86
As someone who has just this week started serious study of Erlang, I'll have
to look at Elixir as well. Ending statements with periods does take some
getting used to!

------
lsdr
Have yet to take a look in Julia, but I've been playing around with Elixir for
a while and looks great. Elixir macros particularly got my attention:

[http://elixir-lang.org/getting_started/5.html](http://elixir-
lang.org/getting_started/5.html)

There is a book on Elixir coming out from Pragmatic Programmers sometime and
will be written by Dave Thomas, which might generate a certain buzz too. This
may be a good time to dive into it a bit more.

------
santialbo
LiveScript looks amazing. I love how much F#-y looks. I'm definitely going to
start using it for personal projects.

------
gpsarakis
Julia and Elixir definitely seem worth checking. I especially like the
interchangeability between Erlang & Elixir.

------
stewbrew
What features do these languages offer that make it worth watching them?
Neither of them seems to offer anything novel.

------
nnq
I really hope people would promote Livescript or GorillaScript more, as better
compile-to-js languages.

...Coffeescript stole the spotlight and nobody wants to hear about anything
else, but it's mediocre and boring language-wise!

~~~
jashkenas
As the creator of CoffeeScript, I hope so too!

A big part of the original idea with CoffeeScript was to exhaustively annotate
the compiler so that folks could take it, and run off in more radical
directions. Whereas CoffeeScript is intentionally conservative (no standard
library beyond what JavaScript offers is allowed, for example), the fact that
LiveScript is a fork off Coco, which is a fork off CoffeeScript, is a
wonderful tangent.

There are static and optional typing flavors, asynchronous-flow-control
flavors, macro-oriented flavors, functional ones, contract ones, and of course
the rewrite of the basic language itself. In open source, there's enough
spotlight for all of 'em.

------
ilaksh
Also check out ToffeeScript.

~~~
reddit_clone
Also for people coming from Haskell/ML background there is GorillaScript.

------
kldavenport
What about R?

~~~
pwang
What about it? It's 20 years old this year, and the language it was meant to
clone, S, is almost 40 years old. What's new to keep an eye on?

