9 ms·

If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money eit

If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore. Say what you will about Java the language (I agree it's not particularly "sexy") but the JVM is a performance beast. You can write Java or pick from one of several other languages that range across different paradigms from static functional to dynamic (current gen: Scala, Groovy, JRuby, Jython, next-gen: Kotlin, Ceylon). Integration is usually painless between these languages. It's also highly configurable and can be tuned to virtually any workload. You get the huge benefit of a very mature and common shared infrastructure and tooling environment. Your operations team will thank you for solidifying on a single runtime environment. Java is great. The whole ecosystem is really really solid in general and it's truly a pick what you want platform at this point. The JVM is magical for web applications and services.

lmm 11y ago
Java is great but there are other high-performance options with great languages e.g. Haskell.
- deleted 11y ago
  [deleted]
- bliti 11y ago
  Haskell is less of an option than any of the functional languages that work on the JVM. I like Haskell, it's a language that forces you to challenge your knowledge and assumptions. But it is not in the same level as JVM langs. Maybe once it matures more. Hopefully.
- jcrites 11y ago
  I'm skeptical that any other language will be nearly as easy write, operate, and maintain in production as Java. It's really easy to administrate Java applications. You can connect to the JVM and examine what objects are in the heap, or request a thread dump and see what threads the application has launched and what they're doing. There are rarely any (JVM-level) correctness issues since code is safe and has a simple exception model - JVMs are rock solid and virtually never crash. There are advanced profiling tools available, and simple ones built in. It's easy to deploy applications due to Java's jar and class model. You can inspect a class and see its code as-deployed. Building Java code is simple, so there are rarely any build tooling or reproducibility issues. Java also has excellent tools for logging and metrics emission, like Log4j / Slf4j and utilities like Metrics. These are just a few of the system-level features that are critical in large-scale deployments, and in practice these elements matter quite a lot for managing production apps. The language itself is only part of the story. The Java language has also been improving substantially. Java 1.8 launched a lot of great features, like lambdas, functional interfaces, streams, and other modern elements that give me most of what I expect from a modern language and allow me to write clear and concise code that is statically typed, in the context of really strong IDEs. Java's portability makes it straightforward to develop an application from any platform (not just the server platform you deploy on). IDE support is crucial and frequently overlooked. Automatic code completion, refactoring, and inspection ("show all usages of this method") are essential to working on large code bases together as a team. Java also has style enforcement and static analysis tools like FindBugs, Fortify, CheckStyle, etc. Java's open source community is extremely strong - look at all of the work happening under the Apache umbrella such as Hadoop, Spark, and Hive [1] or Google's umbrella, like Google Guava [2] or the Dataflow SDK [3]. There are excellent concurrency tools like java.util.concurrent, Guava's futures, and Akka. I agree with meddlepal on this one. It's hard to do better than Java for the backend. [1] https://projects-old.apache.org/indexes/language.html#Java https://projects-old.apache.org/indexes/language.html#Java [2] https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/ [3] https://github.com/GoogleCloudPlatform/DataflowJavaSDK https://github.com/GoogleCloudPlatform/DataflowJavaSDK
  - nv-vn 11y ago
    I don't really know how most of these relate to Haskell specifically. For example, you bring up safety and the exception model used in Java, but Haskell puts an even higher priority on safety/correctness than Java does. IDE support may be weaker, but IDEs tend to solve problems very specific to the languages they target, namely Java in this case. Refactoring is seen as much less of a problem, for example, since the lack of side effects lets you move any function to wherever you want in your code without breaking anything and the type system/compiler guide you through the entire process if you mess something up. And besides, pretty much every popular editor or IDE has a Haskell plugin that is easily as good as most of the Java tooling out there.
    - jcrites 11y ago
      These are the kinds of questions I'd be concerned with: Can I easily develop Haskell from any platform (Windows, Mac, Linux) and are good IDEs available on all of them? My team is diverse and I don't want to tell my engineers what platform they have to use for development. Can I meaningfully develop my server software on those platforms and deploy it to another OS (Linux)? I agree that Haskell's type system will catch problems made in refactoring, but it's about avoiding the effort. If I wish to rename a method or a class, I don't want to spend time updating the text manually everywhere that is relevant and working through compiler errors - I just want to say "rename class", "rename method". In large code bases this prohibits people from improving the code over time and doing maintenance work. Are there Haskell IDEs of equivalent quality to Eclipse and IntelliJ? My software development is a lot slower if I need to remember the standard library precisely and type its methods and classes, rather than typing TPE and allowing the IDE to auto-complete it to ThreadPoolExecutor; and it's a lot slower if I can't highlight a method and quickly invoke the IDE command for "show me all methods that call this method", or "show me the implementation of this class / method". I've personally found that this kind of code authoring and navigation assistance has a dominant impact on practical development speed. When I've written a unit test, can I easily select the test in my IDE and run that single test with a keystroke, attaching a debugger if needed? (Maybe Haskell needs fewer unit tests, but for business software I doubt it.) That same test suite will be run by my build system at build time to make sure everything passes. How would I accomplish in Haskell the equivalent of what Metrics helps you solve in Java? https://dropwizard.github.io/metrics/3.1.0/ https://dropwizard.github.io/metrics/3.1.0/ Or Log4j and Slf4j? Managing log messages from large applications is important, since log messages are the primary after-the-fact record of what processing took place. They're often all you have to go on, aside from any metrics you've produced. (I would not buy the idea that Haskell code is so defect-free that these kinds of tools are unnecessary. In any case, Metrics is about performance metrics and business-relevant metrics.) Are there profiling tools comparable to JProfiler? Can I easily get stack traces and heap dumps at runtime? In Java there are great interactive tools to explore these, to inspect every object and its properties and GC state. If the application crashes (not the runtime), is good troubleshooting information available to figure out what went wrong? It's more difficult, though still possible, to attach debuggers to production code and step through, so log messages are a poor man's after-the-fact trace. That said, I can still attach a debugger to a JVM remotely over the network and inspect the threads, heap, etc., and step through code execution. Is it easy to debug (attach a debugger to) a Haskell program as-is over the network in production? How would I write a distributed map/reduce job with Haskell and execute it across a large fleet, like I would with Java using Hadoop, Spark? Are there distributed actor frameworks with the quality of Akka, or messaging systems like Kafka? Are there good RPC libraries for Haskell to interact with other applications written in Apache Avro, Google Protocol Buffers, Cap'n Proto, and so on? The tools I mention are solid, and very widely deployed - they're not obscure. There are a lot of practical large-scale problems that I can solve easily in Java, ones where many other programmers would be familiar with the solution I'd use. If there are good ways to solve these problems then I'd love to learn more. I've always been a fan of the Haskell language and its concepts, as well as F# and Scala. However, despite my wish to use them, I've run into a lot of practical challenges. These extra-linguistic factors involved in running software in production dominate the linguistic ones.
- jbooth 11y ago
  Yes, the installed base of working, high-performance, money-making programs written Haskell is astounding compared to those part-time Java amateurs.
__derek__ 11y ago
In your list of JVM languages, you skipped Clojure, which has the side-benefit of a strong community working on ClojureScript.
edem 11y ago
You forgot to mention Clojure which also has a dialect which compiles to JavaScript (ClojureScript) has excellent tooling (EMACS/Cursive/Leiningen) and has full interoperability with Java.
hackercomplex 11y ago
I couldn't agree more, but I think you should add Clojure to the list. There's also advanced profiling tools available for the JVM platform. For those who do use Rails the Torquebox environment is available http://torquebox.org/ http://torquebox.org/ TorqueBox 4's web server is powered by Undertow. Check out the performance benchmarks: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r9&hw=i7... undertow edge 183,150 requests per second on the JSON benchmark
nv-vn 11y ago
I'm really not a fan of these kinds of blanket statements where you lump everything into "JVM" or "failure". The JVM is a good platform for performance, stability, etc. but it's not the only one. The .NET ecosystem is pretty high up there for performance (and gives you a bit more room for fine tuning) and it easily has some of the best support in the industry (both 1st and 3rd party). And we've all seen success stories with Node.JS, RoR, and all sorts of niche languages that probably wouldn't have happened with a different language (because of factors like needing to get up quick prototypes for startups or just the culture at those specific companies). There's no road that will "set you up for failure," so to speak. In reality, it comes down to what works for your team and your application, and a lot of times there's no clear-cut winner in those cases.
- conventionalmem 11y ago
  Agreed, it's crazy that there are engineers in this world that can make blanket statements like this, especially on a site like HN. There are a lot of great languages/frameworks, and it depends on the needs you have and your team. (I'm so fatigued by this view I hear so regularly expressed in web dev that "X is the solution to everything" - no, it's very rarely the case)
  - lmm 11y ago
    I'm more fatigued by the constant "use the right tool for the job" - impossible to argue with, and utterly useless advice for actually making decisions. Some tools really are better than others, and there is a lot of value in standardizing on a single platform. http://www.teamten.com/lawrence/writings/java-for-everything.html http://www.teamten.com/lawrence/writings/java-for-everything...
    - conventionalmem 11y ago
      Sure, but let's have that debate, and set down a philosophy around that. What you're arguing is not that Java is everything - but that a polyglot stack has dangers, that certain tools are often unobjectably better than others, and that we shouldn't sugar coat that. I agree, as would many of our friends in the space. But if you're saying that everyone who is in Javascript, Ruby, Python, Go, PHP (and others) should all refactor into Java because it's the one and only ideal web backend in 2016 (or design new apps exclusively in Java) - I could pick a 1000 holes in that argument. The original comment I reacted to was: > If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake My apologies if this comes across negatively (which I don't intend, as this is a respectful debate among people who care deeply about their craft) - but I'm just not convinced that you're really a full supporter of the original commenter. Your blog seems to show a fair degree of pragmatism (you consider other languages/frameworks, might use them, are ok if your friends are not using Java). I'm totally fine with "I think the majority of people should use Java" (I don't fully agree with that, but in a world where many people knew that ecosystem, I think it's a great choice) - but the commenter went much further. If s/he is looking to start a debate, then I'm fine; if that person would join any company and religiously uphold that viewpoint, I don't think they'd be the right person for many companies. P.S. If I'm wrong, and if Java is the ecosystem that for the next few years the rules them all, I really want to make a Lord of the Rings-inspired meme about it
seivan 11y ago
Does Kotlin offer anything Rails like with batteries included? I'm steering away from Ruby. I love Rails but ruby becomes a monster when a project gets larger. I've looked at TypeScript and Express.js but I'm worried I gotta deal with type definitions a lot.
- sotojuan 11y ago
  Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.
  - edwinnathaniel 11y ago
    Keep in mind Sails has stagnated and there's a fork called TrailJS now. The NodeJS 3rd-party ecosystem is really really fragile at the moment.
    - sotojuan 11y ago
      Yeah that's what I meant. The Node ecosystem doesn't really care for Rails-like frameworks so they stagnate. Most Ruby companies run Rails. Most Node companies run Express, Hapi, or Koa. Not Sails.
    - traviswebb 11y ago
      For anyone who's interested, the github repo: https://github.com/trailsjs/trails https://github.com/trailsjs/trails
  - seivan 11y ago
    It's rails like through its middleware pipeline design. That's a requirement for me. That allows Express third party middleware to add missing parts like Strong Params and easier HTTP Caching. It would be nice to have batteries included but not at the cost of a giant box still design that I suspect Sails and other have. Pipeline design is important and Express does that really good.
fweespeech 11y ago
> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore. Honestly, unless you are operating on thin margins due to your business structure ... this isn't really an issue. Pretty much anyone with well padded margins that the primary cost is engineering time or product costs [e.g. Physical products to ship] this is a complete non-issue as long as the datastore/service architecture is designed for horizontal scaling. I'm constantly amazed by the tribalism of developers and the delusion that language performance is in any way relevant. The reality is you need to just stick with one language so you can keep your engineering talent, tooling, etc. consistent due to the economies of scale of avoiding duplication of effort [libraries, learning time, tooling, etc]. The gain is in terms of engineering costs, not hardware costs. The language, honestly, just does not matter when we can have a 10 man IT team with ~$50k/year in hardware handling a $100mil/year in business with good margins. It just doesn't even register.
- discreteevent 11y ago
  Good for you that you are in that kind of business. I've never worked on anything where we didn't need more performance in the end. And when you do need it you need it quick. Having an environment and tools (e.g. top class profilers) that make that possible is often the only way to get it done in time.
  - fweespeech 11y ago
    The OP's one-size fits all approach is simply wrong. Simply because it is correct for a subset of organizations does not make it true for all organizations as the OP implied.
SiVal 11y ago
I keep wondering how Java compares to Go these days. I'm not advocating Go, just wondering how much of an advantage Java has for server-side "web applications and services" for new businesses that are the usual small to medium scale with a single-digit number of developers and no legacy vs giant enterprise scale. It just sounds as though the advantages of Java help large, complex systems of services and developers more than they help the vastly more numerous small-med systems. Can someone with experience comment, because I'd like to understand the options a bit better.
- edwinnathaniel 11y ago
  This startup: https://www.kashoo.com/home https://www.kashoo.com/home was built by a husband doing all the tech, and a wife doing the non-tech part. The app was written using Java and GWT. Can the husband roll faster if it was using Rails? probably but not significantly. Another anecdotes: I was part of a team of 3-4 developers delivering a portal solution for British Columbia compensation board (WorksafeBC, http://bit.ly/1QhUH8L http://bit.ly/1QhUH8L NOTE: it's a few pages of PDF to show the size of the app). The thought of Java is slow, not agile, and probably overkill for small team, small project, small this and that is probably not warranted. I've mentioned this in another thread: choose Java and you'll set for at least 5-7 years with minimum problem, focus on solving business problems and less on infrastructure, upgrades of software/libraries, choices of latest du jour). Those open source libraries are damn solid and I very rarely need to worry much whenever I upgrade those libraries. Open the pom.xml, bump up the version number, sit back and enjoy the latest version. Do you want to write a mobile app? 1/2 of the popular platform is already covered with Java so you just have to worry about the other one. I'm having a very very hard time justifying the use of Go for "Web Application". I just can't see the benefit over Java (I'm scoping this to just those 2 platforms). PS: My experience might not reflect other people.
- lmm 11y ago
  Java and Go are pretty similar at the language level, and you're right that the advantages of both are more applicable in large systems. For a small business situation something like Ruby may well be a better choice. Java has a more powerful type system (though still poor by modern standards). Both have weaknesses regarding error handling - Go encourages you to err on the side of repetitive code, Java encourages you to err on the side of handling errors only at very high level, I'm not sure which is worse. Java has a much bigger ecosystem and better tool support, though a lot of it is written for pre-C10K days and assumes a "1 thread per connection/request" model - but frankly for a small business type situation that's fine. The go concurrency model is overkill at the low end and not flexible enough at the high end, but if you're in the sweet spot then you can write code more efficiently there than in Java.
amalag 11y ago
You can do RoR on Jruby. It won't be as performant as staticly typed languages, but it is often good enough. You do lose the benefits of static typing though with refactoring.
xiaoma 11y ago
>"If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore." That sounds like a fantastic problem to have. Airbnb, Teespring, (Rap) Genius, Github and many others have run into it and I don't see how one could wish more for a friend building out a new wep app in 2016. The best part is that if you build quickly and hit scaling problems, you have the resources to invest into making your product performant. The second best part is that if you don't hit scaling problems, at least you haven't wasted time on optimizing something the market didn't want.
swah 11y ago
Some people will always go with lighter systems, see how big Go is getting. And then integrate the subsystems with RPC. That said, Clojure + Java is a sweet combination, they are pretty complementary IMO.

lmm 11y ago

Java is great but there are other high-performance options with great languages e.g. Haskell.

deleted 11y ago
[deleted]
bliti 11y ago
Haskell is less of an option than any of the functional languages that work on the JVM. I like Haskell, it's a language that forces you to challenge your knowledge and assumptions. But it is not in the same level as JVM langs. Maybe once it matures more. Hopefully.
jcrites 11y ago
I'm skeptical that any other language will be nearly as easy write, operate, and maintain in production as Java. It's really easy to administrate Java applications. You can connect to the JVM and examine what objects are in the heap, or request a thread dump and see what threads the application has launched and what they're doing. There are rarely any (JVM-level) correctness issues since code is safe and has a simple exception model - JVMs are rock solid and virtually never crash. There are advanced profiling tools available, and simple ones built in. It's easy to deploy applications due to Java's jar and class model. You can inspect a class and see its code as-deployed. Building Java code is simple, so there are rarely any build tooling or reproducibility issues. Java also has excellent tools for logging and metrics emission, like Log4j / Slf4j and utilities like Metrics. These are just a few of the system-level features that are critical in large-scale deployments, and in practice these elements matter quite a lot for managing production apps. The language itself is only part of the story. The Java language has also been improving substantially. Java 1.8 launched a lot of great features, like lambdas, functional interfaces, streams, and other modern elements that give me most of what I expect from a modern language and allow me to write clear and concise code that is statically typed, in the context of really strong IDEs. Java's portability makes it straightforward to develop an application from any platform (not just the server platform you deploy on). IDE support is crucial and frequently overlooked. Automatic code completion, refactoring, and inspection ("show all usages of this method") are essential to working on large code bases together as a team. Java also has style enforcement and static analysis tools like FindBugs, Fortify, CheckStyle, etc. Java's open source community is extremely strong - look at all of the work happening under the Apache umbrella such as Hadoop, Spark, and Hive [1] or Google's umbrella, like Google Guava [2] or the Dataflow SDK [3]. There are excellent concurrency tools like java.util.concurrent, Guava's futures, and Akka. I agree with meddlepal on this one. It's hard to do better than Java for the backend. [1] https://projects-old.apache.org/indexes/language.html#Java https://projects-old.apache.org/indexes/language.html#Java [2] https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/ [3] https://github.com/GoogleCloudPlatform/DataflowJavaSDK https://github.com/GoogleCloudPlatform/DataflowJavaSDK
- nv-vn 11y ago
  I don't really know how most of these relate to Haskell specifically. For example, you bring up safety and the exception model used in Java, but Haskell puts an even higher priority on safety/correctness than Java does. IDE support may be weaker, but IDEs tend to solve problems very specific to the languages they target, namely Java in this case. Refactoring is seen as much less of a problem, for example, since the lack of side effects lets you move any function to wherever you want in your code without breaking anything and the type system/compiler guide you through the entire process if you mess something up. And besides, pretty much every popular editor or IDE has a Haskell plugin that is easily as good as most of the Java tooling out there.
  - jcrites 11y ago
    These are the kinds of questions I'd be concerned with: Can I easily develop Haskell from any platform (Windows, Mac, Linux) and are good IDEs available on all of them? My team is diverse and I don't want to tell my engineers what platform they have to use for development. Can I meaningfully develop my server software on those platforms and deploy it to another OS (Linux)? I agree that Haskell's type system will catch problems made in refactoring, but it's about avoiding the effort. If I wish to rename a method or a class, I don't want to spend time updating the text manually everywhere that is relevant and working through compiler errors - I just want to say "rename class", "rename method". In large code bases this prohibits people from improving the code over time and doing maintenance work. Are there Haskell IDEs of equivalent quality to Eclipse and IntelliJ? My software development is a lot slower if I need to remember the standard library precisely and type its methods and classes, rather than typing TPE and allowing the IDE to auto-complete it to ThreadPoolExecutor; and it's a lot slower if I can't highlight a method and quickly invoke the IDE command for "show me all methods that call this method", or "show me the implementation of this class / method". I've personally found that this kind of code authoring and navigation assistance has a dominant impact on practical development speed. When I've written a unit test, can I easily select the test in my IDE and run that single test with a keystroke, attaching a debugger if needed? (Maybe Haskell needs fewer unit tests, but for business software I doubt it.) That same test suite will be run by my build system at build time to make sure everything passes. How would I accomplish in Haskell the equivalent of what Metrics helps you solve in Java? https://dropwizard.github.io/metrics/3.1.0/ https://dropwizard.github.io/metrics/3.1.0/ Or Log4j and Slf4j? Managing log messages from large applications is important, since log messages are the primary after-the-fact record of what processing took place. They're often all you have to go on, aside from any metrics you've produced. (I would not buy the idea that Haskell code is so defect-free that these kinds of tools are unnecessary. In any case, Metrics is about performance metrics and business-relevant metrics.) Are there profiling tools comparable to JProfiler? Can I easily get stack traces and heap dumps at runtime? In Java there are great interactive tools to explore these, to inspect every object and its properties and GC state. If the application crashes (not the runtime), is good troubleshooting information available to figure out what went wrong? It's more difficult, though still possible, to attach debuggers to production code and step through, so log messages are a poor man's after-the-fact trace. That said, I can still attach a debugger to a JVM remotely over the network and inspect the threads, heap, etc., and step through code execution. Is it easy to debug (attach a debugger to) a Haskell program as-is over the network in production? How would I write a distributed map/reduce job with Haskell and execute it across a large fleet, like I would with Java using Hadoop, Spark? Are there distributed actor frameworks with the quality of Akka, or messaging systems like Kafka? Are there good RPC libraries for Haskell to interact with other applications written in Apache Avro, Google Protocol Buffers, Cap'n Proto, and so on? The tools I mention are solid, and very widely deployed - they're not obscure. There are a lot of practical large-scale problems that I can solve easily in Java, ones where many other programmers would be familiar with the solution I'd use. If there are good ways to solve these problems then I'd love to learn more. I've always been a fan of the Haskell language and its concepts, as well as F# and Scala. However, despite my wish to use them, I've run into a lot of practical challenges. These extra-linguistic factors involved in running software in production dominate the linguistic ones.
jbooth 11y ago
Yes, the installed base of working, high-performance, money-making programs written Haskell is astounding compared to those part-time Java amateurs.

__derek__ 11y ago

In your list of JVM languages, you skipped Clojure, which has the side-benefit of a strong community working on ClojureScript.

edem 11y ago

You forgot to mention Clojure which also has a dialect which compiles to JavaScript (ClojureScript) has excellent tooling (EMACS/Cursive/Leiningen) and has full interoperability with Java.

hackercomplex 11y ago

I couldn't agree more, but I think you should add Clojure to the list. There's also advanced profiling tools available for the JVM platform. For those who do use Rails the Torquebox environment is available http://torquebox.org/ http://torquebox.org/ TorqueBox 4's web server is powered by Undertow. Check out the performance benchmarks: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r9&hw=i7... undertow edge 183,150 requests per second on the JSON benchmark

nv-vn 11y ago

I'm really not a fan of these kinds of blanket statements where you lump everything into "JVM" or "failure". The JVM is a good platform for performance, stability, etc. but it's not the only one. The .NET ecosystem is pretty high up there for performance (and gives you a bit more room for fine tuning) and it easily has some of the best support in the industry (both 1st and 3rd party). And we've all seen success stories with Node.JS, RoR, and all sorts of niche languages that probably wouldn't have happened with a different language (because of factors like needing to get up quick prototypes for startups or just the culture at those specific companies). There's no road that will "set you up for failure," so to speak. In reality, it comes down to what works for your team and your application, and a lot of times there's no clear-cut winner in those cases.

conventionalmem 11y ago
Agreed, it's crazy that there are engineers in this world that can make blanket statements like this, especially on a site like HN. There are a lot of great languages/frameworks, and it depends on the needs you have and your team. (I'm so fatigued by this view I hear so regularly expressed in web dev that "X is the solution to everything" - no, it's very rarely the case)
- lmm 11y ago
  I'm more fatigued by the constant "use the right tool for the job" - impossible to argue with, and utterly useless advice for actually making decisions. Some tools really are better than others, and there is a lot of value in standardizing on a single platform. http://www.teamten.com/lawrence/writings/java-for-everything.html http://www.teamten.com/lawrence/writings/java-for-everything...
  - conventionalmem 11y ago
    Sure, but let's have that debate, and set down a philosophy around that. What you're arguing is not that Java is everything - but that a polyglot stack has dangers, that certain tools are often unobjectably better than others, and that we shouldn't sugar coat that. I agree, as would many of our friends in the space. But if you're saying that everyone who is in Javascript, Ruby, Python, Go, PHP (and others) should all refactor into Java because it's the one and only ideal web backend in 2016 (or design new apps exclusively in Java) - I could pick a 1000 holes in that argument. The original comment I reacted to was: > If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake My apologies if this comes across negatively (which I don't intend, as this is a respectful debate among people who care deeply about their craft) - but I'm just not convinced that you're really a full supporter of the original commenter. Your blog seems to show a fair degree of pragmatism (you consider other languages/frameworks, might use them, are ok if your friends are not using Java). I'm totally fine with "I think the majority of people should use Java" (I don't fully agree with that, but in a world where many people knew that ecosystem, I think it's a great choice) - but the commenter went much further. If s/he is looking to start a debate, then I'm fine; if that person would join any company and religiously uphold that viewpoint, I don't think they'd be the right person for many companies. P.S. If I'm wrong, and if Java is the ecosystem that for the next few years the rules them all, I really want to make a Lord of the Rings-inspired meme about it

seivan 11y ago

Does Kotlin offer anything Rails like with batteries included? I'm steering away from Ruby. I love Rails but ruby becomes a monster when a project gets larger. I've looked at TypeScript and Express.js but I'm worried I gotta deal with type definitions a lot.

sotojuan 11y ago
Express isn't like Rails. It's more like Sinatra, but has probably even less stuff. There's no official or popular Rails for Node yet. People have made stuff like Sails but not many use it.
- edwinnathaniel 11y ago
  Keep in mind Sails has stagnated and there's a fork called TrailJS now. The NodeJS 3rd-party ecosystem is really really fragile at the moment.
  - sotojuan 11y ago
    Yeah that's what I meant. The Node ecosystem doesn't really care for Rails-like frameworks so they stagnate. Most Ruby companies run Rails. Most Node companies run Express, Hapi, or Koa. Not Sails.
  - traviswebb 11y ago
    For anyone who's interested, the github repo: https://github.com/trailsjs/trails https://github.com/trailsjs/trails
- seivan 11y ago
  It's rails like through its middleware pipeline design. That's a requirement for me. That allows Express third party middleware to add missing parts like Strong Params and easier HTTP Caching. It would be nice to have batteries included but not at the cost of a giant box still design that I suspect Sails and other have. Pipeline design is important and Express does that really good.

fweespeech 11y ago

> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore. Honestly, unless you are operating on thin margins due to your business structure ... this isn't really an issue. Pretty much anyone with well padded margins that the primary cost is engineering time or product costs [e.g. Physical products to ship] this is a complete non-issue as long as the datastore/service architecture is designed for horizontal scaling. I'm constantly amazed by the tribalism of developers and the delusion that language performance is in any way relevant. The reality is you need to just stick with one language so you can keep your engineering talent, tooling, etc. consistent due to the economies of scale of avoiding duplication of effort [libraries, learning time, tooling, etc]. The gain is in terms of engineering costs, not hardware costs. The language, honestly, just does not matter when we can have a 10 man IT team with ~$50k/year in hardware handling a $100mil/year in business with good margins. It just doesn't even register.

discreteevent 11y ago
Good for you that you are in that kind of business. I've never worked on anything where we didn't need more performance in the end. And when you do need it you need it quick. Having an environment and tools (e.g. top class profilers) that make that possible is often the only way to get it done in time.
- fweespeech 11y ago
  The OP's one-size fits all approach is simply wrong. Simply because it is correct for a subset of organizations does not make it true for all organizations as the OP implied.

SiVal 11y ago

I keep wondering how Java compares to Go these days. I'm not advocating Go, just wondering how much of an advantage Java has for server-side "web applications and services" for new businesses that are the usual small to medium scale with a single-digit number of developers and no legacy vs giant enterprise scale. It just sounds as though the advantages of Java help large, complex systems of services and developers more than they help the vastly more numerous small-med systems. Can someone with experience comment, because I'd like to understand the options a bit better.

edwinnathaniel 11y ago
This startup: https://www.kashoo.com/home https://www.kashoo.com/home was built by a husband doing all the tech, and a wife doing the non-tech part. The app was written using Java and GWT. Can the husband roll faster if it was using Rails? probably but not significantly. Another anecdotes: I was part of a team of 3-4 developers delivering a portal solution for British Columbia compensation board (WorksafeBC, http://bit.ly/1QhUH8L http://bit.ly/1QhUH8L NOTE: it's a few pages of PDF to show the size of the app). The thought of Java is slow, not agile, and probably overkill for small team, small project, small this and that is probably not warranted. I've mentioned this in another thread: choose Java and you'll set for at least 5-7 years with minimum problem, focus on solving business problems and less on infrastructure, upgrades of software/libraries, choices of latest du jour). Those open source libraries are damn solid and I very rarely need to worry much whenever I upgrade those libraries. Open the pom.xml, bump up the version number, sit back and enjoy the latest version. Do you want to write a mobile app? 1/2 of the popular platform is already covered with Java so you just have to worry about the other one. I'm having a very very hard time justifying the use of Go for "Web Application". I just can't see the benefit over Java (I'm scoping this to just those 2 platforms). PS: My experience might not reflect other people.
lmm 11y ago
Java and Go are pretty similar at the language level, and you're right that the advantages of both are more applicable in large systems. For a small business situation something like Ruby may well be a better choice. Java has a more powerful type system (though still poor by modern standards). Both have weaknesses regarding error handling - Go encourages you to err on the side of repetitive code, Java encourages you to err on the side of handling errors only at very high level, I'm not sure which is worse. Java has a much bigger ecosystem and better tool support, though a lot of it is written for pre-C10K days and assumes a "1 thread per connection/request" model - but frankly for a small business type situation that's fine. The go concurrency model is overkill at the low end and not flexible enough at the high end, but if you're in the sweet spot then you can write code more efficiently there than in Java.

amalag 11y ago

You can do RoR on Jruby. It won't be as performant as staticly typed languages, but it is often good enough. You do lose the benefits of static typing though with refactoring.

xiaoma 11y ago

>"If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore." That sounds like a fantastic problem to have. Airbnb, Teespring, (Rap) Genius, Github and many others have run into it and I don't see how one could wish more for a friend building out a new wep app in 2016. The best part is that if you build quickly and hit scaling problems, you have the resources to invest into making your product performant. The second best part is that if you don't hit scaling problems, at least you haven't wasted time on optimizing something the market didn't want.

swah 11y ago

Some people will always go with lighter systems, see how big Go is getting. And then integrate the subsystems with RPC. That said, Clojure + Java is a sweet combination, they are pretty complementary IMO.