Getters, setters fixed? Check. Functional features? Check. Most crappy OO features fixed? Check. Trendy package system inspired by npm/apt-get/gems? Check. Healthy community with libraries replacing frameworks? Check.

I'd recommend checking it out if you haven't already.

Unfortunately the CLR doesn't run on any useful platforms.

Now this may be largely a culture thing, with Java programmers creating more cross-platform software and avoiding platform dependent libs just by default, or it may be a technology thing, but to the end user it doesn't really matter.

And this is coming from a linux veteran who wrote a C# web app and hosted it in production on Linux for a few months and then had to re-write it in .NET MVC hosted on IIS. I hate Windows servers. Every time I have to RDP into them to change some configs instead of just vi'ing files in /etc I want to shoot myself.

Ugh, maybe you should try out at least one of the several options for remotely managing IIS before you shoot (or embarrass) yourself?

Not to mention the difference of opinions you get when you search for IIS tuning info/documentation. Half the stuff is only valid for older versions of IIS and there doesn't seem to be a lot of good info on the latest version when it comes to tuning.

http://mono-project.com/What_is_Mono

(hint: search for the word "subset" on that page)

The problem with the framework is that we run into a steep hill when we must diverge off the path. A good framework gives a great story. Unit tests, integration tests, consistent layers, convenient and powerful ways to access the database without writing a giant SQL generator (if x return "and b.id = c.id" else return "b.name = "%" + name + "%")...

But then, you hit the use case that the framework didn't consider. And suddenly, you either need to extend the framework (never pleasant) or go outside the framework for one portion, which means building all of the tools from the ground up.

Or, more often, ignore testing, hack in the best way you know how, and hope nothing breaks.

The library approach means that you have to build the integration pieces yourself. This is painful, but it means that when you reach a new use case, it isn't as large a jump to keep going.

Each has tradeoffs. There are times when each is superior. Someone like Bob Martin would suggest that you build your system independent of frameworks and treat the web as a client/compatibility layer, and that you build your system of small composable parts so that the framework/library question is a minor one. (This has its own tradeoff with an abhorrent amount of plumbing code that comes along.)

It all comes back to the problem at hand and how we judge the tradeoffs, like most engineering problems.

I don't know what it is about the web, but it's as if we decided all of software architecture didn't mean anything and threw it out. My theory: it's harder to feel coupling in a dynamic language, thus it's just an academic concern!

It isn't that we've decided that software architecture meant nothing; rather, we settled on one architecture that is Good Enough. The View/Controller/Domain paradigm of Rails works for many projects.

Aside: "good enough" seems to summarize the web as a whole. This is both discouraging and a fact of life.

A lot of the 'glamour' in the Bay Area is around web apps that 20-somethings use. As a consequence a lot of the headlines and centers of discussion are going to be around languages, platforms and paradigms that reflect that. And, these days, that would be dynamically typed languages, frameworks or framework-like 'libraries' and fad-following (which is where the "rock-star-ninja" meme comes from). I just try to filter the noise as best I can to glean the useful and interesting bits of articles and comments I read.

This sets up a kind of feedback loop: there is an abundant supply of "cheap" labor who can use these languages, which companies love, and so they create more jobs for this labor market to fill, which means more people want to fill it (since there are jobs there).

Edit: 1) I would disagree that python is a "lousy" language; 2) To give some perspective regarding where I come from, the vast majority of my experience is with statically typed languages like C, C++ and Java; I prefer them and in my experience they are at least as easy to develop with as any of the dynamic languages that are popular.

Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).

There is very little in terms of "provability" that either C++ or its types give you. Proving anything really interesting (for example, the absence of race conditions in concurrent code) still seems like pretty much an arduous process in languages not explicitly designed for such things.

Compared to Python or Ruby, you're pretty much relying entirely on culture and good habits to ensure the proper rules of encapsulation. Any code may modify the private members of your objects. (Granted, C++ has "mutable", Java has the whole "Reflection" loophole as well. But you can search for those edge cases rather easily).

That didn't seem very comprehensible to me, but if you're claiming that in Ruby, you can modify member variables of someone's objects, well, you can't, unless you use reflection as well (not only that, but the access to member variables is object-based, rather than class-based, so you can't access the member variables of an object from any other object, even if they are of the same class, unlike in C++ - so much for the "objects communicate by passing messages" in C++!). More to the point, in C++, you can always cast a pointer into something that makes the raw data accessible. There's enough stuff in C++ for you to blow your whole leg off instead of just shooting yourself into the foot.

In C++, you may not be able to prove "the lack of race conditions", but you can prove things like "I'm the only one who is holding onto this mutex right now" thanks to stuff like unique_ptr... which tracks that stuff. These primitive proofs are performed at compiletime, and have little-to-no effect on runtime as well.

Stronger languages with stronger type-systems (ie: Haskell) can prove / disprove which code has side-effects... because you've explicitly passed the Monad around. (Note: Code without side-effects is guaranteed to not have race conditions).

So yes, there are important things you can prove using the type-system. More importantly, it is the compiler's job to automatically conduct these proofs every compile cycle.

Seems to me that's a chip on your shoulder; not mine.

I'll freely admit that it peeves me to no end when people make value judgments based on what programming languages people do and don't like and use, on both sides of the static/dynamic divide, so maybe I do have that chip on my shoulder.

Try building a large C# projects with running unit-tests, integration-tests, packaging, code-coverage, code style baked into it, and a bunch of other plugins for your build systems without pulling your hair.

Your DateTime library ain't there yet sir so you're pretty much at the same situation with Java (although both ecosystems have NODA/JODA lib).

C# is just Java with 10% syntax improvement and -30% to -40% productivity lost when it comes to everything else.

The .net ecosystem isn't as evolved as Java, for sure. But I don't think maven is a good implementation of a dependency management system either, nor is it particularly good as a build system.

Say anything about Maven but the recent discussion about embedding Bundler to Gem is just one step closer to be like Maven (now if they merged Rake+Gem+Bundler then Maven is). Even if Maven is not "good enough", .NET is thousand miles behind Java when it comes to dependency management and build system.

Google-Guava, as ugly as the syntax is, is good enough for most of us. Java 8 is around the corner so meh.

Why are Java developers always like 5 years behind on C# improvements?

And build systems are something g you set up one afternoon, why are you so fixated on a tiny part of the programming process?

... And C# devs always borrow patterns and best practices from the Java ecosystem, so I think it's you guys who are always 5 years behind us.

... If you're using MSBuild or Nant and can set up an adequate build system in one afternoon, either your project is super simple crud, or you're not using enough tools to ensure proper engineering/verification, or you're the top 5-10% people who can bent .net build tools according to your needs, or you're exaggerating.

If you think that we shouldn't sweat over build scripts then that seems to be a hint that you have not dealt with large projects.

There is nothing 'monadic' about select. SelectMany yes, but not Select. That's equivalent to map in other languages.

The weakening of the concept is inevitable now that everyone has been taught to not be afraid of it even if they have no clue why it exists.

With that said, I disagree that having to mark the end of a statement with a semi-colon is obsolete syntax. Statements and lines should not have to be 1-to-1, even if most code is written as such.

Reactive Extensions are very nice. I'm experimenting with the Java port, RxJava. Actually I use RxScala, the Scala interface. However, for me they are of limited utility for my current usecase, because in comparison with Iteratees (a concept coming from Haskell, borrowed by Scala and championed in Play2), Rx Observables are very error prone to issues such as backpressure, whereas Iteratees are safe by design. So on one hand, Iteratees are better for handling streams, such as http requests/responses, handling big files and so on, while Rx Observables are better for publishing events to event listeners. I can see myself using Observables though. Erik Meijer is now contributing to RxJava btw.

The C# continuations are delimited continuations, or partial continuations. They are pretty cool, not arguing about it. But in Scala, the API for the standard Future, is much, much nicer than the API of Tasks in C#, therefore working with Futures directly is more comfortable. Plus, Scala's philosophy is to empower the developer to build on the same "magic" that the compiler uses, therefore instead of introducing LINQ or Async, Scala 2.10 introduced Macros. As a result, LINQ and Async are now possible as libraries. Here's DB LINQ (see the direct embedding tab): http://slick.typesafe.com/ ; and here's Async, which will be included in the standard library, but it's just a library based on macros: https://github.com/scala/async

On Value Types, there's nothing ground-breaking about it. On one hand they are great and it would have been cool to have value types on the JVM. There are proposals to include value types that people experiment with in OpenJDK. On the other hand, the JVM being more restrictive about managing memory, gave birth to the most advanced garbage collectors in mainstream usage. C#/CLR is great when a low overhead is required, such as on mobile devices, but in a server-side context no GC-enabled language can beat the JVM.

On syntax, it's true that Java is an abomination. However this gave birth to multiple languages that are flourishing and you can't say the same thing about .NET ... Scala, Clojure, JRuby, Jython, Groovy and Rhino are examples with flourishing communities and ecosystems. Similar efforts have been happening for the CLR, but they never made it or are moribund, except maybe F#.

I did want to use C# several times, as I view it as a mixed-bag language, as in a language with comfortable high-level features that also has some low-level stuff, which is pretty cool on top of resource constrained devices. And I definitely prefer C# over Java (thank God for Scala and Clojure). Unfortunately the platforms I build upon are mostly Unix and I prefer to build on top of open-source as I'm the kind of developer that likes being in control. And in spite of the best efforts of those people from Xamarin, or the recent moves from Microsoft to open-source some stuff, .NET doesn't really have an open-source community and it's very Windows/Microsoft oriented.

It's a pity because it could have been much more than it currently is. And maybe it will, as I'm seeing some encouraging signs, like Microsoft partnering with Xamarin.

We tend to treat languages like they are football teams. We really need to learn from each other and build on top of each other ideas. Cross-pollination is healthy. Conservatism is not. If we jumped between platforms more often, we wouldn't be separate communities.

For real? Do you have any reading I can do on this? It sounds... interesting

Preparing dev workspace means to include csproj in your repo which may contain hardcoded paths. Is that portable across to Mono? In Java, all you need is a Maven pom.xml file and the code. Any modern IDE can read pom.xml file and prepare the project consistently cross platforms.

CI server is the easy part.

[1] http://www.scala-lang.org/old/node/10299

You know, Java can be many things, but you can't beat its ecosystem ;-)

[1] http://www.robovm.org/

[2] http://www.codenameone.com/

[3] http://xmlvm.org/overview/

[4] http://oss.readytalk.com/avian/

[5] http://code.google.com/p/j2objc/

In any case, JVM runs on more platforms than any others.

Relevant: http://www.mono-project.com/Companies_Using_Mono https://servicestack.net/features http://stackoverflow.com/questions/18450/is-mono-ready-for-p...

No, there aren't. And MonoDevelop has gotten better, Xamarin is doing a good job, but it's still a far cry from IntelliJ IDEA. If you want to target Mono, spare yourself the effort and just use Visual Studio.

IntelliJ still seems to be a wishlist item. Surprised there is nothing considering how many other great C# tools JetBrains produce.

Basically, YMMV.

To develop, sure, it is feasible (I did this, but for a simple webservice), but it may be missing something essential to you.

So the bits and pieces are certainly there, and even the JCP does good work sometimes (JAX-RS) that becomes good standard APIs with many different implementations.

[1]: http://dropwizard.codahale.com/getting-started/

While I really like JAX-RS, the reference impl Jersey uses HK2 for dependency injection, which makes it odd to integrate into a Guice application (in fact Guice support is still lacking with Jersey 2.x).

[1]: http://www.ninjaframework.org

I think of Dropwizard much like express for node, and most of the "cool kids" in the node community think that that's just too much for a single library.

I like Dropwizard, don't get me wrong, but it isn't quite a micro-framework by other standards.

I do, however, think that standard JSR APIs are still really nice to have, if they're good.

I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.

You mean "no unsigned types (even though the language is essentially machine-level when it comes to integers), no compact memory layouts for aggregate data, no useful function values without jumping through hoops etc." is an approach that leads to good languages?

That's not my opinion, but just what I understood his comment to be about (personally I prefer the npm approach any day over Maven).

The issue with these other frameworks/languages is that even when modern frameworks are used there are usually some Java backend services (or another "powerful-outside-of-the-web-also" language) if the app does anything substantially complex. A ton of the hip web tech is basically for building front-end and cobbling together relatively inefficient backends.

I was an RoR guy myself but moved to Java & I see the correct hipster tech here but just lacking unanimity. I bet if the RoR community decided "Clojure hell yea" or "Scala hell yea" and contributed lots of plug-ins to those ecosystems, they would generally have similar development times with a lot of performance gain for free. I'm thinking about trying Play framework on Heroku just to see what the monthly bills & New Relic readouts look like in comparison.

[1]: https://groups.google.com/forum/#!searchin/play-framework/pl...

For example the portion about "Asynchronicity" is a brief paraphrase like "Play is good in Rails its awful or doesn't exist". Performance isn't even mentioned really.

I find that with Rails apps a lot of development effort is put toward optimizing for scaling rather than complex logic, where Play could potentially be stronger. A lot of the comparisons seem to be posted by RoR devs who are looking at Play as a potential new framework for a CRUD app with a very fancy UI. In my mind that's not what it is... I read a few articles about corps using it for big distributed apps with a lot of eventing.

So I guess it's a bit of my personal taste but I just don't see "Rails has HAML", for example, as a reason why it's better given that HAML would be pretty trivial to implement in Play if the community wanted it. Full-featured CRUD frameworks vs. enterprise-ready app frameworks are very different ideals. They each have their place but if one tech were to emerge as really superior I think it could easily integrate all the bells & whistles that rapid CRUD devs like.

Do you know of any frameworks that are good for that (but let you easily reach down for complex logic, e.g. where data processing or AI is needed)?

Every project I do needs some form of CRUD, and making it work AND be pleasing to interact with takes a lot of time. I don't mind the language, just someone, somewhere must have solved this already...

The advantage of JVM in my opinion is that a lot of their toolchains have this approach in mind and simplify integration of the stack. Java can be used for a lot, when you add in other JVM languages that is a lot of possibility. Then again, if you design proper web services you can make almost any front/back-end interact, the trick is just in minimizing that amount of impedance.

I'm sure there are tons of crummy Java devs out there but there are also some brilliant ones delivering "corporate solutions" (fancy term for myriad proprietary frameworks) or just coding for Google. And there are talented/talentless in almost every community.

Why would you assume I'm snubbing my nose at open source when I'm advocating for Clojure? The JVM is a sick platform for web dev and it gives you the opportunity to use a variety of languages and open source tools in a single high-performance project.

I don't know if this is personally what you're getting at but it seems like a lot of the attraction to the scripting languages is sorta convention over configuration rather than some major shift in the web dev paradigm -- the same design patterns are possible in every language for the most part.

My point was merely that judging a single implementation is a straw-man approach. You don't know how motivated or talented those devs were in the first place.

EDIT: well, the comment was deleted so I guess the writer realized my position maybe(?). Well, Let the record show that open source exists all over the JVM... I don't know why it has the rep of looking down upon open source movements...

Also, Java is extremely popular, and some of its most painful points have been addressed in Java 8. Even an arguably better language (regardless of its name) will not easily replace Java. Hey, look across the browser at JavaScript. There are arguably better languages there; are they replacing JavaScript?

If you look just at GitHub – which is greatly skewed towards new languages – you see that all other JVM languages put together make about 10% of the JVM ecosystem, with Java being the 90%. Outside of GitHub, in "the real world", the situation is even more strongly in favor of Java. I don't know if this is going to change much in the next few years.

I don't mean that you shouldn't use an alternative JVM language if it makes your work better, and there are many viable and very useful alternate JVM languages – personally, I like Clojure and Kotlin – but you can't just "replace" Java so easily. I think efforts to reform the Java ecosystem are more likely to succeed – at least in the short term – than efforts that require switching to a different JVM language.

I think it possible (though far from inevitable) that another JVM language will achieve dominance on the JVM, and it is very possible that Java will fall below the 60% or even 50% on the JVM (with the rest being taken by several, though not one dominant, languages). But this is still some years in the future.

It IS an improvement on/replacement for Java in most situations.

In short, no one (who knows the software development landscape well, that is) can say Scala (or some other JVM languages) makes Java redundant.

Maybe when some of these new fancy tools like Graal become more polished and ready the dream that was scala can start to happen vs reality you get when using it. I'd be happy to see that happen.

Frankly, I'd rather just go to Erlang and skip all the compromises needed to stay with the JVM if I want that kind of language.

I mean the most hated implicits are implicit conversions and they basically exist for Java compatibility.¹

So on the one side you have terrible stuff hard-coded into the language (Java, C#) which you will never get rid of and on the other side you have a solution as a library which you just can de-import if you don't want to suffer from e. g. magic anything-to-String conversions any longer (I certainly won't).

That's a huge plus in my book.

¹ The two other main use cases, type classes and extension methods, seem to be hugely popular and I haven't seen any criticism concerning them.

I'd rather work with a language that _i_ don't fully understand (modersky seems to provide me with an infinite supply of intellecutal challenges) than with a language that gives me reason to doubt that it is fully understood by the people who made it.

It's really just one of the people who made it. Groovy has a non-technical project manager, and most of us who've programmed in corporate IT shops know how that goes.

A case in point: traits were announced for Groovy 2.2 ( http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td... ) in June (2013). A rather lengthy discussion (55 messages) followed planning them, but the traits never came. The very last message asked what happened to them but the project manager never replied.

Another case: tech lead Jochen Theodorou began a discussion about changes to the meta-object protocol (MOP) for Groovy 3 ( http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html ) in June last year (2012), kicking off a 91 message discussion. But the project manager canceled the new MOP, diverting Jochen into other work.

Again: Groovy creator James Strachan's very last Groovy mailing list posting ( http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... ) to that project manager who replaced him just before he left the Groovy development team in Dec 2005:

"The MOP and introspection APIs do NOT solve the horribly broken name resolution rules in the current RI of Groovy [...] I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole [...] It just feels totally wrong to break Closures across the entire language just because of some use cases for Markup."

The project manager's behavior is typical of non-technical people working in Software Development everywhere. E.g. on 29 August this year, Groovy's 10th birthday, someone added the project manager's name to Strachan's as a "co-developer" of Groovy on its Wikipedia page ( http://en.wikipedia.org/w/index.php?title=Groovy_%28programm... ), giving him 3 titles (developer, project manager, and spec lead). I really had to undo it. Because the Spec was changed to dormant in April 2012 ( https://www.jcp.org/en/jsr/detail?id=241 ) after being inactive for 8 years, I removed Laforge's "spec lead" title also. I also added the 3 technical people who are listed in Groovy's Codehaus repository as "despots" to give to Wikipedia page more truth ( http://en.wikipedia.org/wiki/Groovy_(programming_language) ).

It's a pity how Groovy stagnated over the years, and maybe it's just a very public example of why "business people" shouldn't be allowed anywhere near programming language design and development.

I've heard many good things about Gradle's functionality, but not so many about Groovy. Only yesterday ( https://news.ycombinator.com/item?id=6884355 ) I asked if Gradle will ever expose an API so developers can use the same language for the build scripts as they do for the projects they're building, i.e. Groovy with Gradle for Groovy projects, and Scala with Gradle for Scala projects?

LOL, I'm trying to imagine anything else in life being run like this. For instance, you go to the "car package manager" and are told that all parts must be less than 2kg and that you need to choose which ones you need...

It would be like saying that all SKUs need to be comprised of other SKUs and less than 2kg of screws, nuts, bolts and custom components.

In your analogy the Spring might be an entire engine, spark plugs and all, built as a single unit. Want to use your own spark plugs? Tough luck. You get the whole engine or none at all, or you could just build your own from scratch.

Then why not just use Rails for Java, i.e. JRuby ?