About PayPal's Node vs Java “fight”(developer-blog.cloudbees.com)
developer-blog.cloudbees.com
About PayPal's Node vs Java “fight”
http://developer-blog.cloudbees.com/2013/12/about-paypal-node-vs-java-fight.html
215 comments
You've basically described C#:
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.
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.
"You've basically described C#"
Unfortunately the CLR doesn't run on any useful platforms.
Unfortunately the CLR doesn't run on any useful platforms.
Like Linux or Mac? http://www.mono-project.com/
The difference is that I can basically count on any arbitrary java/jvm program running on Linux, but even with Mono I don't get that same level of confidence with random c#/clr.
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.
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.
Sure, you can run command line c# apps just fine but the web hosting solutions for c# web apps are terrible compared to IIS + Windows.
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.
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.
> 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?
Ugh, maybe you should try out at least one of the several options for remotely managing IIS before you shoot (or embarrass) yourself?
You still have to dig through 20+ screens of possible configuration values, some configs are in web.config in your app, some are in some other machine.config files, etc. The configuration just seems like a mess compared to your standard linux app with everything nicely organized in /etc/<app>
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.
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.
You need to use the command line configuration tools, it has got a lot better than it used to be (thanks to Azure, I assume). Still nowhere near as consistent/logical as Linux, but it's getting better..
I love the Mono project, and I follow its progress with great hope. But I've tried to use Mono apps on my Mac (Popcorn Hour configuration things) and they flat out wouldn't run. The gui came up and it just hit a brick wall. I tried it on my Linux laptop... it showed a bit more... and then got stuck. I ran upstairs to a windows machine. Finally it worked. So the write once, run anywhere mantra hasn't exactly hit all Mono developers yet. I think C# is one of the best languages I've ever been blessed to use, but Mono still has a ways to go.
Yes. Mono is not C#, it’s only a subset.
Please at least learn what Mono is before spouting this tripe.
http://mono-project.com/What_is_Mono
(hint: search for the word "subset" on that page)
http://mono-project.com/What_is_Mono
(hint: search for the word "subset" on that page)
Mono is not a language. C# is not a platform. Get a clue - it's useful.
The "libraries over frameworks" notion is something I keep noticing in communities that seem to be more engineering-minded than rock-star-ninja-dev-minded. Where do you think this comes from? I think it's a mix of maturity on the part of the community members along with how often the language is used to do things that are harder than CRUD.
In my case, I'm speaking of a reaction to Spring and Struts. I personally use Grails on my recent projects, which is as close to batteries-included as it gets, but I occasionally have problems with square peg round hole problems, and fighting against a framework is more painful than a library.
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.
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.
Do you know of any shops that use Uncle Bob's approach (besides 8th Light, of course)? I don't; I wish I did. I agree that isn't something you'd use every time, but I feel there isn't a whole lot of data out there when people have used it. All I see online are devs whining about the extra work.
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!
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!
I have plans to try it in a side project. I too am skeptical about the rewards of setting up a CRUD system like that.
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.
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.
It won't be great for CRUD. It's really meant for applications that have a bunch of business logic to them...you know, the interesting apps.
Aside: "good enough" seems to summarize the web as a whole. This is both discouraging and a fact of life.
Aside: "good enough" seems to summarize the web as a whole. This is both discouraging and a fact of life.
You can still have an interesting business logic system that is CRUD at its core. A case management system, as an example, is CRUD at its basis but filled with business logic.
I'd say it's exactly about "maturity" not in the emotional sense, but the "breadth and depth of professional experience" sense.
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.
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.
Except that of all the things you've named, dynamically typed languages are hardly "a fad". It's surprising (?), though, that the lousy ones are the most popular ones.
I take a very cynical view of these things, and from that perspective it doesn't surprise me at all, really. My cynical view is that the "lousy" ones are popular because they are easy even for non-technical people to learn well enough to be useful in the majority of business settings.
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.
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.
The commoditization of web devs will occur, it's just a matter of when. Consider it the collateral damage from ever-more-powerful frameworks, a de-emphasis on SOLID-type software architecture, and businesses wanting to pay less for developers.
Couldn't agree more. I'd argue it's already well on its way. It seems there has been a resurgence in companies trying to shoehorn every application into a specific development pipeline within the last several years (specifically, the HTML5/JavaScript in-the-browser solution, rather than a more appropriate native solution). It happens every so often in this industry, but lately it seems to have accelerated.
I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables.
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).
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).
I think its more of the realization that types are actually freaking useful for determining "provability" of a system. C++ perhaps takes it too far with Const, but it allows the compiler to prove that certain functions will not attempt to modify certain variables.
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.
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.
Take for example, proper use of a unique_ptr<lock_guard<std::mutex> > in C++. You can pass around the unique_ptr, and guarantee that you are in "unique ownership" of a particular lock at compile-time.
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.
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.
In Ruby, you can break into any other object with a judicious combination of send() and instance_variable_{set,get}()
[deleted]
Alternate theory: "lousy" is a subjective measure, and those languages are popular because in many other peoples' subjective reality, they are not lousy. Just a theory though, by all means, keep thinking that languages are objectively ranked identically to your subjective ranking and anybody using ones at the bottom are just dumb dumbs who are incapable of using the ones at the top.
I didn't rank any languages. I made an observation that it is easier for non-technical people to pick up dynamically typed languages and be productive enough for use in many business cases than to pick up statically typed ones. That doesn't mean the dynamically typed ones are "easier" or "worse" than statically typed ones. It doesn't mean people who prefer them or learn programming with them are "dumb dumbs," either. There's a reason I put "lousy" in quotes and didn't flat out agree that they were, in fact, "lousy".
Seems to me that's a chip on your shoulder; not mine.
Seems to me that's a chip on your shoulder; not mine.
Hmmm, I re-read your comment and its parent a couple times, and maybe I didn't give proper credence to your sarcasm quotes. I do think that your comment strongly implies agreement with the non-sarcasm-quote-using parent comment, but hey, maybe that's really just my reading of it. Your edit also confusingly says that you don't think the "lousy" languages are really any easier than the static languages you prefer, despite your second paragraph seeming to say the opposite. So maybe I'll just bow out of trying to interpret what you think :)
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.
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.
I first saw this in clojure, and thought it came for the builtin immutability of most types. Meaning you can't have order problems with libraries functions, unlike in the mutable world where a framework will shield you a bit.
Your package system is inspired by Maven, minus a good build system and other functionalities.
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.
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.
C# is Java with perhaps 200% syntax improvement. The things I use most often with e.g. Ruby - monadic collection operations like map, select, etc. - is there in the form of Linq, with select, where, etc. A concise, type-inferred lambda expression goes a long, long way.
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.
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.
I still don't see any C# developers that are 200% more productive than Java developers due to limited infrastructure around the C# ecosystems.
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.
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.
Huh? C#'s had Nuget quite a while ago now.
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?
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 Nuget is always behind Maven.
... 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.
... 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.
[deleted]
>monadic collection operations like map, select, etc
There is nothing 'monadic' about select. SelectMany yes, but not Select. That's equivalent to map in other languages.
There is nothing 'monadic' about select. SelectMany yes, but not Select. That's equivalent to map in other languages.
Sure there is! Monads generate liftM, so if you live in a place so bereft of explicit semantics as to call major parts of your standard library "monadic" without specifying which monadic context to which you refer... Then you may as well drag functor and Applicative along with you.
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.
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.
Any language today that still requires to mark end of line with a semi colon, has in my opinion outdated syntax. Most people put one statement per line, so why is it required and not optional?
just guessing but if all statements are terminated with a ; instead of a newline it allows statements to be split up into multiple lines?
What about the counter case of one statement needing more than one line?
1) Line length is arbitrary, and there is no finite limit
2) You can have an escape sequence for a new line
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.
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.
And some languages don't check types for you before running the code and it's almost 2014 now, can you imagine?
Ruby, Python, even PHP checks the types of values before executing operations on the values.
That's not true, at least with Python. It uses duck typing, there is no type check before execution. It just runs the code you give it, if you try to call a method that doesn't exist (split on a integer), it will just give an error.
Exactly. They check the types. They don't burden the programmer with such tasks.
We build those kind of projects and our team is successful with C#. Perhaps we just know a thing or two about decoupling on all levels. С# comes from the world that brought us Reactive Extensions and TPL. If you call runtime generics, continuations, dynamic typing and value types 10% syntax improvement, then perhaps you should grab a book or two and catch up a bit?
"Runtime generics" (they are called reified generics btw) is one of the things that keeps the CLR from being a multi-language VM like it was advertised, as at the bytecode level they are very hard to work around. That's one of the reasons for why dynamic languages on the CLR never took off and that's why F# has two generics systems in the same language. I'm much happier with the generics type system provided by Scala - it's more flexible, allows for more type safety (so there are far, far less instances in which one needs to do isInstanceOf checks), you also get reification by receiving TypeTags and Scala can also specialize the implementation for primitives if you want it. You get most of the benefits and more, without butchering the runtime. The easiness with which you can generate bytecode on the JVM has been one of the reason for why the JVM has been preferred by language designers.
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.
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.
> that's why F# has two generics systems in the same language.
For real? Do you have any reading I can do on this? It sounds... interesting
For real? Do you have any reading I can do on this? It sounds... interesting
What? We do all those things and have hardly a problem. What ci / build server do you use?
In the past, I had the misfortune to work with MSBuild to setup a fairly large .Net project. This was before NuGet exist. NuGet helped a bit these days but integrating FxCop, FxStyle, auto run NUnit, generate the docs, and running code coverage as part of the build is very painful and a manual process from downloading the proper assemblies up to setting up paths and results. Not to mention packaging the whole things up and possibly deploying to local IIS all through the build script.
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.
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.
And C# "fixes" the deficiencies by heaping features upon features. Already it looks like the MS version of Perl.
Scala with all of its symbolic notation would be more like Perl than C# is. Scala also can run on .net[1].
[1] http://www.scala-lang.org/old/node/10299
[1] http://www.scala-lang.org/old/node/10299
Except that between the two, only the JVM is truly cross platform, Mono notwithstanding.
Really? How can I use JVM on iOS? Is there a good toolchain for Java -> native iOS?
Besides RoboVM [1], there are also other solutions, like Codename One [2] that's based on XMLVM [3], or Avian [4] which is a new and very promising lightweight VM that can also compile code to native. And there's also J2ObcC [5] a compiler that's being developed and used by Google to share code between Android and iOS.
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/
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/
We were talking about servers. A Java program can run on just about every server platform out there, from puniest Windows Server machines all the way to IBM's largest mainframe and Cray's larger supercomputer.
sure there is - RoboVM just came out recently.
In any case, JVM runs on more platforms than any others.
In any case, JVM runs on more platforms than any others.
Has the Mono story gotten better? How feasible is it to develop without thousands of dollars of Microsoft software these days?
Mono has gained serious traction the last few years. I've personally been using it along side .Net and am loving it. You could develop in Windows with the Free/Express versions of Visual Studio etc. and deploy binaries to Linux. You could also use monodevelop (http://monodevelop.com) in Linux or OSX. There are C# plugins for Eclipse and IntelliJ as well.
Relevant: http://www.mono-project.com/Companies_Using_Mono https://servicestack.net/features http://stackoverflow.com/questions/18450/is-mono-ready-for-p...
Relevant: http://www.mono-project.com/Companies_Using_Mono https://servicestack.net/features http://stackoverflow.com/questions/18450/is-mono-ready-for-p...
> There are C# plugins for Eclipse and IntelliJ as well
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.
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.
http://emonic.sourceforge.net/index.html
IntelliJ still seems to be a wishlist item. Surprised there is nothing considering how many other great C# tools JetBrains produce.
IntelliJ still seems to be a wishlist item. Surprised there is nothing considering how many other great C# tools JetBrains produce.
For command line apps they're fine. For web apps you still need to host them on Windows + IIS since the Linux+Mono c# web hosting is awful.
It has been some time since I tried it
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.
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.
I'm sorry, but NuGet is a package manager that makes most Maven haters want Maven back...
Could you expand on "crappy OO features"?
I also like to know more about this C# package system you mentioned.
I would imagine he's talking about NuGet. Unless I've missed something dramatic in the past half year in the .net ecosystem.
You've also described Clojure...
I think that much of your fantasy is already a reality. For example, look at how Dropwizard[1] assembled a best-of-breed collection of modern Java libraries into a small, yet very powerful, REST micro-framework.
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/
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/
Ninja web framework [1] is also worth a look. It's similar to Dropwizard in that it's less of a framework and more like a well thought out archetype building upon the best Java libraries. Two main differences I see are Ninja uses Guice for DI whereas dropwizard is manual DI. Dropwizard uses JAX-RS while Ninja has its own Play 1 style routing system.
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
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
Dropwizard is a bit heavy by Node standards. The health checks, in the NPM-style system, would be its own package. The configuration class would be its own package. Resources would be their own package. Liquibase or Freemarker wouldn't be built in, nor would JDBI.
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 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'm sorry, I may have been misunderstood. I meant that Dropwizard exemplifies how you can pick and choose components, those atomic libraries, into a "framework" of your choosing. Dropwizard contains very little code. It's just an assembly of the parts you wished existed, and the proof that those parts already exist.
That makes sense, then. Looking at the source code briefly, it looks very similar to what I mean, especially if the parts are able to be used individually.
Dropwizard is pretty great, but one unfortunate aspect is that it's stuck with Jersey 1.x for JAX-RS and as a result is missing some nice features, like async responses, etc.
I only used it as an example to the fact that modern Java libraries bear little resemblance to those of yesteryear.
I do, however, think that standard JSR APIs are still really nice to have, if they're good.
I do, however, think that standard JSR APIs are still really nice to have, if they're good.
Java has always been a good language if you ignored the ecosystem. The ecosystem is a large part of what defines a language though. You have to take care in how you define that ecosystem.
I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.
I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.
Java has always been a good language if you ignored the ecosystem.
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?
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?
I think he's alluding to the stuff that comes after the language is released, not the language design/architecture itself. Node is not a language, so his comment probably implies that he's referring to the design choices of build system, development cycle (of tools, libraries and frameworks), and things like dependency management.
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).
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).
A language IS its ecosystem. In 2013 java is a good platform.
I believe the ecosystem mentioned is the consistently over-engineered AbstractFactoryFactory mindset that permeates so much of the Java space.
Hear hear. When I read about JVM performance issues I usually immediately think "team of 20+ complacent corporate devs who don't care if this succeeds or not because they can get a new job insanely easily at a moment's notice".
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.
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.
Here's[1] a comparison of the two from an RoR guy who used Play! (with Scala) for 16 months. I found the ensuing discussion pretty informative with minimal FUD / bashing.
[1]: https://groups.google.com/forum/#!searchin/play-framework/pl...
[1]: https://groups.google.com/forum/#!searchin/play-framework/pl...
Thanks but I've seen a lot of similar comparisons and they seem to focus on trivial things :/
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.
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.
> looking at Play as a potential new framework for a CRUD app with a very fancy UI.
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...
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...
Hmmm I don't know. I think the conventional wisdom is to use a service-oriented architecture with the best front-end tools you can find.
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.
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.
(In fact, for heavy processing stuff I'm pretty sure it's architecturally preferred to have it on a separate machine than the web-app server)
also just so you know i think AI, for example, is beyond the scope of this web stack quest. When "complex" is used in a web app it means concurrency issues, asynchronicity, eventing. Not necessarily computational stuff beyond that
[deleted](1)
So why not scala? Scala 8 years ago is where java 8 is now, and you can ignore most of the java frameworks.
Even putting aside my great dislike for Scala (which I discussed on HN ad nauseam :)), I think everyone would agree that Scala has a very different philosophy from Java. Java has been designed as a "blue-collar" language, with maintenance of a large project with possibly hundreds of developers as a central guiding principle. C#, Go, Dart, Kotlin, Fantom etc., have a similar philosophy. But Scala is a different beast altogether. You can love it or hate it, but even its most enthusiastic fans would concede that it is most certainly not appropriate as a replacement for Java in some/many/most (depending on your view) circumstances.
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.
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 wouldn't say that Java is extremely popular by any stretch. It's ubiquitous, but people aren't falling over themselves to become Java programmers anymore. I'd say Java is much less popular than it used to be (and I've run a Java Users' Group for 13 years). The JVM is still popular, but Java the language's popularity is arguably at a low point.
I don't think he means java is popular in the "cool" sense. He means it is popular because it is so widely deployed and still in use everywhere.
I agree that Java is widely adopted (thus my 'ubiquitous' comment). The fact that the commenter followed-up immediately with "some of its most painful points have been addressed in Java 8" led me to believe it was referring to being liked and not necessarily to being adopted.
I meant adoption, but mentioned that some of the issues that make it less well liked are being addressed.
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.
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.
That seems to be a pretty popular opinion among the Java pros that I know. Some of the early Scala adopters seemed to believe that, and many are likely still of that opinion. It may take years for an alternative JVM language to be dominant in terms of overall code, but might not be quite as far off when using a metric such as 'new projects'.
Java at corporation level is extremely popular.
On what do you base your assumption when you say nobody would recommend Scala as a replacement for Java? Scala has actually taken great pains to maintain seemless Java interop for this very reason.
It IS an improvement on/replacement for Java in most situations.
It IS an improvement on/replacement for Java in most situations.
That's not what I said. I said that no one would say that Scala can replace Java in all circumstances. Opinions vary greatly on what percentage the appropriate circumstances are (I think Scala is rarely a good replacement and never given the alternatives, while others, like you, say it's a good replacement in most circumstances - but not all).
In short, no one (who knows the software development landscape well, that is) can say Scala (or some other JVM languages) makes Java redundant.
In short, no one (who knows the software development landscape well, that is) can say Scala (or some other JVM languages) makes Java redundant.
I strongly contest that assertion. I'd say an honest variation would be the dream of scala is an improvement.
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.
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.
Implicits, SBT being anything but simple, and compile times. :) People have suggested sticking to a subset of Scala for most purposes, but what happens when you run into a problem with a library? Suddenly, you're diving into Slick (from a friend's example) or Play (from a personal, painful example) and can't make heads or tails of the code because of how different the paradigm is.
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.
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.
What did you find painful about Play? I've dived into its internals a number of times, including to submit a performance fix a few months ago, and I've found it to be quite easy to understand.
What's wrong with implicits?
Magic.
... done right?
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 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 think you want Clojure and leiningen.
Groovy with Gradle is a pretty good answer that is there today. Gradle way way way easier to work with than with Maven for your build system, publishes packages with dependency info, so you still get your dependencies sorted OK. Groovy has automatic setters/getters, a ton of functional-style helpers (closures, etc), dynamic & static mixins, delegates, etc.
Sorry, but in groovy, [[1 : 2]] - [["b" : "a"]] seems to be []. As long as they don't get fundamentals like this right i consider groovy only useful for demonstrating it's own deficiencies. The fact that this is in their Jira since 2010 and a fix would would be easy for anyone who understands the basics of hashcode and equals doesn't paint an all too rosy picture of the people behind groovy.
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.
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.
> 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.
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.
> Groovy with Gradle is a pretty good answer that is there today
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?
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?
My day job is in grails. :) However, some shops still have an aversion to other JVM languages.
"All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte."
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...
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...
Except that there is implicit dependency management.
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.
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.
I think your analogy makes a whole lot more sense when you keep in mind that you'd be a automotive engineer and not a consumer.
Have you looked at Groovy/Grails/Gradle? You can use the existing Java code and ecosystem or you can choose to do things the new way, you have access to a web framework similar to Rails, it's pretty nice.
> you have access to a web framework similar to Rails
Then why not just use Rails for Java, i.e. JRuby ?
Then why not just use Rails for Java, i.e. JRuby ?
Forget about OOP. Check Clojure.
I've had the misfortune of using the PayPal Java SDK to integrate PayPal credit card and Express payment into a web application. Based on that experience, I find it especially difficult to digest any opinion that PayPal has on Java. They may be experts on handling money, processing credit card payments, fraud prevention, and the like. (Or maybe not, given their reputation.) But their opinion on Java is about as meaningful to me as Microsoft's opinion on Java. Or more on point, a Rails developer's opinion on Java. Both are characteristically stale. And not "whew, that bread is really ripe, throw it out" stale. Rather, "what we have here is a new form of fungal life" stale.
I've worked with a fair number of Java APIs. I would put the quality of their Java SDK in the bottom 10%. It has the stench of really old Java. Remember how the first Java APIs reeked of C? The fact that the PayPal Java SDK still looked like hastily ported C code in 2011 when I last worked with it makes me worry that their entire manner of using Java is stuck in the early 2000s. That's being generous. It's the kind of Java you'd expect to see written by a company that still thinks about "applets" and "beans" and tries to come up with clever coffee double-entendres for their package names.
My theory: PayPal is big but they know they are vulnerable. They've acquired BrainTree and that helps. I suspect they want to improve their technical chops and felt a need to migrate away from Java in order to break free of their organizational quagmire. PayPal is from 1998 and if their Java SDK is any indicator, they probably have a Subversion commit log for their core systems going all the way back.
This sort of move is the kind of thing I could see myself doing if I were in a decision-making position at PayPal. Attempting to invigorate sensible modern Java practices within that organization would seem hopeless. I would have to start anew with an approach that is free of poisonous legacy.
As others have pointed out, the fact that a rewrite yielded so little performance gain is decidedly troubling. At least they got a fun and well-linked blog entry out of it. If I had just gone through that effort and reaped such a modest improvement, I'd be crestfallen.
I've worked with a fair number of Java APIs. I would put the quality of their Java SDK in the bottom 10%. It has the stench of really old Java. Remember how the first Java APIs reeked of C? The fact that the PayPal Java SDK still looked like hastily ported C code in 2011 when I last worked with it makes me worry that their entire manner of using Java is stuck in the early 2000s. That's being generous. It's the kind of Java you'd expect to see written by a company that still thinks about "applets" and "beans" and tries to come up with clever coffee double-entendres for their package names.
My theory: PayPal is big but they know they are vulnerable. They've acquired BrainTree and that helps. I suspect they want to improve their technical chops and felt a need to migrate away from Java in order to break free of their organizational quagmire. PayPal is from 1998 and if their Java SDK is any indicator, they probably have a Subversion commit log for their core systems going all the way back.
This sort of move is the kind of thing I could see myself doing if I were in a decision-making position at PayPal. Attempting to invigorate sensible modern Java practices within that organization would seem hopeless. I would have to start anew with an approach that is free of poisonous legacy.
As others have pointed out, the fact that a rewrite yielded so little performance gain is decidedly troubling. At least they got a fun and well-linked blog entry out of it. If I had just gone through that effort and reaped such a modest improvement, I'd be crestfallen.
Precisely.
I spent some time at PayPal and, one thing I think is being lost in all of these discussions is exactly what was "fixed."
All your points on introducing new practices to an older, establish (in the company) framework and technology are spot on. I see this as more a way to shake things up and improve things under the guise of new tech.
Also, this is in the top-most bit of their stack. All of the underlying services are the same. That's where the majority of the latency exists and a lot of it comes from old-school PayPal. But you can't shift a company by trying to tackle a deeply integrated bit of architecture first. The easiest place to demonstrate that change is feasible and actually quite beneficial (to a company that has been change-averse in the past) is your app tier. Get them on your side with an easy (easier?) win, then tackle the harder problems.
I spent some time at PayPal and, one thing I think is being lost in all of these discussions is exactly what was "fixed."
All your points on introducing new practices to an older, establish (in the company) framework and technology are spot on. I see this as more a way to shake things up and improve things under the guise of new tech.
Also, this is in the top-most bit of their stack. All of the underlying services are the same. That's where the majority of the latency exists and a lot of it comes from old-school PayPal. But you can't shift a company by trying to tackle a deeply integrated bit of architecture first. The easiest place to demonstrate that change is feasible and actually quite beneficial (to a company that has been change-averse in the past) is your app tier. Get them on your side with an easy (easier?) win, then tackle the harder problems.
PayPal do not care at all whether their APIs are developer-friendly. Why should they? They are a near-monopoly. You are completely dependent on them and they do not need you at all. I suspect their APIs are a result of minimising what they have to pay their own developers, because they win if they saved just one hour of development time even if 10 million vendors have to spend 10 hours each to work around the limitations.
In the very unlikely event that the developer has any influence in the choice of payment processor (i.e. you are a startup that intends to trade in only one country) they still do not care, because they still need to do the usual due diligence to check whether your company is a fraud/ML risk, but they earn little in fees from you. They would rather let a smaller payment processor deal with you, then try to take over later after your product is established.
In the very unlikely event that the developer has any influence in the choice of payment processor (i.e. you are a startup that intends to trade in only one country) they still do not care, because they still need to do the usual due diligence to check whether your company is a fraud/ML risk, but they earn little in fees from you. They would rather let a smaller payment processor deal with you, then try to take over later after your product is established.
Whose Java SDK would you rate at the top 10%? I'm curious.
Just to compare apples to apples—by which I mean credit card payment APIs—Stripe's Java API is superior. I'd not say it's a thing of beauty, but then, I don't want a credit card payment API to be anything but immediately approachable and obvious. And it is precisely that. Easy to understand.
https://stripe.com/docs/api/java
As for something I am happy with in recent memory, the Undertow builder model is appealing: http://undertow.io/
But you ask a tough question. I've not spent much time thinking about the best of the best. I suppose part of it is that a great API gets out of its own way and lets you get to work. So I suppose citing Stripe's first may have been the right thing.
https://stripe.com/docs/api/java
As for something I am happy with in recent memory, the Undertow builder model is appealing: http://undertow.io/
But you ask a tough question. I've not spent much time thinking about the best of the best. I suppose part of it is that a great API gets out of its own way and lets you get to work. So I suppose citing Stripe's first may have been the right thing.
Regarding the JVM performance:
> Under minimum load the best page rendering time was 233ms
Regarding the node.js performance:
> Under minimum load the best page rendering time was 249ms
What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going to be mostly waiting for external resources (DB, message queue, etc).
Without knowing how much time is spent on those external requests these numbers are meaningless.
Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms (though you could increase parallelism of multiple requests if done right).
> Under minimum load the best page rendering time was 233ms
Regarding the node.js performance:
> Under minimum load the best page rendering time was 249ms
What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going to be mostly waiting for external resources (DB, message queue, etc).
Without knowing how much time is spent on those external requests these numbers are meaningless.
Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
If every request you process involves serially accessing a 50-100ms external resource four or five times then it will always take 250ms (though you could increase parallelism of multiple requests if done right).
> Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
I bet they have a really crappy backend storage system for account history/data.
We have a PayPal transaction history with a low 6 digits record count. Searching for a specific email address, name, or transaction ID can take literally minutes. Exporting a transaction history CSV takes hours.
I bet they have a really crappy backend storage system for account history/data.
We have a PayPal transaction history with a low 6 digits record count. Searching for a specific email address, name, or transaction ID can take literally minutes. Exporting a transaction history CSV takes hours.
It only gets worse from there.
When we exported a CSV of our transaction history there were entries missing. We knew this because each line has a running balance and it wasn't adding up with the line before it.
When we told our paypal account manager about this it triggered an investigation. They claimed they had never seen it before and they sounded very worried about it.
They then told us that they have multiple different databases with transaction histories and that they were not consistent. They said that they had investigated the problem and found that it affected only a small percentage of customers.
They then pointed us to another CSV export form that doesn't seem to be able to be accessed via the normal UI and were told that this one would give us correct results. Unfortunately we were unable to export an entire year at once with this form as it seems to have some kind of time limit.
We had to export our history in little chunks that would take hours each. We asked our paypal account manager to prepare the CSV for us after finding this out, but she refused.
Having a large number of transactions in paypal sucks very bad.
Compare this to Stripe that proactively emailed us saying that they had noticed that queries for filtered transaction sets were taking a very long time so they had done some optimizations and were asking us to see if it had improved.
When we exported a CSV of our transaction history there were entries missing. We knew this because each line has a running balance and it wasn't adding up with the line before it.
When we told our paypal account manager about this it triggered an investigation. They claimed they had never seen it before and they sounded very worried about it.
They then told us that they have multiple different databases with transaction histories and that they were not consistent. They said that they had investigated the problem and found that it affected only a small percentage of customers.
They then pointed us to another CSV export form that doesn't seem to be able to be accessed via the normal UI and were told that this one would give us correct results. Unfortunately we were unable to export an entire year at once with this form as it seems to have some kind of time limit.
We had to export our history in little chunks that would take hours each. We asked our paypal account manager to prepare the CSV for us after finding this out, but she refused.
Having a large number of transactions in paypal sucks very bad.
Compare this to Stripe that proactively emailed us saying that they had noticed that queries for filtered transaction sets were taking a very long time so they had done some optimizations and were asking us to see if it had improved.
[deleted]
> Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
i'm pretty sure the paypal node app does not directly access the db , the node app talks to a private api.
i'm pretty sure the paypal node app does not directly access the db , the node app talks to a private api.
That doesn't really change the point, it just wraps it with a layer of abstraction.
Well, it adds another opportunity for a chatty API to add latency.
[deleted]
This was a good read. Minor nitpick, given the author's stress of not comparing apples to oranges I think the motivating anecdote on protein folding struck a dissonant cord. A fair comparison would have been a profile guided optimization with comparably aggressive compile optimization flags.
For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up time.
Java can indeed be very fast, and in my opinion JVM is the one of the most optimized VMs that we have now. That said Java code beating a C or a C++ code on a CPU bound task raised an eyebrow. In my experience Java usually gets to the 80% speed of C++ quite easily but at a cost of 2.5 to 3.5 the memory. For these types of applications memory tends to be an expensive resource. For our number crunching server, 80% of its cost is sunk in the RAM.
For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up time.
Java can indeed be very fast, and in my opinion JVM is the one of the most optimized VMs that we have now. That said Java code beating a C or a C++ code on a CPU bound task raised an eyebrow. In my experience Java usually gets to the 80% speed of C++ quite easily but at a cost of 2.5 to 3.5 the memory. For these types of applications memory tends to be an expensive resource. For our number crunching server, 80% of its cost is sunk in the RAM.
My experience is similar: Java will get you 80% of super-optimized-compiled C++ speed for the cost of more memory (although you may choose to give Java less memory and pay in speed), and will get much closer to C++ speed with some work (off-heap memory, etc.). However, Java has the upper hand in two scenarios: 1) long-running applications that are developed by a large team – those usually make heavy use of virtual inheritance for the sake of good engineering, and the execution profile is not static, so the program can greatly benefit from JIT optimization; and 2) fairly complex multithreaded code – Java's incredibly useful and well-implemented blocking and lock-free data structures, as well as an incredible work-stealing scheduler (all expertly programmed by Doug Lea) make great use of a general purpose GC, plus Java usually gets them about 5 years before C++ (if C++ gets them at all).
Don't forget the tools and infrastructure that support good engineering (dependency management, build, javadoc, findbugs, checkstyle, PMD, cobertura for code-coverage, better unit-testing frameworks, the list goes on).
I'm sure C++ ecosystem has some of those but whether people are using them or not seem quite obvious: how many C++ projects do that out there? Not as many as the Java counterpart.
I'm sure C++ ecosystem has some of those but whether people are using them or not seem quite obvious: how many C++ projects do that out there? Not as many as the Java counterpart.
> how many C++ projects do that out there? Not as many as the Java counterpart.
I'm not sure this is a good argument.
Projects where performance is critical are coded in C/C++ , not in java ( browsers , AAA games , databases , servers , micro-controllers , oses... ). C/C++ programming is not about writing 'elegant' code with FactoryFactories , but performances. Even if it means using very basic data structures instead of classes or inlining functions everywhere.
I'm not sure this is a good argument.
Projects where performance is critical are coded in C/C++ , not in java ( browsers , AAA games , databases , servers , micro-controllers , oses... ). C/C++ programming is not about writing 'elegant' code with FactoryFactories , but performances. Even if it means using very basic data structures instead of classes or inlining functions everywhere.
I'm referring to the tools that ensure the code quality, not the performance critical aspect of it.
Besides, all of the projects I've worked for has no FactoryFactories so let's cut that song right here right now.
Besides, all of the projects I've worked for has no FactoryFactories so let's cut that song right here right now.
> Projects where performance is critical are coded in C/C++ , not in java ( browsers , AAA games , databases , servers , micro-controllers , oses... ).
This is not true. C++ beats Java performance in constrained environments. On servers the situation is not so clear-cut. You see some really fast Java databases.
And BTW, Java is better at inlining functions than C++, but C++ handily beats Java when it comes to controlling memory layout (though that, too, is changing).
This is not true. C++ beats Java performance in constrained environments. On servers the situation is not so clear-cut. You see some really fast Java databases.
And BTW, Java is better at inlining functions than C++, but C++ handily beats Java when it comes to controlling memory layout (though that, too, is changing).
> This is not true. C++ beats Java performance in constrained environments
Every environment is constrained. Devs just got lazy and scaling now means buying more machines instead of performance optimisation.
> You see some really fast Java database
That eat up way to much memory for little.
When you see popular java based os , tell me.
Every environment is constrained. Devs just got lazy and scaling now means buying more machines instead of performance optimisation.
> You see some really fast Java database
That eat up way to much memory for little.
When you see popular java based os , tell me.
> Projects where performance is critical are coded in C/C++ , not in java (databases)
HBase, Cassandra, VoltDB
HBase, Cassandra, VoltDB
I believe the core of VoltDB (the in memory storage engine) is written in C++. See here: https://github.com/VoltDB/voltdb/blob/master/src/frontend/or...
"VoltDB mainly consists of Java modules for easier development. However, the core EE and its underlying on-memory storage system is implemented in C++. Nowadays Java and C++ have almost same performance for many cases, but C++ still outperforms Java on low-level memory accesses. This is why we have EE and its storage system written in C++."
"VoltDB mainly consists of Java modules for easier development. However, the core EE and its underlying on-memory storage system is implemented in C++. Nowadays Java and C++ have almost same performance for many cases, but C++ still outperforms Java on low-level memory accesses. This is why we have EE and its storage system written in C++."
Actually, my favorite bits are runtime linking, JMX, VisualVM and, most recently, FlightRecorder + Java Mission Control, which has to be one of the coolest profilers I've seen. But I was just talking about performance.
Don't forget the javaagent and the ability to instrument JVM. Event .NET/CLR doesn't have that (They have some low-level COM/Profiler API but boy that takes a lot of effort to work with).
How could I forget? I personally use runtime instrumentation all the time: https://github.com/puniverse/quasar
Sorry I don't mean to hijack thread or anything like that but I work for AppNeta and we're on the APM field instrumenting various platforms. If you ever need an instrumentation tools for your full-stack infrastructure, check us out :).
Almost agree, but minor nitpick: the tools and infrastructure (at least most of them) exist on other platforms in the same or better quality as well. Especially dependency management is not necessarily a strong side of Java (one global namespace for types etc.).
> one global namespace for types
I am not entirely sure what you mean by that, but in Java, a runtime type is determined as a combination of its name and its class-loader. You can (and do) have two versions of the same class running alongside one another in different modules of your code.
Granted, supporting this stuff is not easy, but hopefully the long awaited module system planned (currently...) for Java 9 is supposed to make this all both powerful and easy.
I am not entirely sure what you mean by that, but in Java, a runtime type is determined as a combination of its name and its class-loader. You can (and do) have two versions of the same class running alongside one another in different modules of your code.
Granted, supporting this stuff is not easy, but hopefully the long awaited module system planned (currently...) for Java 9 is supposed to make this all both powerful and easy.
Well, the OSGi module system supports this now and is quite powerful. Oh wait, you also said easy.
I debated including that example, but at the end the point I was making is that the JVM can be faster than native code in some cases... this case had static allocation of data and the calculations could benefit from MMX instructions when available, plus there was a logical unrolling that I think it was able to infer from code path analysis
And superword optimization, when possible...
Well-reasoned.
I've always found framework overhead and especially tech debt to be the largest contributors to performance issues. Especially when said frameworks have lots of ways to do things and they're not all the best way to do it.
Modern JVM development starts to look a lot like Sinatra -- you don't get a lot baked in, but you probably didn't need it anyways.
I've always found framework overhead and especially tech debt to be the largest contributors to performance issues. Especially when said frameworks have lots of ways to do things and they're not all the best way to do it.
Modern JVM development starts to look a lot like Sinatra -- you don't get a lot baked in, but you probably didn't need it anyways.
The biggest contributor to performance issues these days, from what I've seen, is synchronous code. The JVM can be blindingly fast at running your code, but when it hits a point where you make a database call or web services call that's implemented synchronously, it sits there, waiting, doing nothing. No amount of VM optimizations can increase of the speed of idling code.
This is why Node apps often out-perform Java apps despite running on a VM that's significantly slower. Node is pervasively asynchronous...it's baked into the DNA of the platform and almost all libraries follow that philosophy. And as organizations move to a micro-services architecture where one external call can result in multiple internal calls between systems, the need for reactive, asynchronous programming becomes all the more glaring.
That's where this critique, for me, fell down. It's spent too much time comparing the JVM to V8 and not enough time talking about how the applications being run were designed. Because CPUs are fast enough these days that any of the VMs will give you decent performance for workloads that aren't CPU-bound as long as you, the application designer, do the right thing. It's just that some environments, Node in particular, make it easier to do the right thing. This will get easier in Java with the introduction of lambdas in Java 8 and the inevitable asynchronous community frameworks and libraries, but right now it's still harder to write reactive applications in Java than it is in Node.
This is why Node apps often out-perform Java apps despite running on a VM that's significantly slower. Node is pervasively asynchronous...it's baked into the DNA of the platform and almost all libraries follow that philosophy. And as organizations move to a micro-services architecture where one external call can result in multiple internal calls between systems, the need for reactive, asynchronous programming becomes all the more glaring.
That's where this critique, for me, fell down. It's spent too much time comparing the JVM to V8 and not enough time talking about how the applications being run were designed. Because CPUs are fast enough these days that any of the VMs will give you decent performance for workloads that aren't CPU-bound as long as you, the application designer, do the right thing. It's just that some environments, Node in particular, make it easier to do the right thing. This will get easier in Java with the introduction of lambdas in Java 8 and the inevitable asynchronous community frameworks and libraries, but right now it's still harder to write reactive applications in Java than it is in Node.
> Node is pervasively asynchronous
Personally I view that as a drawback. It's all fine, until you end up with CPU-bound tasks or until you end up talking with backend servers that don't support many concurrent requests.
The JVM support for multi-threading is absolutely stellar. You've got true 1:1 kernel-level threading, with no GILs and you've got access to the best primitives available for dealing with multi-threading issues, atomic references, re-entrant read-write locks, fork-join thread-pools, non-blocking data-structures, asynchronous I/O guaranteed to work well cross-platform, all of them backed by a guaranteed memory model that also works well cross-platform, plus garbage-collectors that are the most advanced garbage collectors in mainstream usage. G1/CMS are amazing for servers and if you've got cash to spend, Azure's pauseless GC is probably as close to real-time as you can get with a GC.
And on top of these you can build whatever concurrency handling architecture you want. Including Erlang-style Actors (e.g. Quasar, Akka), STM (Clojure, Scala-STM), persistent data-structures (Clojure, Scala), asynchronous streams (Play2's Iteratees, RxJava Observables, Scalaz Machines, Scalaz Streams).
Even when speaking of Node.js's strengths, like asynchronous I/O, I still think Java is better because of the foundations (e.g. NIO, Netty, Mina). The only reason people don't work much with asynchronous workflows is because the language is so freaking painful for that. But that will change with Java 8 and people are doing wonders in Scala/Clojure.
I've personally built an entire web-service, designed to handle thousands of requests per second per frontend instance, with responses generated in under 30ms, with a completely asynchronous workflow, on top of Scala/Akka/Play2. Node.js people don't know what they are missing.
Personally I view that as a drawback. It's all fine, until you end up with CPU-bound tasks or until you end up talking with backend servers that don't support many concurrent requests.
The JVM support for multi-threading is absolutely stellar. You've got true 1:1 kernel-level threading, with no GILs and you've got access to the best primitives available for dealing with multi-threading issues, atomic references, re-entrant read-write locks, fork-join thread-pools, non-blocking data-structures, asynchronous I/O guaranteed to work well cross-platform, all of them backed by a guaranteed memory model that also works well cross-platform, plus garbage-collectors that are the most advanced garbage collectors in mainstream usage. G1/CMS are amazing for servers and if you've got cash to spend, Azure's pauseless GC is probably as close to real-time as you can get with a GC.
And on top of these you can build whatever concurrency handling architecture you want. Including Erlang-style Actors (e.g. Quasar, Akka), STM (Clojure, Scala-STM), persistent data-structures (Clojure, Scala), asynchronous streams (Play2's Iteratees, RxJava Observables, Scalaz Machines, Scalaz Streams).
Even when speaking of Node.js's strengths, like asynchronous I/O, I still think Java is better because of the foundations (e.g. NIO, Netty, Mina). The only reason people don't work much with asynchronous workflows is because the language is so freaking painful for that. But that will change with Java 8 and people are doing wonders in Scala/Clojure.
I've personally built an entire web-service, designed to handle thousands of requests per second per frontend instance, with responses generated in under 30ms, with a completely asynchronous workflow, on top of Scala/Akka/Play2. Node.js people don't know what they are missing.
Yes. JAX-RS (the standard implemented by Jersey), which is part of the often maligned Java EE, is a (surprisingly?) well designed REST "microframework". Java EE in general has come a long way from the monster it used to be, and is becoming quite pleasant.
You can use Servlet + Jersey. It's just one dependency away and minimal web.xml config (or spring-jersey...whichever). It's not necessarily tied to Java EE albeit Java EE app-server _must_ implement JAX-RS properly.
Both Servlet and JAX-RS are pretty central pieces of Java EE. But Java EE is now really a collection of modules that you can pick and choose.
> Spring brings a lot of functionality to the table. Likely far too much functionality. Most people are moving away from the monolithic application and moving towards smaller more lightweight frameworks…
It's high time to debunk Spring. In the name of 'Dependency Injection' many Java developers still create complex, monolithic and - first of all - untestable applications with this framework. In fact, Spring adds another layer of complexity on top of Java EE without real benefit. It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally).
It's high time to debunk Spring. In the name of 'Dependency Injection' many Java developers still create complex, monolithic and - first of all - untestable applications with this framework. In fact, Spring adds another layer of complexity on top of Java EE without real benefit. It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally).
I'm pretty good with Spring and have even given trainings on it and I'd argue that Spring's main problem is that it needs to be seen in the right context: a poor man's DSL for declarative system configuration (it is last 10 years old after all.)
That it creates untestable applications seems like completely nonsensical FUD however since the entire point of Spring is to keep code easily testable. Spring is an almost direct response to the lack of testability of the ServiceLocator anti-pattern.
I'm not saying you can't make untestable code in Spring, but if you do the problem is most likely more with the people than with Spring.
That it creates untestable applications seems like completely nonsensical FUD however since the entire point of Spring is to keep code easily testable. Spring is an almost direct response to the lack of testability of the ServiceLocator anti-pattern.
I'm not saying you can't make untestable code in Spring, but if you do the problem is most likely more with the people than with Spring.
I've done a lot of Spring side work and your first paragraph is the best explanation I've ever read for the framework.
I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the both the class and module functionality layer.
I also agree that if you can't test Spring code you are doing something wrong. I get the frustration with having to create test harnesses for some things, and the SpringJ4Unit stuff oftentimes feels a bit too magical, but I've never seen well written Spring code that wasn't easily testable at the both the class and module functionality layer.
With Spring you can easily test your empty mocked-out shells. Great!
"It fosters Anti-Patterns like 'Dependency Injection' that give you the illusion of modularity but instead create dependencies within the application ('Dependency Injection' needs to be taken literally)."
What? Any system with separated modules is going to have dependencies. At least with DI, classes are written to a interface and different versions easily be swapped in and out.
What? Any system with separated modules is going to have dependencies. At least with DI, classes are written to a interface and different versions easily be swapped in and out.
> Any system with separated modules is going to have dependencies.
Thank you. I thought I was the only doing my nut in over "I've done DI, now I have all the same dependencies" ... adds DIC ... "Now I have all the same dependencies but higher up, and.. oh I need to add logging to 80% of the objects" [Goes to kill myself]
I have OCD about writing beautiful code. The more I try, it seems to real world prevents it from happening.
Eager to learn so if good demo code, resources, books or I'm missing something (obvious or not) I'm all ears.
Thank you. I thought I was the only doing my nut in over "I've done DI, now I have all the same dependencies" ... adds DIC ... "Now I have all the same dependencies but higher up, and.. oh I need to add logging to 80% of the objects" [Goes to kill myself]
I have OCD about writing beautiful code. The more I try, it seems to real world prevents it from happening.
Eager to learn so if good demo code, resources, books or I'm missing something (obvious or not) I'm all ears.
Try dependency management instead of dependency injection. Layered, modular, hierarchical design instead of 'anything injected into anything'. Divide and conquer instead of DI spaghetti. Testable independent modules instead of mocked-out stubs...
If you want to promote an alternate paradigm you might want to learn to directly argue in favor of your alternative, tather than randomly attacking things that don't fit your personal aesthetics.
I'm also not particularly enamored with the current state of affairs although my pet peeve is more with the lack of adoption of functional reactive programming. That doesn't mean though that I refuse to acknowledge what (or when) Spring was good for or how it fits into the evolution of the industry.
I'm also not particularly enamored with the current state of affairs although my pet peeve is more with the lack of adoption of functional reactive programming. That doesn't mean though that I refuse to acknowledge what (or when) Spring was good for or how it fits into the evolution of the industry.
TL;DR from the post:
"""
My take-home for you, the persistent reader who has read all my ramblings in this post...
Don’t build your app on top of a pile of crap in-house framework. """
Don’t build your app on top of a pile of crap in-house framework. """
Which suggests that take-home #0 should be:
Don't build a pile of crap in-house framework.
Sniffing that out before too late is the tricky part...
Sniffing that out before too late is the tricky part...
This reads like someone reading a 1995 article about a company switching from writing Netscape Enterprise Server code in C++ on a Windows machine to Apache code in perl on a Sun server, and then writing a defense of the x86 processor against SPARC.
I might have missed something but I don't recall the original PayPal article arguing that the switch was motivated by moving from a slow virtual machine to a faster one.
But just as switching from C++ to perl would trade some computing power for productivity in getting a site built, I don't see it as controversial for an organization to say they achieved the same productivity gains going from java to javascript.
I might have missed something but I don't recall the original PayPal article arguing that the switch was motivated by moving from a slow virtual machine to a faster one.
But just as switching from C++ to perl would trade some computing power for productivity in getting a site built, I don't see it as controversial for an organization to say they achieved the same productivity gains going from java to javascript.
Two poorly written apps compared with blame for each placed on the underlying virtual machine rather than the part between the chair and the keyboard. I'd much rather compare VMs and systems with something a little more structured and open like the TechEmpower benchmarks. They still have their flaws and simplifications, but at least the source for all apps is open and you can see and contribute to them.
That is a refreshingly sober point of view. Blaming frameworks is easy. Speaking of technical debt is hard.
I stopped reading at the part with the "Type information". Or better i should have stopped...
Another post about(and the from paypal too) about my language X vs language Y...
It's the same flameware like Facebook started with its we can't get HTML5 as fast as native... then some people who know what they where doing did it...
No don't use java No don't use javascript
For god sake learn one language or two and learn it very well! i mean very well! and you will write good code and performant code...
EDIT: Why do i get down voted? Jesus HN gets worse and worse...
It's the same flameware like Facebook started with its we can't get HTML5 as fast as native... then some people who know what they where doing did it...
No don't use java No don't use javascript
For god sake learn one language or two and learn it very well! i mean very well! and you will write good code and performant code...
EDIT: Why do i get down voted? Jesus HN gets worse and worse...
You're getting downvoted because this isn't a "language X vs language Y" article at all. Its point is that the language choice doesn't matter when you're building on top of crap, and jumping from one language to another probably won't solve platform problems. It's an article about the politics of being a software developer in enterprise where management is entrenched in legacy codebases, not about language features.
What?
the first part is exactly that...
for example:
"So which is the faster virtual machine, V8 or JVM? My belief is that when you are coding in the most basic building blocks of either virtual machine (i.e JavaScript vs JVM Byte Code) that the JVM will win out every time. If you start to compare higher up, you may end up comparing apples with oranges and see false comparisons. For example, if we consider this comparison of V8 vs JVM performance at mathematical calculations. This blog post tells us that if we relax our specifications we can calculate things faster. Here is the specification that V8 must use for Math.pow and here is the specification that the JVM must use for Math.pow notice that the JavaScript specification allows for an “implementation-dependent approximation” (of unspecified accuracy) while the JVM version has the addition that"
and at the second part too: "... a limit of Node.js itself when used with the backing APIs that they have to call through to."
It's just hidden better... to me it reads like a java fan boy is crying why a company switched to language X from his language Y...
and at the second part too: "... a limit of Node.js itself when used with the backing APIs that they have to call through to."
It's just hidden better... to me it reads like a java fan boy is crying why a company switched to language X from his language Y...
Your analysis is too shallow. The only reason he attempts to compare node.js to Java at all is to reach his point: that the decision was probably more about company politics than tech benefits. The team used a different language not because it's better or worse, but because it'd allow them to avoid building on top of the existing framework -- a chance to get rid of technical debt and start a fresh code base, even if just a seed.
I wonder if a lot of headway could have been made simply by doing some constraint analysis on the Spring framework and figuring out how to improve the performance. I have a hard time believing that Spring itself was completely topped out. It might have been an architectural choice, or some bloat that could have been taken out incrementally.
Instead they seem to be going the route of "the unicorns will solve it". The overall cost of that approach seems higher - finding unicorns is rare. Finding unicorns that are very good at all areas is even harder. I know there are a lot of unicorns on this board, but there sure aren't a lot of unicorn resumes on a hirer's desk.
I think the value of Spring has always been not that it's super-high-performance out of the box, but that it does a lot for you, and that as you learn more and more of it, you can develop solutions fairly quickly. It's built to make it easier on the developer, not the servers - but it is still easy to improve performance by focusing on constraints.
I think it's easy to blame what's between the keyboard and the chair, but the availability of said unicorns is the one ingredient of the system that is not in an employer's control. What is in control is sponsoring more education, and focusing on simplicity and constraint analysis.
Instead they seem to be going the route of "the unicorns will solve it". The overall cost of that approach seems higher - finding unicorns is rare. Finding unicorns that are very good at all areas is even harder. I know there are a lot of unicorns on this board, but there sure aren't a lot of unicorn resumes on a hirer's desk.
I think the value of Spring has always been not that it's super-high-performance out of the box, but that it does a lot for you, and that as you learn more and more of it, you can develop solutions fairly quickly. It's built to make it easier on the developer, not the servers - but it is still easy to improve performance by focusing on constraints.
I think it's easy to blame what's between the keyboard and the chair, but the availability of said unicorns is the one ingredient of the system that is not in an employer's control. What is in control is sponsoring more education, and focusing on simplicity and constraint analysis.
What a shocker... a Java guy says that you shouldn't abandon Java :-)
Lots of wild speculations... especially about the reasons PayPal picked node.js/JavaScript instead of a Ruby stack. He says that Ruby wasn't chosen because you can run it on JVM ignoring the fact that you can run JavaScript on JVM too using DynJS (he actually mentions DynJS earlier in his blog post).
Lots of wild speculations... especially about the reasons PayPal picked node.js/JavaScript instead of a Ruby stack. He says that Ruby wasn't chosen because you can run it on JVM ignoring the fact that you can run JavaScript on JVM too using DynJS (he actually mentions DynJS earlier in his blog post).
First post on HN. I'm not entirely sure how the PayPal Node vs. Java message has been packaged, but I think there is a lot of confusion. From my understanding (via blogs and conferences), Node was used to replace Java on the front-end. Meaning, the Node front-end is still calling Java + other stacks upstream -- which likely explains the performance benchmarks (the front-end wasn't the bottle neck). That said, even with similar performance benchmarks, I can see how Node might result in higher developer productivity for the front-end components of PayPal -- hence the enthusiasm they are showing. Lot's of negativity and blame on this thread, but I think it's because people are making assumptions.
This is more about PayPal's dirty laundry than an comparative evaluation of technologies. If a collective set of tools are used improperly, comparisons beyond the context of those walls means very little.
In our first lecture at graduate college, the prof told us how to read research papers.
Rule 1 : Louder the guest shouts of his honor, faster you should count your spoons.
Similarly if someone tells you about 50% savings just because you switched to some other technology you should be extremely skeptical. Besides those people who engage in `Node vs X` debate every now and then should spend some time educating themselves about compilers and interpreters to understand what makes some programming languages faster than others in certain circumstances.
Rule 1 : Louder the guest shouts of his honor, faster you should count your spoons.
Similarly if someone tells you about 50% savings just because you switched to some other technology you should be extremely skeptical. Besides those people who engage in `Node vs X` debate every now and then should spend some time educating themselves about compilers and interpreters to understand what makes some programming languages faster than others in certain circumstances.
He forgets to mention one critical fact: developer productivity. Most applications (sans his terrible example of protein folding) are not that performance critical. Most of the code you write as a developer will do-away with any platform or language advantages itself.
It is not productive to write web applications in Java. Everyone hates it, which is why we have ruby, php, and now javascript (node).
I'd much rather trade a little performance for a scripting language anyday.
It is not productive to write web applications in Java. Everyone hates it, which is why we have ruby, php, and now javascript (node).
I'd much rather trade a little performance for a scripting language anyday.
I wonder if someone has written up comparisons on their productivity between the languages / frameworks. My previous job had me on the python stack (Pyramid / Mako / Sqlalchemy), which I loved, but have been on Java / Play! framework for the last 10 months. The one thing that has consistently surprised me is how productive I feel writing Java. Mainly, I notice I make far fewer mistakes / typos while coding; the IDE does a great deal of the work for me, and as the application grows, having static types has (for me) improved the readability of code I haven't looked at for a while.
No doubt a large part of any language choice is subjective, but I'm starting to believe that developer productivity has more to do with the tools and frameworks than the language itself. As these continue to improve in Java-land, I'm willing to bet that the disparity in productivity will continue to decrease.
No doubt a large part of any language choice is subjective, but I'm starting to believe that developer productivity has more to do with the tools and frameworks than the language itself. As these continue to improve in Java-land, I'm willing to bet that the disparity in productivity will continue to decrease.
>The one thing that has consistently surprised me is how productive I feel writing Java.
I know exactly how you feel. I recently moved from a Java project to a Python one and felt a little amiss without the power that an IDE gives a statically typed language. The tooling for Python flat out sucks. And it pains me to say, as I love the language to death, but I do feel more productive in other languages. Whether or not that's true is another thing entirely, but it does feel like a lot of time is wasted calling `dir` on objects to figure out what the hell the name was of the function you need.
As of about a week ago I switched from my text editor + console to Eclipse + PyDev. It's not perfect -- intellisense functionality is really hit or miss, but it does make me feel a lot more productive. The background linting is pretty good at catching basic errors as you type them, which is really nice.
It's also does an OK job at renaming things -- which is generally a nightmare to do on a big project in Python.
So, point being, while I miss a lot of the other tooling that an IDE affords a statically typed language, PyDev gets you, like, 80% of the way there. Worth checking out if you move back to Python.
I know exactly how you feel. I recently moved from a Java project to a Python one and felt a little amiss without the power that an IDE gives a statically typed language. The tooling for Python flat out sucks. And it pains me to say, as I love the language to death, but I do feel more productive in other languages. Whether or not that's true is another thing entirely, but it does feel like a lot of time is wasted calling `dir` on objects to figure out what the hell the name was of the function you need.
As of about a week ago I switched from my text editor + console to Eclipse + PyDev. It's not perfect -- intellisense functionality is really hit or miss, but it does make me feel a lot more productive. The background linting is pretty good at catching basic errors as you type them, which is really nice.
It's also does an OK job at renaming things -- which is generally a nightmare to do on a big project in Python.
So, point being, while I miss a lot of the other tooling that an IDE affords a statically typed language, PyDev gets you, like, 80% of the way there. Worth checking out if you move back to Python.
Pycharm>Pydev by many accounts.
>Everyone hates it ...
I don't; that's a bit of a sweeping generalization. I happen to enjoy writing webapps in JAX-RS and Wicket, and I know a number of folks who enjoy writing them in other frameworks.
I don't; that's a bit of a sweeping generalization. I happen to enjoy writing webapps in JAX-RS and Wicket, and I know a number of folks who enjoy writing them in other frameworks.
Would really prefer java over php and JavaScript.
Closure, python, c#, f# over Java. But I quite like the java ecosystem. There's normally library for anything.
Closure, python, c#, f# over Java. But I quite like the java ecosystem. There's normally library for anything.
Application based comparisons are usually flawed, because the writer will never and cannot release enough info to reveal the real problem. Just because your bad-performing application runs faster on one platform doesn't necessarily mean that platform is superior to the old one. It simply means whatever problems you have in your bad-performing application manifests less in the new platform. In the end, fix your application!
TL;DR:
* Micro-benchmarks don't provide a good picture of real system performance and can be skewed to make almost anything look better/worse than anything else.
* Much of Java's "slowness," clunkiness, large amounts of boilerplate code, etc. is the fault of the Java ecosystem and libraries rather than the language itself or the JVM.
* The inverse is true for Node: the quality of its ecosystem helps make up for language and runtime shortcomings.
* Micro-benchmarks don't provide a good picture of real system performance and can be skewed to make almost anything look better/worse than anything else.
* Much of Java's "slowness," clunkiness, large amounts of boilerplate code, etc. is the fault of the Java ecosystem and libraries rather than the language itself or the JVM.
* The inverse is true for Node: the quality of its ecosystem helps make up for language and runtime shortcomings.
I was reminded that self deceit is the worst of its kind on reading the article. seeing a benchmark and deciding what to write your next application in kinda like that. you browse until you find the benchmark that aligns with what works out best for the lazy you and not works out best for the faithful app. this was just an observation of mine and not necessarily true or applicable to you.
Maybe we should assume the best instead of the worst. We could assume that paypal has capable developers who are knowledgeable about both the jvm and node.js, and who have concluded that their specific featureset can best be built using node. That is not a value judgment of the jvm vs node in general, as their situation is theirs and theirs alone.
Lots of people trying to unblub blub.
I'd venture a guess that mimicking Node.js isn't going to fix the deeper problems with Java.
I'd venture a guess that mimicking Node.js isn't going to fix the deeper problems with Java.
So far I tried compiling some of my numeric Scala code to JS with Scala.JS and unfortunately running that code in Chrome is much, much slower (~10-20 times) than running the original version on Java 7. :( Not sure if it is because Scala.JS creates poor code, or just JS is still not as fast as they claim.
Current version of Scala.JS is an alpha release, don't expect miracles.
[deleted]
I think it comes to this: Java > JavaScript. But Java programmer < JavaScript programmer, due to culture. (ex: Spring, Maven, EJB light).
If Java programmer is true polyglot, then whatever tool you are using wins. That's why C programmers are the best.
If Java programmer is true polyglot, then whatever tool you are using wins. That's why C programmers are the best.
Does anyone know how vertx[1] fits into this picture? It gives you the JVM, JavaScript, and non-blocking I/O.
[1]: http://vertx.io/
[1]: http://vertx.io/
Nodyn is an effort to run node.js apps on top of Vert.x. JavaScript alone is not enough to make Vert.x popular for node.js people. You need to be able to leverage the node.js module echosystem. Hopefully Nodyn will do that, so you can use your favorite node modules on Vert.x. It's still a work in progress though.
Cool, Nodyn looks interesting. Thanks for the info.
Incredible insight... Here's the TLDR: Everything is faster when you engineer it a second time. Rewriting in a different language is not an apples to apples comparison.
Management won't take the blame but ... who allowed the architects/engineers to build two systems that failed the same way?
I agree that management is likely a problem here, but disagree with the framing.
If you're in a structure where management's job is to allow/deny, then I think the code is already doomed. Software development is work that can't be effectively micromanaged.
In software, I think management's job is to support and challenge. All the people coding should be professionals, thoughtful and aware of issues like tech debt, second-system effects, reinventing the wheel, and so on. Management's job isn't to be more professional than the pros; it's to support the pros and make sure they're living up to (and sometimes advancing) their professional standards.
I'm sure there are plenty of people who work with these frameworks that know that they're crap. Management didn't fail by allowing these to get built. They failed by creating power relationships that allowed the people who couldn't see the problems to control the building of the frameworks, and to suppress criticism and improvement.
If you're in a structure where management's job is to allow/deny, then I think the code is already doomed. Software development is work that can't be effectively micromanaged.
In software, I think management's job is to support and challenge. All the people coding should be professionals, thoughtful and aware of issues like tech debt, second-system effects, reinventing the wheel, and so on. Management's job isn't to be more professional than the pros; it's to support the pros and make sure they're living up to (and sometimes advancing) their professional standards.
I'm sure there are plenty of people who work with these frameworks that know that they're crap. Management didn't fail by allowing these to get built. They failed by creating power relationships that allowed the people who couldn't see the problems to control the building of the frameworks, and to suppress criticism and improvement.
Damn, paypal really suck at making fast sites.
Summary: Most frameworks sux.
Wrong. PayPal refuses to use open source frameworks because of an internal culture (and self preservation interest) of some very old "architects" who really only care about being in charge of the next internal framework. The best part is they later get to showcase how much better the new one is compared to the old framework, even though it's multiples slower than the slowest open-source counterpart.
Their node.js "framework" is really just a couple modules sitting on top of express, and they are all open-source.
Spring is open source. From the sounds of things, they replaced Spring with a closed in-house framework.
"Based on Spring" is not Spring. I worked there for a bit, they called it Sparta, and its appeal to the top tech brass was they could restrict which objects are available for use in the library they provided for you. The subtle message behind it was, we can hire anyone as long as we limit what they can do.
Thanks, I stand corrected. Sounds heinous.
That's atrocious.
One thing I'll never understand is how companies get so hungry for developers that they subconsciously admit to hiring amateurs: "well, Joe can't do too much damage!"
One thing I'll never understand is how companies get so hungry for developers that they subconsciously admit to hiring amateurs: "well, Joe can't do too much damage!"
Or PayPal programmers.
Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and java's poor implementation of OOP ignored.
Heck, fork Spark, split out the individual pieces as modules, and start there.
All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte.
I'd argue that java is a better back end language than javascript in and of itself, but that the community norms have led to the pain we see.
Have an extreme preference for 1.8 code (IE, the new java.time system) and away from anything bloated. Rethink for the common use cases, rather than trying to support everything under the sun. Spring still exists for that, after all. :)
The problem with java isn't that it's a BLUB language anymore, but that it's a BLUB ecosystem. I'm not saying the language is perfect, but Java 8 as good as ruby or javascript for web development if the ecosystem is ignored.