I've used xtend last year, before I switched to Scala.
Eclipse integration is better with Scala (autocompletion among others), and Scala has more to offer.
Biggest pain point: stack traces point to the Java translations, not to xtend's source code. That made me switch to Scala.
Interestingly, I've made the opposite switch. And I can't even compare the difference between the slow, unreliable ScalaIDE, with the the hardly understandable compiler errors, and the much quicker, leaner Xtend IDE, where you can see, what's the compiled code, which I really enjoy.
I've been using IntelliJ IDEA for Scala for about a year. Best IDE ever.
With Scala IDE I've only had painful experiences, plus I hate Eclipse with a passion - but folks keep telling me that it got better. Well, I don't really care as long as IntelliJ IDEA exists.
They are also extremely fast and responsive in fixing bugs of any kind. I personally couldn't be happier and other communities can only dream about such IDE support. Of course, if you compare IDEA's Java support with the Scala plugin, it's worse, but IDEA works better for Scala than Eclipse does for Java, like seriously ;-)
Good for you! My experiences wasn't that bright. Even configuring IDEA was a nightmare, especially because none of the Ivy plugin worked with the Scala stuff. And there were a couple of annoying thing, with which I can't live it. Probably they've improved since then
Autocompletion in the Xtend editor is quite excellent, you might want to try a recent version. The last time I tried the Scala IDE (during the first Coursera lecture), Scala's autocompletion suggested may invalid proposals. It felt more like the editor was guessing about types than actually doing proper type analysis. If you happen to have a Java stack trace from Xtend code and click on a stack frame, Eclipse will open the Xtend file and highlight the proper line in your Xtend code.
Could you tell me something about the difference between Xtend and Groovy. To me, Xtend looks like Groovy with a stricter syntax, and instead of directly translating to Java byte code, it gets transalted to Java source first.
Xtend is statically typed but your Xtend code can be as lean and concise as your groovy code because the Xtend compiler can infer the correct types for you.
Because Xtend is statically typed, the Eclipse Xtend editor has quite an excellent autocomplete. For your cursors's location it can propose you a list of all valid keyword, methods names, filed names, local variable names, Class names, etc.
And by excellent I mean: Autocompletion will not forget things and it won't show invalid proposals. No guessing!
For Groovy this just isn't possible because it is mostly unknown to the editor which methods and fields an object has. It's only known at runtime.
It's true in general, but in most specific cases it is possible to statically analyse dynamic languages to the point of providing meaningful auto-completion. For example in Python-land there is Jedi (http://jedi.jedidjah.ch/en/latest/), and also commercial Komodo IDE and PyCharm. This is done through static analysis, so that no code is ever run for auto-completion.
So, while it's impossible in general case, it's perfectly possible to create useful auto-completion for dynamic languages. There are such tools for Python, JS and probably others as well.
"Modernized Java", it's basically a slightly uglier C#.
Not that I'd argue C# isn't modern, it's in fact one of the most 'modern' languages I can imagine at the moment, but it's kind of wry that C# did such a good job of keeping current where Java lagged so terribly behind.
JVM doesn't even have value types or generics making it practically unusable in some scenarios. While JVM implementations might be better quality for specific problem domains I'd say CIL is probably better than JVM.
Not to mention CIL was designed to be a Common Intermediate Language from start so language interop is nicer (generics are a nice example)
> JVM doesn't even have value types or generics making it practically unusable in some scenarios
Like what?
The CLR is unusable for dynamic languages for example. I was using Ruby back in the day, when both IronRuby and JRuby were active at the same time, with IronRuby/IronPython being developed by Microsoft ... there was no comparison to speak of, JRuby was beating the pants out of IronRuby in terms of everything.
The JVM can inline virtual method calls, the JVM can do escape analysis for getting rid of unneeded locks or to allocate short-term objects on the stack, the JVM can de-optimize previous optimizations in case assumptions have changed or in case it doesn't see a performance improvement, the JVM has a GC that can cope with the garbage produced by dynamic or FP languages. The JVM has invokeDynamic.
As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing) and many others, including a Haskell port. All of them with thriving communities.
> Not to mention CIL was designed to be a Common Intermediate Language from start
That was just marketing. The JVM's bytecode is actually better for other languages. At the very least, the debugging symbols are part of that bytecode and the format is documented.
>As a result we now have - JRuby, Scala, Clojure, Groovy, Jython, Kotlin, Rhino, Nashorn (as a new Java 8 thing).
Speaking of those, if anyone wants to try those languages on the jvm for web app development check out HiveMind (crudzilla.com)...I am the developer, it is the easiest platform so far for using JSR-223 to build web apps.
Actually I've heard that CIL generics make language interop harder, because you're essentially forced to have a generics model that corresponds exactly to C#'s. This was a major factor in abandoning the .net version of Scala. (Whereas on the JVM, type erasure means that Scala is free to apply its own generics model rather than having to match Java's)
It's not like Scala has generics interop with Java, you can't use advanced Scala generics from Java so I don't see your point. I'm sure they could have erased the extra stuff on CIL and support a basic subset that's visible to .NET languages.
Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
> It's not like Scala has generics interop with Java
Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode.
> you can't use advanced Scala generics from Java
I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it?
> I'm sure they could have erased the extra stuff on CIL
Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics.
As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all).
> Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.
Yet the CLR model is apparently not flexible enough to implement type classes, which Scala can handle in a very flexible way. Here's Microsoft's rejection claiming that the current CLR can't practically support type classes: https://visualstudio.uservoice.com/forums/121579-visual-stud...
Apparently baking the generics into the generated bytecode has downsides in flexibility.
I had always thought that the CLR was considerably ahead of the JVM, though admittedly only anecdotally. What is in the JVM that is not in the CLR that makes the JVM further ahead, so to speak.
Working with the JVM, there is definitively more cross-platform support (I know there's Mono for CLR but it's not the same support Oracle's JDK gets), GC has a ton of heavy hitters investing time (from IBM JRockit acquisition to collaborations with Azul's Zing) and while I haven't seen first-hand CLR's optimization the JIT optimizations are pretty impressive.
For me, it's about the ecosystem. I do a fair bit of work on the CLR and JVM.
The JVM has the following advantages: open source, cross platform, free tooling[1], incredibly more mature 3rd party libraries, zero OS cost to deploy, architectures ready to roll out of the box.
A lot of the Java stuff I do is literally integrating some off the shelf bits that work 100% reliably first time and it's done. Compare to C# where I end up having to do a lot of leg work and navigating immature, abandoned or just broken open source projects.
[1] By the time I've bought VS Pro 2013 with MSDN, ANTS profiler, NCover, VisualSVN, I'm down a pile of cash.
Async, lambdas, extension methods, linq and "the dynamic type" (late binding). Yes, many similar but older implementations for these exist, I know, but in C# they work in harmony - and that's a bit hard to explain for me =)
And more syntactic sugar than is good for your teeth :) (I'd also want to add generics to the list, but it's over 10 years old, still not many languages that implement it so well)
Many enterprise shops won't look too far beyond plain Java. Xtend is not as far beyond plain Java as Scala is. One of its selling points is that you can just generate plain Java from Xtend into your normal source folders.
Yes, yes, I know enterprise CTOs need a good slapping, but at least this gives their down-trodden devs an option.
As such, I think it will come under threat from Java 8 rather than Scala.
You can do that in combination with IntelliJ IDEA for example, which has awesome support for both Scala and Android. Google's new Android Studio is actually the same as IntelliJ Android plugin that they distribute as part of their open-source distribution. It's also the best IDE ever.
Why's that? If you're worried about generating lots of extra inner classes, isn't that still a problem with Xtend? Other than that, what's the problem with using Scala on Android?
You don't need to mess with a type system unless you're doing some fairly advanced stuff. And then messing with type system starts to be better than messing with reflection, anyway. I'm a dynamic-languages kind of guy, but Scala type system is one of its advantages. Scala type system is comparable with OCaml and Haskell and that's really something you can't say about Java.
Oh, how many "next Java" options we have now... Kotlin, Ceylon, Gosu, Xtend, Java 8 :) (Scala not mentioned as I refuse to call it "the next Java", it's a new player)
I've used Xtend many times over the last few years. In fact, I'm using it right now at my "real" job for an internal project. I'm mostly a Clojure guy who still has to do a lot of Java work to pay the bills - when I can't use Clojure on a project, Xtend is a breath of fresh air.
The current form of Xtend has been around for a few years now, and has steadily improved. Its origins go back many years, to the OpenArchitectureWare project where its predecessor (called Xpand) was used as a templating and model transformation language for the framework. Since oaw moved to the Eclipse foundation (5-6 years ago?), most of the tools have been dropped, reworked, or merged in with other Eclipse projects.
Out of all this reworking for the new generation of Xtext came Xbase, which is an expression language that you can just drop into your DSL and have pretty much the entire Java language available (type system, expressions, scoping, etc.). If you're doing serious modeling/DSL work, this is about as good as it gets without going to something like MPS (which is awesome, but has its own set of limitations). Xtend is essentially this Xbase language in stand-alone form, with a few other goodies. There is also another project called Xcore which lets you create EMF models in plain text, mixing behavior along with structure, and it uses Xtend/Xbase as well. This is one of the reasons why I'm not too worried about Xtend becoming "abandonware" or anything like that - its main components are pretty essential to some key projects in the Eclipse ecosystem.
So why wouldn't you just use (Scala, Groovy, etc.)? Well for one thing, I can (and have) bring Java developers up to speed on Xtend in about an hour (less if they know anything about functional programming). You can see some benefits in more concise code right away, and it only takes a couple days to get productive with it. No one can do that in Scala or Clojure. If you're looking for a strategic platform to build your next JVM architecture on - well, that's not really Xtend's place, you're looking for Scala or Clojure (hint - the latter). But there are a lot of projects where Xtend is a very nice fit, and as a bonus, I've found that developers who learn Xtend first have a much easier time learning a more "serious" language like Scala or Clojure later.
It is a me too language from Eclipse foundation without any clear roadmap why anyone in the industry would care to use it given the more mature JVM languages, specially given its dependency to Eclipse and generation of Java code instead of bytecode.
Xtext, the Eclipse/JVM language development toolkit behind Xtend, is in many ways more interesting than Xtend itself. In fact (I may be wrong) but Xtend was really done as an Xtext example/test/advertisement.
I have used Xtend a little (not in production) and it was interesting when first introduced. I suspect Java 8 will make it redundant.
My feelings as well. I just looked into it as a possible language for Android development given the stagnation on Java compliance on the platform, but Kotlin looks much better suited for it given Google's investment into InteliJ.
MPS from jet-brains offers another good option something called baseLanguage with very good DSL equivalents for a lot of use-cases combined with one more called SModel language.But its not parser based one like xtend is , its AST based projection editing and manipulation platform.I've been learning it for sometime.
What I would hope is that these features get rolled back into Java. Xtend could be a testing ground that shows how something would work, similar to the way browsers have their own proprietary implementations of an idea that then serve as examples to the W3C.
I find it sad that some view JVM languages which aren't Java as a testing ground for features which could be added to Java. Other JVM languages are worthy of usage independent of the Java language. Not everything can be back-ported to Java and keep the language backward compatible.
coming from java, xtend is probably the best choice right now (also compared to java8) because you are up and running in few hours. really!
and the development time will decrease significantly. You can create full projects in a fraction of time.
Active annotations are also very useful to generate common boring code (Logging, patterns, ...) also from configuration or HTML files, or to generate files like javascript to call your backend service.
the only drawback is that it only works in eclipse. Eclipse has full support, meaning that debugging, refactoring, click from stacktrace and so on are available and work perfectly.
just try it for 30 minutes, you'll not come back!
This all looks OK to me but my first worry would be ease of debugging. I eyeballed the doc but couldn't see anything specific to debugging. Anyone has some experience they could share?
You can debug Xtend code using the Eclipse Java debugger and debug Xtend code just like you would usually debug Java.
During debugging, you can select for every stack frame if you want to see the Java code or the Xtend code. This makes sense since Xtend code gets compiled to Java code which then gets compiled to byte code.
They surely need to find a solution for proper debugging. Nobody likes mental gymnastics needed when debug stack traces to a language other than the language you write the s/w in.
Xtend isn't supposed to replace Java. It enhances it. That's why Xtend doesn't compile to byte code but to Java code.
If you do imperative programing in Xtend, there will be exactly one Java method for each Xtend method. I.e. the "Xtend stack trace" (if it would exist) is exactly the same as the Java stack trace.
If you do a more function style of programming and use lambda expressions, each lambda will be a anonymous class in Java 7 or older. So you'll see them in your stack trace. But I guess that you would also see them in Java 8.
Because many languages were designed with only the compiler in mind, but IDEs have requirements regarding language design, too…
Example 1: text-based preprocessors such as the ones you find in C or C++ are a nightmare for IDE developers. They turn static analysis into a game of guessing because your source code can manifest itself into too many variations.
Example 2: SQL: If a user wants to write "SELECT mycolumn FROM mytable;" but he/she has only written "SELECT " and now trigger auto-completion… it can not work, because the IDE has no idea from which table it can list the columns. If the language would have the syntax the other way around "FROM mytable SELECT mycolumn" auto-complete could easily propose the tables first and all the columns from a specific table later.
Nice, liked Lombok!
But why stop there, Scala / Kotlin have everything you have in Lombok + Java 8 (case class in Scala and data class in Kotlin do basically what @Data does, in Scala there are no checked exceptions by default, and both have very good null safety solutions, albeit different approach)
I think that if a company is open to using Java 8 + Lombok, then they should at least try out Scala / Kotlin (or even xTend) for comparison.
If compile times are what worries you, Kotlin seems to be on par with Java compilation times, although I don't think Kotlin is production ready yet. (and it misses some Java 8 / Scala goodies such as parallel collections etc... though I'm sure JetBrains will add it soon...)
Did you have a look at Xtend's Active Annotations?
http://www.eclipse.org/community/eclipse_newsletter/2013/mar...
You can define your own annotation processors without having to understand Java Byte Code. With Xtend, an annotation processor is basically a small Java code generator that can add/remove/modify classes/interfaces/fields/methods. It's quite awesome for automating design patterns, e.g. generating getters/setters, observer pattern, property objects, delegators, etc.
Xtend has been around for a while and I think one of the reasons why it didn't catch on is because it generates Java, which severely limit its performances.
These days, "modernized Java" would probably be Ceylon or Kotlin.
It's finally a syntax that doesn't get into your way when you want to generate stuff.
Think of XSLT. Every time you want to generate a "<" or ">" you need to escape it.
Think of PHP. Every time you want to embed a command you need at least two characters to escape it: <? ?>
Xtend choose «guillemets» because they're concise and very unlikely to occur in the string/text/file your generating. You might want to use UTF-8 or ISO-8859-1 encoding.
The templating engine is one of the parts carried over from the old Xpand project on which Xtend is based. Xpand's sole purpose was as a templating language for writing code generators in MDE projects, and as such they tried to make it easy to generate any kind of code, so they chose a non-ASCII delimiter.
It's really not a problem in practice - type < and then ctrl-space and code completion will fill it in for you. The only real gotcha is that you have to make sure your project is set to use UTF-8 encoding, which unfortunately is not the default setting in Eclipse.
