[–] chubot link

FWIW the demo snippet is a toy and not the real quicksort, which is in-place, rather than copying the list / creating garbage at every step.

Ironically it says "A powerful language for building scalable systems on the JVM" but this literally doesn't scale as quicksort does.



This is related to the "Genuine Sieve of Eratosthenes", which is also an imperative algorithm and NOT a functional one:


This brings to mind the slur "Haskell (Lisp) programmers know the value of everything but not the cost".


[–] moomin link

For people new to the party, this looks great. For those who had been following the GHCVM project, it's a horrible disappointment.

Basically, this project used to be a fork of the Haskell compiler to support the JVM. Now it's a fork of the Haskell compiler that may or may not be compatible for your use case depending on their opinion of GHC's features.


[–] swlkr link

The website is exactly what a programming language website should be. Syntax and features front and center.


[–] jfe link

i feel like each "new" general-purpose language project is just nipping at the boot-heels of the much bigger problem of constructing large-scale systems that can be fully understood by a few (2-3) people.

VPRI's research has shown that one important method for constructing large-scale systems that can be understood by small teams is to have a pipeline of problem-specific languages that express major portions of the system. they were able to reduce LOC for a typical OS with networking and graphics by 3 or 4 orders of magnitude.

general-purpose languages can't compete with DSLs in terms of expression, and yet we keep inventing them. i think our lack of imagination is starting to show. compilation and language design will need to become much more common-place if we expect to continue scaling up.

a tower of babel in computing is healthy, no matter how much employers want us to be easily-replaceable cogs in an IT machine.


[–] virtualwhys link


Haskell <> JVM with Eta[1]

Scala <> Native with Scala Native[2]

One language to rule them all. Personally am rooting for both becoming a success, though Eta may have the easier path given that it can piggy back on the JVM, while Scala Native will have to, for example, come up with a plausible GC solution (i.e. matching JVM's world class GC is a tall task to say the least) along with porting myriad Java/Scala libs to native.

[1] https://github.com/typelead/eta

[2] https://github.com/scala-native/scala-native


[–] psibi link

This is the relevant github repository: https://github.com/typelead/eta

And this is the blog post from the co-founder of Typelead (the company behind Eta) discussing about it: https://blog.typelead.com/https-blog-typelead-com-introducin...


[–] general_ai link

Java's hunger for memory, combined with Haskell's unpredictability wrt memory allocations due to laziness. What could possibly go wrong.


[–] taylodl link

Why do we need this? We've already had Frege (https://github.com/Frege/frege) filling this role for roughly three years now. Seems to me the DRY principal doesn't just apply to personal projects but to public works as well.


[–] omaranto link

Looks like they don't acknowledge it on the landing page, but this is probably an implementation of Haskell, or of a dialect of Haskell.


[–] lacampbell link

I'm interested in what the trade off between "lazy by default" and "Eager by default, with some great lazy data structures you can use" is?

Often programming language support for streams will feel a little second class, and I'd love to have something as first class seeming as Haskells lazy list - but that's a minority of the time for me.


[–] kaykay link

There is a bug in the code, unless the input is expected to be a set instead of a list.

I believe the right implementation should be something like:

  main :: IO ()
  main = print $ quicksort [1, 123, 42, 90, 1, 23, 24, 12, 3]
  quicksort [] = []
  quicksort (x:xs) = quicksort left ++ [x] ++ quicksort right
      where left  = [ y | y <- xs, y < x ]
            right = [ y | y <- xs, y >= x ]


[–] danielam link

There's a bug in the quicksort implementation example (it assumes all values in the list are unique).


[–] ww520 link

Looks similar to Haskell.

Edit: Darn, I'm stupid. It's a port of Haskell to JVM.


[–] pyrale link

That's great news !

I'm quite disapointed by the decision regarding GHC8, though. Overloaded record labels adresses a problem which the community was quite annoyed with, for instance.


[–] benol link

Does it come with a debugger of any kind?

I think this is the biggest gap in the Haskell ecosystem right now. Every time I try to write something in Haskell, I remember I cannot "talk to my program" easily and just give up.


[–] danidiaz link

I don't really mind if Eta ends diverging from Haskell in the particulars but remains Haskell-like à la Purescript.

I'm curious about how the jvm will behave in regards to laziness and typeclasses (MTL-like libraries, in particular).


[–] cle link

How is this "scalable"? What does that mean?


[–] omaranto link

The quicksort example seems oddly named, I would have called it "unique" or "removeDuplicates".

If you change one of the inequalities, say ">" to ">=", then it does sort (without removing duplicates). It still wouldn't feel fair to call it "quicksort" because it isn't in place.


[–] sandGorgon link

Awesome! built in Bangalore - http://typelead.com/contact-us/index.html#our-office

The stock image on the about-us page threw me off. Great going guys!

We have already been sold on Kotlin... but Eta looks interesting.


[–] preordained link

Hmmm...could get me back into Haskell (cough--mean Eta). I always hated the Haskell environment. A nice to work with port to JVM could inject some life back into that interest. There was Frege, but it just seemed fringe at the time...we'll seem if this has any steam behind it.


[–] nnq link

This makes me wonder again: is there any such language but for people wanting an eager (not lazy) Haskell?

(and I don't care for it to be JVM. but I do care for it to be be Haskell... OCaml is not Haskell and has too many weird dark corners imho)


[–] MaxLeiter link

Has a gitter and slack but no IRC?


[–] blunte link

If they had any marketing sense, they would start by telling me why it's better than Clojure. I'm sorry to offend the Scala guys, but if you want to be the best JVM language, you need to improve on Clojure.


[–] ibejoeb link

One of these must need some division...

    feet2Meters :: Feet -> Meters
    feet2Meters (Feet ft) = Meters $ ft * 0.3048

    meters2Feet :: Feet -> Meters
    meters2Feet (Meters m) = Feet $ m * 0.3048


[–] geff82 link

When you write about this new language, you'll be on the no-fly list soon :)


[–] hyperpallium link

Seems 99% written in haskell/eta itself, with a little c.

So, the compiler won't run on the JVM... if it did, there could be haskell dev on-the-device for Android...


[–] catnaroek link

I'd like to know if the most scalable technique for reasoning about program data works: structural induction!

Is Eta strict or lazy?


[–] Rapzid link

This looks really cool. How are the language services coming along? Can we expect something on par with F#'s?


[–] hacker_9 link

I really don't understand the need to squeeze as much functionality as possible out of as few lines as possible, that the code makes no sense no read. How am I supposed to parse the cryptic beginning example which shows the 2048 game being played? It looks like a ton of stuff has just been hidden way, which is fine for the example but likely all falls apart when you try to add something new to the game.


[–] andrzejsz link

Does anybody knows about syntax highlighting support?


[–] mistaken link

I'd personally just support Frege more instead of reinventing the wheel. https://github.com/Frege/frege


[–] TurboHaskal link

What an unfortunate name.


[–] eta link