Yeah and it also allows addressing beyond 2GB. I've been using DirectByteBuffers for the sake of being compatible with Android which I think doesn't give you access to the Unsafe API probably. I'll see if I can add a compiler option to use Unsafe for the JVMs that have it in the future. That'll probably do wonders for performance since Unsafe APIs are intrinsics. Unsafe is currently used in the Eta RTS for atomic CAS operations (which should be compatible in Android) on some of the RTS data types.
Throughout eta-lang.org we use a custom syntax highlighter we developed for CodeMirror (used in the playground) and Pygments for the static code examples throughout the docs. We will translate these to other platforms like Emacs, Vim, Eclipse, IntelliJ, etc. once IDE support is better.
You can use JVM debugging tools and with a guide on how to interpret the results for Eta (or a tool that does the mapping to Eta source code for you), debugging can be pretty awesome. The implementation was specifically designed to re-use the JVM Thread stack as much as possible so that you can get stack traces and figure out the source of the error. You'll get stack traces similar to other JVM languages like Scala and Clojure. See http://eta-lang.org/docs/html/eta-user-guide.html#debugging-... for an example. You can use tools like slf4j-ext as java agents and get nice traces - it's how I debug the Eta runtime.
Performance of a tiny code sample is not why people select one language over another. If that was the case, no one would be using anything besides assembly or C. Even in other languages, you'll use an abstraction heavy implementation for the benefit of long-term maintenance and code evolution and then performance optimise the bits that can pack a punch. Performance optimisation in any language looks ugly be it C or Haskell.
There are plans to make the compiler self-hoisting once it's more stable. The little bit of C used is just to turn on an option in the GHC runtime for profiling purposes. That would be replaced with some Java code to turn on an option in the Eta runtime if it were self-hoisting.
I should mention that a good testing discipline is required in Eta as well but you would focus your testing on high-level properties using frameworks like QuickCheck. Moreover, you don't lose as much if you don't write tests like you would in dynamic languages like Clojure.
Thanks for the example! My point was not that you can't test effectively in Clojure, but just that doing things like refactoring is much easier in Eta because of the numerous static checks.
Laziness by default does not mean you can't have strict primitive types, which Eta does. Moreover, if you ever want to avoid object references in performance-sensitive contexts, you can allocate off-heap memory and work directly with that via the Ptr mechanism (which is backed by DirectByteBuffers). GHC 8 recently got compound values with an extension called UnboxedSums. It would be tricky to implement on the JVM though in Eta, but not impossible.
Lisp is sexy, but parenthesis are a really hard sell for the wide crowd. It sounds silly, but that's the reality. If they had forced people to learn & use Lisp instead of C, the world might be a very different place. I personally love them even now when I look back at Clojure code.
Clojurescript is just wonderful. I'm not even sure a Haskell-like language that compiles to JavaScript (Elm, PureScript, GHCJS) with really good tooling can beat it, though I haven't tried. Would be an interesting experiment to do a comparison by writing the same app in all the languages.
Thanks for bringing this up! I will definitely add a section for explaining the benefits for Scala and Clojure devs. I shipped a non-trivial Clojure web service to production that was handling 1M/requests a day. The experience is what made me finally understand that the JVM is wonderful platform, and what prompted me to work on Eta, given that Frege was insufficient for what I wanted (not supporting a lot of useful GHC extensions). Clojure was wonderful in the fact that I could become as concise as I wanted via EDSLs, and the immutability by default + concurrency primitive were a joy. The lack a type system (please don't mention core.typed) and compile-time errors at runtime were really a pain. I'm sure you can ameliorate that with libraries like prismatic/schema (which I did) and strong test discipline, but it's great when the compiler just takes care of all of that for you. Once you really "get" Haskell-like languages, you miss the benefits no matter what language you try. As for Scala, I haven't built anything significant and I wouldn't want to for some of the examples I've seen. It's too verbose for a typed functional language.
I think it might interest you that Haskell-like languages are one of the best languages for programming EDSLs after Lisp-like languages. If I recall correctly, Standard Chartered uses an EDSL written in Haskell that's maintained by ~10 Haskell programmers and the remaining ~90 people program inside of this EDSL for specifying new rules. Similar case for Facebook and their spam filter rules.
You would be correct if we branded it as "the" powerful language, but we used "a" meaning it's one of many for you, the programmer to chose. I have practically found Haskell-like languages to deliver lots of value in business settings and I want to bring those advantages to everyone who would like to take advantage of it, reducing the risk of adoption as much as possible. No user ever cared about the programming paradigm, but I think they would be happy if bugs were fixed faster (or not present in the first place) or if new features were added without breaking existing features.
The benchmarks I've run are extremely promising, and Eta is sometimes competitive to GHC after warmup. GHC's aggressive optimisations with -O2 + Oracle JVM's JIT seem to be a very powerful combination. I have avoided publishing the results because I still need to spend more time looking at the numbers and understand why was so fast in certain cases (check up on any mistakes I've made). I'd rather take the time to report proper benchmarks rather than hype unverified results.
How Eta's going to differ from the standard is not clear for me either. It's dependent on a lot of factors, such as how GHC decides to evolve and how that affects the usability of the language. The whole point of the name change was to have the choice of not accepting the new features if we felt they weren't ready yet for wide consumption. GHC is a playground for PL research, and SPJ has made that clear on many accounts. It's great for research, but scary for industry adopters. We are focused on industry more than research.
2048 was just convenient. It just so happens that there was an existing Haskell project that used the native GLTK library. I just swapped that out with JavaFX and it worked. If I were to write a book on Eta, I would certainly use a simpler game! I personally learned to code as a child by playing with examples and developing a game, so I can bet your kids are going to grasp programming fast. The human brain learns naturally from examples as opposed to theory.
It was actually not familiarity. We specifically asked people "Which code sample looks readable to you?" People just love concise code. Less cognitive burden.
Check out the FAQ: http://eta-lang.org/docs/html/faq.html. For the record, I love Haskell as a language and even after solving the tooling and documentation problems, it doesn't solve the integration problem. The JVM is widely used and being on top of it makes it easy to integrate into existing systems. You can certainly reuse code between Eta and Haskell given the number of extensions that are in common.
I agree that it's not a good implementation, as I said it's for illustrative purposes. You also don't implement the "Hello World!" program ever in real life, yet every programming language intro starts with that. Relative to that, a sorting algorithm is a lot more instructive. I think if I changed the name of 'quicksort' to 'sortUniqueList' that would clear things up.
This is exactly the direction we're going. I'm a big fan of extensible records/variants. We'll be supporting the GHC 8 extensions that are orthogonal to the type system refactoring like Strict, StrictData, etc. pretty much everything other than TypeInType.
No, you're right. I just don't want to swap out the frontends right now (again, stability). I'll definitely be cherry picking bug fixes and non-pervasive changes once I get a solid test/benchmark suite setup.
You can, see https://github.com/rahulmutt/eta-2048. The whole point of that example was to demonstrate that you can build nontrivial things with Eta right now. Just have to deal with Java FFI boilerplate which requires some patience without any IDE support.
"Relatively easy to understand even if you don't know the language" <- We have empirically verified this by showing code samples of quicksort side-by-side in Java, Scala, Clojure, and Eta to ~100 programmers who had no experience with functional programming at an exhibition. Eta won, followed closely by Scala (people just love their curly braces!). One person liked Clojure because of "it looked like English" and no one liked Java. For this reason, we have posted it on the landing page. We have made no claims that it's the most performant nor that it's the fully correct quicksort (accounting for uniques) - the whole point was to highlight the expressiveness.
GHC 8 will take some time. The current position is to prioritize those new extensions which start creeping up in Hackage libraries. There were significant changes to the codebase in 8 and I want to wait until it's stabilized. Eventually, yes.
Eta in fact only deals with STG code -> Java bytecode transformation. I agree that the intermediate transformations are brilliant, so I am very careful about playing around with the frontend bit of the GHC codebase. Eta currently implements almost all of GHC's primitive operations faithfully. I have taken extreme care in preserving semantics. In some obscure cases though, I just gave up since there are no platform-independent ways of implementing certain things (like vectorised instructions).
Don't worry. Solving the records problem is a high priority item for Eta. We might solve it in a different way than GHC 8, so that's where the 'dialect' part comes in.
We maintain quite a bit of compatibility, which is why we have access to the wonderful, but dependency-heavy lens library. See the Eta Playground for an example.