5 ms·

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original language... you could even still be faster. Very hard to split apart what is faster because the rewrite got rid of lots of bloat, and what is faster because it is legit faster. Java is legit fast when it is written well. Also very easy to make a bloat fest.

martingxx 10y ago
These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?
- brianwawok 10y ago
  A lot more to an app than MCV framework. I realize dropwizard tries to be the everything for the app, but at the core it is a MVC with some bundled libs.
- nostrademons 10y ago
  Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jackson, or if performance was really a problem, Boon over straight servlets. What framework did your Go rewrite use? The standard libs?
  - sk5t 10y ago
    On first glance the dropwizard test app appears to be doomed to mediocrity via reliance on hibernate. Call me crazy, but I like my dropwizard with Spring DI for (singleton) resource setup, a micro-ORM to get work done, and HikariCP datasources at runtime.
    - imtringued 10y ago
      What's wrong with hibernate? The only thing I can think of is that you're not using "JOIN FETCH entity.relation" when accessing collections and end up with the N+1 select problem but that is because you're using any ORM incorrectly. Entity framework has include and active record has includes which do the same thing. The qt ORM also has something similar. The only ORM I have seen that lacks this critical feature is odb. It doesn't allow setting the fetching strategy on a per query basis. You have to either always use eager loading or lazy loading which basically makes it useless for my purposes.
      - sk5t 10y ago
        Well, for benchmarking the essential framework, which does not mandate any ORM, I would want to use something for data access that takes the question of time spent on type reflection, internal caching, and the like, out of the picture. Hibernate and EMF have their place, but not as part of benchmarking the thing that hosts 'em. Core Dropwizard performance is all about how it uses Jetty, Jackson, and maps requests to resources and operations.
  - hota_mazi 10y ago
    > DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. Any benchmarks to provide in order to support this wild claim?
    - nostrademons 10y ago
      The ones I just linked to above.
  - 10y ago
- lenkite 10y ago
  Use vertx if you want lean REST micro-services. I so wish vertx was part of the standard library. The main advantages that Go has over Java is that the standard library is brilliant - thus obviating the need for folks to create monstrous frameworks (and losing performance) and that Go has better memory utilization because of value types (structs) and because it is AOT compiled. Unfortunately Java JIT as designed by the JVM devs takes a lot of memory. In raw performance, I would still give the edge to Java over Golang though.
fetbaffe 10y ago
Yes, the limitation is rarely the programming language, it is the programmer. Also, when you do the rewrite you have already solved the domain problem that you did not fully understand when implementing it the first time.
- hyperpallium 10y ago
  "Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it. But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage. > deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant
  - jpgvm 10y ago
    Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.
    - fetbaffe 10y ago
      I could use the exact same arguments but for PHP.
      - noir_lord 10y ago
        Which is why I still often use PHP. For my usages its a reasonable language.
      - jpgvm 10y ago
        Not quite, I omited here that it is also statically typed and is a future proof language. Mainly because these are properties already shared with Java. However this is not true of PHP. PHP is a great velocity language, provided you have a small(er) team or are willing to commit to additional controls on how you write your PHP (document types/structure of arguments mainly) to ensure that your PHP code is able to be read quickly by other developers. Personally I prefer Go here because it enforces good readability by default and therefore scales better with team size.
hota_mazi 10y ago
> This is the easy trap to fall into though. Indeed. It's a typical honeymoon phase with very little regards to 1-2-5 years in the future. The cost of having picked to Go will be fully apparent then.
- shard972 10y ago
  I really want to see a comparison of a language like go to something much more in the functional sphere when it comes to maintainability of a large codebase. I really feel like that one of the big issues we as programmers want to get a better handle on but there isn't a lot to go off that isn't based off opinions (which can be hard to validate).
nvarsj 10y ago
You're still limited by the JVM technology, regardless of how you write your app - large heap, and big tail latencies (JVM's GC is designed to be throughput optimised, whereas golang is latency optimised).
- deleted 10y ago
  [deleted]
- dm3 10y ago
  Actually, the new G1 collector deals very well with latency-sensitive workflows. I'd say it's comparable to Go if you adjust your heap size to the working set. You can try running the benchmarks here - https://gitlab.com/gasche/gc-latency-experiment https://gitlab.com/gasche/gc-latency-experiment.
- jerven 10y ago
  Just use one of the other JVM's that have GC that are latency optimised such as Zing from Azul, Metronome from IBM or OpenJDK with Shendoah from RedHat. The power of Java is that there is more than one JVM and that can really save you a lot of money/developer time if the world changes under your ass ;) i.e. had a JVM based graph database, ran it on Hotspot -> big GC pauses, moved to Zing no more pauses. All we needed to do is run a different VM and problem went away (new problem was of course that Zing costs but not much, also now with Shendoah coming for free we could probably have moved to that) With GO you can't do that yet. If your app is not latency, bound but throughput bound there is no place to switch too other that a rewrite. That flexibility of deployment on JVM tech gives us a lot insurance for no costs, until we need it.
ldev 10y ago
Exactly, that's how some not very bright people were tricked into thinking that Node.js is actually fast.
- Zach_the_Lizard 10y ago
  And at work, we're now rewriting all those NodeJS services in Go or Java. We hired some Node maintainer(s) a long time ago, rumor has it, who got us on the Node train.
  - kazagistar 10y ago
    How do you do async in java? While it does have CompletableFutures now, none of the libraries (specifically databard drivers) seem to support it, so I always end up with a blocked thread per request.
    - tynpeddler 10y ago
      Java has had non-blocking IO for some time. https://en.wikipedia.org/wiki/Non-blocking_I/O_(Java) https://en.wikipedia.org/wiki/Non-blocking_I/O_(Java) Unfortunately it seems difficult to use (to me at least), but frameworks like netty are build on top of it to provide incredible performance. However, the fact that Java provides real threading means that a blocking io is not a performance problem if you use the correct patterns.

martingxx 10y ago

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?

brianwawok 10y ago
A lot more to an app than MCV framework. I realize dropwizard tries to be the everything for the app, but at the core it is a MVC with some bundled libs.
nostrademons 10y ago
Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jackson, or if performance was really a problem, Boon over straight servlets. What framework did your Go rewrite use? The standard libs?
- sk5t 10y ago
  On first glance the dropwizard test app appears to be doomed to mediocrity via reliance on hibernate. Call me crazy, but I like my dropwizard with Spring DI for (singleton) resource setup, a micro-ORM to get work done, and HikariCP datasources at runtime.
  - imtringued 10y ago
    What's wrong with hibernate? The only thing I can think of is that you're not using "JOIN FETCH entity.relation" when accessing collections and end up with the N+1 select problem but that is because you're using any ORM incorrectly. Entity framework has include and active record has includes which do the same thing. The qt ORM also has something similar. The only ORM I have seen that lacks this critical feature is odb. It doesn't allow setting the fetching strategy on a per query basis. You have to either always use eager loading or lazy loading which basically makes it useless for my purposes.
    - sk5t 10y ago
      Well, for benchmarking the essential framework, which does not mandate any ORM, I would want to use something for data access that takes the question of time spent on type reflection, internal caching, and the like, out of the picture. Hibernate and EMF have their place, but not as part of benchmarking the thing that hosts 'em. Core Dropwizard performance is all about how it uses Jetty, Jackson, and maps requests to resources and operations.
- hota_mazi 10y ago
  > DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. Any benchmarks to provide in order to support this wild claim?
  - nostrademons 10y ago
    The ones I just linked to above.
- 10y ago
lenkite 10y ago
Use vertx if you want lean REST micro-services. I so wish vertx was part of the standard library. The main advantages that Go has over Java is that the standard library is brilliant - thus obviating the need for folks to create monstrous frameworks (and losing performance) and that Go has better memory utilization because of value types (structs) and because it is AOT compiled. Unfortunately Java JIT as designed by the JVM devs takes a lot of memory. In raw performance, I would still give the edge to Java over Golang though.

fetbaffe 10y ago

Yes, the limitation is rarely the programming language, it is the programmer. Also, when you do the rewrite you have already solved the domain problem that you did not fully understand when implementing it the first time.

hyperpallium 10y ago
"Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it. But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage. > deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant
- jpgvm 10y ago
  Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.
  - fetbaffe 10y ago
    I could use the exact same arguments but for PHP.
    - noir_lord 10y ago
      Which is why I still often use PHP. For my usages its a reasonable language.
    - jpgvm 10y ago
      Not quite, I omited here that it is also statically typed and is a future proof language. Mainly because these are properties already shared with Java. However this is not true of PHP. PHP is a great velocity language, provided you have a small(er) team or are willing to commit to additional controls on how you write your PHP (document types/structure of arguments mainly) to ensure that your PHP code is able to be read quickly by other developers. Personally I prefer Go here because it enforces good readability by default and therefore scales better with team size.

hota_mazi 10y ago

> This is the easy trap to fall into though. Indeed. It's a typical honeymoon phase with very little regards to 1-2-5 years in the future. The cost of having picked to Go will be fully apparent then.

shard972 10y ago
I really want to see a comparison of a language like go to something much more in the functional sphere when it comes to maintainability of a large codebase. I really feel like that one of the big issues we as programmers want to get a better handle on but there isn't a lot to go off that isn't based off opinions (which can be hard to validate).

nvarsj 10y ago

You're still limited by the JVM technology, regardless of how you write your app - large heap, and big tail latencies (JVM's GC is designed to be throughput optimised, whereas golang is latency optimised).

deleted 10y ago
[deleted]
dm3 10y ago
Actually, the new G1 collector deals very well with latency-sensitive workflows. I'd say it's comparable to Go if you adjust your heap size to the working set. You can try running the benchmarks here - https://gitlab.com/gasche/gc-latency-experiment https://gitlab.com/gasche/gc-latency-experiment.
jerven 10y ago
Just use one of the other JVM's that have GC that are latency optimised such as Zing from Azul, Metronome from IBM or OpenJDK with Shendoah from RedHat. The power of Java is that there is more than one JVM and that can really save you a lot of money/developer time if the world changes under your ass ;) i.e. had a JVM based graph database, ran it on Hotspot -> big GC pauses, moved to Zing no more pauses. All we needed to do is run a different VM and problem went away (new problem was of course that Zing costs but not much, also now with Shendoah coming for free we could probably have moved to that) With GO you can't do that yet. If your app is not latency, bound but throughput bound there is no place to switch too other that a rewrite. That flexibility of deployment on JVM tech gives us a lot insurance for no costs, until we need it.

ldev 10y ago

Exactly, that's how some not very bright people were tricked into thinking that Node.js is actually fast.

Zach_the_Lizard 10y ago
And at work, we're now rewriting all those NodeJS services in Go or Java. We hired some Node maintainer(s) a long time ago, rumor has it, who got us on the Node train.
- kazagistar 10y ago
  How do you do async in java? While it does have CompletableFutures now, none of the libraries (specifically databard drivers) seem to support it, so I always end up with a blocked thread per request.
  - tynpeddler 10y ago
    Java has had non-blocking IO for some time. https://en.wikipedia.org/wiki/Non-blocking_I/O_(Java) https://en.wikipedia.org/wiki/Non-blocking_I/O_(Java) Unfortunately it seems difficult to use (to me at least), but frameworks like netty are build on top of it to provide incredible performance. However, the fact that Java provides real threading means that a blocking io is not a performance problem if you use the correct patterns.