7 ms·
Completely agree. Say what you will about Java (the language), the JVM is a seriously good piece of kit.
by srazzaque 5y ago
Completely agree.
Say what you will about Java (the language), the JVM is a seriously good piece of kit.
- bognition 5y agoJava is a fantastic language. It's simple and in the right environment can be elegant. It's incredibly easy to ramp up new engineers on it and the tooling thats available make discovery and navigation a breeze. It may lack a lot of the fancier features of some newer languages but its still a very effective language.
- cygned 5y ago> It may lack a lot of the fancier features Coming from JavaScript, TypeScript, Python and Go back to Java I can tell you that’s actually a good thing.
- bognition 5y agoAgree 100%. Let me build stuff using simple easy to understand tools. Cleverness in code starts working against you as a code base and organizations scale.
- throwaway894345 5y agoDoesn’t Java tend to have a lot of cleverness/magic? Pretty crazy runtime codegen, reflection, etc? Spring and other DI frameworks seem overly clever to me, as do many ORMs. I guess my standard for a simple, minimal-magic language is Go.
- bognition 5y agoYes but idiomatic java doesn't require you to use those thing.
- throwaway894345 5y agoWhat does “cleverness” refer to then? Couldn’t I equally argue that idiomatic Python (or any other language) doesn’t require I use cleverness? And if so, what sense is there in praising Java for its lack of cleverness?
- cygned 5y agoThe aspects mentioned (Spring, DI containers, ...) are tool on top, though. If we just look at the language, I'd argue Java is boring - which is a good thing for certain types of applications. In languages like JavaScript, you have a number of ways to do things with all kinds of different syntaxes. In Java, there are fewer, but well understood options, that sometimes require more and sometimes require less actual code to achieve the same thing. This is highly subjective, if course.
- throwaway894345 5y agoOk, I understand your meaning, and I agree that gratuitous syntax sugar is a bummer; however, I've never found it to be particularly problematic. On the other hand, I have found a culture of magic/cleverness and a magical ecosystem to be problematic--this is one of my bigger grievances with Python after a decade and a half of experience.
- cygned 5y agoI am leading a transition from TypeScript to Java + Spring Boot and comparing those side-by-side, Java is significantly easier to follow. In TypeScript, we have a (from my point of view) too complex type system and features like destructuring and spreading, that sound smart but actually make it difficult to understand if you are not the author of the piece in question. What do you find magical in terms of Python in particular?
- throwaway894345 5y agoI can't speak to TS. I'm not sure what "spreading" even refers to, although I've never had a problem with destructuring even though my daily driver languages don't support it. > What do you find magical in terms of Python in particular? Lots of libraries are magical. SQLAlchemy, most of the data science libraries, even the standard library returns different types based on the values of inputs (e.g., open() returns a binary file or a text file depending on the string you pass into it). Additionally, people often go crazy with various dynamic typing features (rather than refactoring into a common interface, people will do a bunch of `if isinstance(...)`es all over the place. Similarly people tend to go crazy with metaclasses and so on. I could go on and on.
- vips7L 5y agoIs DI really being clever? I'd rather work with people who understand DI than a big ball of procedural mud.
- throwaway894345 5y ago"DI" and "DI frameworks" are different things. For example, in Go we inject our dependencies (we assemble our object graph in the main function rather than in thousands of constructors), but we're not using XML/etc and a magical translation layer.
- vips7L 5y agoHow do you maintain a single main function for large projects? I personally don't think @Singleton and @Inject are that magical.
- throwaway894345 5y agoPull the graph construction logic out into helper functions if necessary. Pretty straightforward.
- cygned 5y agoThat DI layer (speaking for Spring) is pretty handy for large projects, though, because I can switch out implementations based on configurations centrally, I can use factories without change of injection patterns, ...
- throwaway894345 5y agoI've heard that, but I don't understand it. Is the idea "I don't have to deal with static typing"? In vanilla Go code I can change out implementations super easily as well (via interfaces, which are less tedious than Java interfaces due to structural subtyping). We can also use factories, but this is precisely the kind of stuff I prefer to avoid except in certain very rare cases ("but with Spring, no one is forcing you to use factories!"--maybe not technically, but if it's idiomatic or otherwise culturally accepted then you can guarantee that your coworkers will reach for them).
- kaba0 5y agoI will choose one “magic” annotation over repeating the same buggy code thousands of times. Not having abstraction is just as bad as too much.
- Thaxll 5y agoAnd yet in Go you don't have NPE that plagues Java code.
- Jach 5y agoThey haven't really been a plague for a while, not like they used to be. A lot of forces are behind it, my top three reasons would be 1) because of the Optional type and Optional mapping makes them easy to avoid in chained calls and is less ugly than a nest of null checks or the equivalent err != nil mess in Go, 2) because of better development practices becoming more common like SOLID and especially https://en.wikipedia.org/wiki/Law_of_Demeter https://en.wikipedia.org/wiki/Law_of_Demeter and 3) because of functional programming styles becoming more widely adopted, with Clojure/Scala/Kotlin showing what's possible on the same JVM.
- throwaway894345 5y ago> less ugly than a nest of null checks or the equivalent err != nil mess in Go "null checks are ugly and error handling is messy" are your opinions, not objective facts. I actually prefer Rust-like enums, but short of that, I think Go's error and nil handling seems quite a lot nicer in practice than Java's `Optional` facilities. Note that these are my opinions, and I'm not posing them as objective facts.
- Jach 5y agoUsing the word "ugly" marks the opinion as inherently subjective.
- throwaway894345 5y ago
- _bohm 5y agoMy experience with Go is that it's quite a bit more stripped back of a language than Java. Could you explain what you mean by this?
- skinkestek 5y agoI love Java but happen to like TypeScript a lot, at least the way we write it. The rest of them I've been enthusiastic about for a few weeks until reality catches up with me and I realize what I am missing out on.
- AmpsterMan 5y agoI find it interesting that you'd lump Go with those languages. Java and Go are my favorite languages to code in for muchof the same reasons.
- thinkharderdev 5y agoYeah, I have my complaints about Java the language (and mostly use Scala myself) but the tooling for Java development is really compelling. Everything just works (IDE, debuggers, etc) and idiomatic Java code tends to be very high performance without a ton of special effort required for performance tuning. And if you do need to do performance tuning, the tooling for metrics and performance tuning is also amazing. One of the most underrated aspects of building on the JVM is that the runtime itself provides a lot of visibility into runtime performance "out of the box". If I do have to debug performance issues, I can just fire up JFR and get a ton of useful metrics about performance bottlenecks with no changes to the actual source code. I can even run JFR on my production workloads and get great visibility into the were the "real world" performance bottlenecks are happening.
- scopendo 5y agoAll I want is named parameters so that I don't need to have N variations of the same method with different signatures, also particularly helpful for understanding boolean parameters.
- bognition 5y agoNamed parameters are great but RequestTypes are better. It lets you roll validation into the request type itself which helps clean up methods a ton
- grumpyprole 5y agoIf Java had anonymous (structural) records, then named arguments could just be a function with a parameter that has a record structural type. It could even be given syntactic sugar, something like: foo{ bar=true, baz=true }
- qsort 5y agoMy main complaint is the treatment of generics and lack of value types, which are actually two sides of the same coin. Another thing I'd like to see is opt-in null safety. The Optional type is a very good mechanism, but when every reference is potentially null, its ability to enhance language safety is limited. Other than that, it has everything I want. And of course, the ecosystem, tooling, etc. is simply the best in class. My personal preference is for ML-style languages, so Java will never be my true love. But as far as languages go, you can do much worse.
- knuthsat 5y agoI think there's work being done on value types in Java. Although this was the case 6+ years ago. I'm surprised they still didn't land into Java.
- papercrane 5y agoJEP 169 is for value objects and JEP 218 is for generics over primitives. As the grandparent comment said they go hand-in-hand. My sense is they're more concerned about getting it right then getting it shipped, as both have been in the works for years.
- qsort 5y agoYeah, it doesn't look like Project Valhalla will land before the next LTS. The original separation of primitive types and reference types was necessary when Java was first released, but it's a deal with the devil. It made everything else much harder than it could have been otherwise. Even then we won't have fully reified generics, but some of the stuff they're doing with type projections is insane. I'm pretty sure it's going to be a game changer.
- native_samples 5y agoUse Kotlin to get null safety (and more), plus the ecosystem and tooling.
- qsort 5y ago
- kaba0 5y agoWhat I especially like about Java that it moves slowly, but when it does, it is a very thought out feature. For example, here’s one on the future of a seemingly trivial feature, string interpolation: https://github.com/openjdk/amber-docs/blob/master/site/design-notes/templated-strings.md https://github.com/openjdk/amber-docs/blob/master/site/desig...
- Thaxll 5y agoJava is anything but simple, all the major framework are heavy duty things behind layers of magic abstraction and un-necessary complexity. Did you worked with Spring, Hibernate / random ORM and all the "enterprise" frameworks?
- bognition 5y agoYeah, Java can be bad, but thats more the old school enterprise frameworks. A lot of newer things in Java are much simpler and easier to use. You can be very successful building out your own framework using things like Guice, Guava, and Dropwizard. It lets you pull in what you want and leave out the things you don't need.
- vips7L 5y agoHelidon, Quarkus, Javalin etc. There's plenty of options if you want to build your framework yourself.
- deleted 5y ago[deleted]
- ohgodplsno 5y agoSo, the libraries that some developers have to use are complex. Not the language itself. Additionally, Spring Boot exists and is lightweight and super easy to understand, jooQ is an ORM/query builder that makes Hibernate look like a toy (and it super simple). Just because Java gets tainted by overengineering doesn't mean the language itself isn't simple.
- thinkharderdev 5y agoYeah, to me that's the most amazing thing about it. That the JVM has become an actual platform on which many languages are able run and get the amazing performance of the runtime. In the gRPC benchmarks the top spot is actually akka-grpc which is mostly written in Scala!
- The_rationalist 5y agoAnd Kotlin give the best of both worlds