5 ms·

> But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff. Fast is a poor word to talk about ben

> But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff. Fast is a poor word to talk about benchmarks between languages. Memory, throughput, latency are the things we should be talking about. There’s also trade offs where predictable scaling of latency under massive load is important (Erlang, Elxir), or spending less memory and starting up quickly in order to scale horizontally is important (Golang), or speed of development is important (PHP, Python), or correctness is important (Haskell, Rust). Java is rarely the winner in any area in favor of being well rounded, but as we should be using tools that meet at least the broad requirements it is always possible to make a better choice than Java. > I’ve seen apps run for years straight. This is why Java is dated. I am an Erlang developer, which is known for being hot reloadable and running forever. It turns out this model is actually juxitposed to Kubernetes and severless, which both presuppose letting processed crash at the host level and starting and stopping quickly. This also gets into the tooling argument because profiling in Java would rather the VM be long lived. > The tooling. I too have an operating system with great tooling, it’s called Linux. My knowledge of tooling is more broadly applicable, I can introspect any binary and attach probes to the kernel with bpf. Profiling for a VM is table stakes because you’re on your own. Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host. > Java OO is fine. OO in general is not fine.

meddlepal 8y ago
> OO in general is not fine. I smell a zealot or a troll.
- ilovecaching 8y ago
  Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code and state, which requires explicit knowledge of the intervals of the parent. It’s a code pasting tool. As OO tries to model arbitrary patterns in nature it’s also difficult to reason about the graph of objects apposed to the linear flow of data in FP. Pretty much all of the OO languages are walking back OO features at this point and trying to add type classes (contracts) or functional pieces, mapping and filtering a la linear data transformations.
  - blattimwind 8y ago
    These are actually all fairly common problems so I'm not sure why this is drowned out in gray...
    - Cyph0n 8y ago
      The over-zealous tone may annoy some people. Also, he/she could have gotten the same point across more effectively without implying that Erlang and FP magically solve all problems.
  - spricket 8y ago
    I actually agree with you here that OO is overused. Java has added quite a bit of FP in recent years though. Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it. FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too
  - Scarbutt 8y ago
    True, class inheritance is so hard to get right that is just better to avoid it. Lots of coupling and spaghetti code because of this, but to be fair, you also see this on other languages, like python, php and even JS.
  - int_19h 8y ago
    > It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language. > Pretty much all of the OO languages are walking back OO features About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually. > and trying to add type classes (contracts) In most OO languages, these typically naturally evolve out of interfaces. > functional pieces, mapping and filtering a la linear data transformations. This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.
Scarbutt 8y ago
Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host. Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..
- ilovecaching 8y ago
  It’s a spectrum. Java is at the very end with Erlang. I have a lot of domain specific knowledge of The Beam. Go on the other hand has a very lightweight runtime.
  - spricket 8y ago
    Very true. Newer languages seem to be moving back towards native binaries. The promised advantages of JIT compilation have faded with improvements to compilers and profile driven optimization. Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes
spricket 8y ago
Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go. IMO Java is the most well rounded language, but I'm not trying to convince you of that. Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework. Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#
- ilovecaching 8y ago
  Can do higher concurrency is a nonsensical phrase. Please show me your benchmarks versus Erlang at 10M web socket connections. You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices. You’re not understanding what I told you.
  - spricket 8y ago
    Newer versions of Java cache compiled classes. The startup time is maybe 10 seconds for something big running Java 11. You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal. And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general. Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though
  - gerbilly 8y ago
    If you want to build systems at scale you want to use a lot of commodity boxes, not a few huge or 'special' machines. I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs. Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about. You might chose Java because: * It is well understood and has a lot of mature libraries surrounding it. * You can easily hire people to work on it. * It is a stable language. And so on... I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow. [1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.

meddlepal 8y ago

> OO in general is not fine. I smell a zealot or a troll.

ilovecaching 8y ago
Please elaborate on how OO is fine. OO hides state, which makes reasoning about cache, and therefore performance very difficult, which is why most game programers take a data oriented approach. It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Inheritance isn’t an abstraction because you inherit both code and state, which requires explicit knowledge of the intervals of the parent. It’s a code pasting tool. As OO tries to model arbitrary patterns in nature it’s also difficult to reason about the graph of objects apposed to the linear flow of data in FP. Pretty much all of the OO languages are walking back OO features at this point and trying to add type classes (contracts) or functional pieces, mapping and filtering a la linear data transformations.
- blattimwind 8y ago
  These are actually all fairly common problems so I'm not sure why this is drowned out in gray...
  - Cyph0n 8y ago
    The over-zealous tone may annoy some people. Also, he/she could have gotten the same point across more effectively without implying that Erlang and FP magically solve all problems.
- spricket 8y ago
  I actually agree with you here that OO is overused. Java has added quite a bit of FP in recent years though. Lombok makes immutable data classes trivial. Improved interface support for default methods make it possible to largely ignore OO if you don't want it. FP is mostly a community effort at this point, but solid. Java Streams are decent for basic stuff like map/filter but RXJava is extremely powerful if you want the complexity it comes with. Vavr is nice for adding more FP types too
- Scarbutt 8y ago
  True, class inheritance is so hard to get right that is just better to avoid it. Lots of coupling and spaghetti code because of this, but to be fair, you also see this on other languages, like python, php and even JS.
- int_19h 8y ago
  > It hides state but gains none of the advantages of Erlang because all of the implementations forgot to make state only mutable through explicit message passing. Smalltalk is exactly like that - other objects' state is only mutable through explicit message passing. It's also widely considered the penultimate pure OO language. > Pretty much all of the OO languages are walking back OO features About the only feature I can think of for which this is somewhat true is inheritance, and that's because we realized that aggregation is often a better model, and can be easily supported by the language to be no more verbose. But it doesn't fundamentally change OO - it was never about inheritance first and foremost; I mean, prototype-based OO doesn't even have that conceptually. > and trying to add type classes (contracts) In most OO languages, these typically naturally evolve out of interfaces. > functional pieces, mapping and filtering a la linear data transformations. This is not contradictory to OO in any way. Again, Smalltalk has had "select" (filter) and "collect" (map) from the get go.

Scarbutt 8y ago

Not only do you have to figure out what’s going on in the JVM you also need to duplicate your effort to figure out how the JVM is running on the host. Isn't that true for all other languages you mentioned? python, erlang, php, golang bundles a runtime, etc..

ilovecaching 8y ago
It’s a spectrum. Java is at the very end with Erlang. I have a lot of domain specific knowledge of The Beam. Go on the other hand has a very lightweight runtime.
- spricket 8y ago
  Very true. Newer languages seem to be moving back towards native binaries. The promised advantages of JIT compilation have faded with improvements to compilers and profile driven optimization. Go and Rust are interesting to follow. A highish and low level language both using lightweight runtimes

spricket 8y ago

Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go. IMO Java is the most well rounded language, but I'm not trying to convince you of that. Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework. Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#

ilovecaching 8y ago
Can do higher concurrency is a nonsensical phrase. Please show me your benchmarks versus Erlang at 10M web socket connections. You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices. You’re not understanding what I told you.
- spricket 8y ago
  Newer versions of Java cache compiled classes. The startup time is maybe 10 seconds for something big running Java 11. You can also compile AOT for some performance loss at runtime but zero startup time. Android has been doing this forever but you can also do it on a PC using Graal. And yes Java will destroy Erlang at concurrent connections if you use an async framework like Vert.X or fibers using Quasar/Comsat. It has lower per thread overhead than Erlang and runs code faster in general. Both Java and Erlang will max out Linux TCP connections before running out of steam so this is kinda academic though
- gerbilly 8y ago
  If you want to build systems at scale you want to use a lot of commodity boxes, not a few huge or 'special' machines. I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs. Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about. You might chose Java because: * It is well understood and has a lot of mature libraries surrounding it. * You can easily hire people to work on it. * It is a stable language. And so on... I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow. [1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.