8 ms·

Back in the day when I wrote Java for living, it was too common pattern that development is done on OpenJDK until we hit some mysterious problem. The problem th

Back in the day when I wrote Java for living, it was too common pattern that development is done on OpenJDK until we hit some mysterious problem. The problem then disappeared when we switched to Oracle JDK. Other problems are that Java's "everything is an object" and "generics parameters are lost at run time" ideas poison every other language too, and garbage collection never works as intended.

Tainnor 5y ago
In Ruby, everything is an object too (actually even more so than in Java) and in dynamically typed languages, generic type parameters of course don't exist, so I don't understand how those things matter to Clojure or (J)Ruby. Garbage collection pauses may be slow on the JVM, but Java is still miles faster than Ruby (idk about clojure).
- swlkr 5y ago
  clojure on the jvm has much better performance than ruby, but for my small side projects, that doesn’t matter. I guess I was trying to describe the frustration of switching languages and ecosystems while also trying to ship, thought I could do it, but I couldn’t. I suppose I would have had a much better time and stayed in C-land (and gotten much better performance) if I had tried golang instead of clojure.
  - Tainnor 5y ago
    If you have deadlines and can't afford being "bad" at something for a while then, yes, learning new technologies or ecosystems might not be a wise choice. I think that's independent of what those technologies are. I switched to the JVM because I was annoyed enough at the things I had to deal with in Ruby that learning how to do things in a new way was worth it for me in the long run. > I suppose I would have had a much better time and stayed in C-land (and gotten much better performance) if I had tried golang instead of clojure. But Go is a completely different language than Clojure? By what criterion are you deciding which language to focus on? Mostly I'd think that people who choose Clojure do so because they want to use a homoiconic, dynamically typed, functional programming language and not something that looks a lot like a cleaned-up C.
    - swlkr 5y ago
      These days I care less about how the language looks and more about the development/deployment experience, and how much memory it’s going to take on a VPS, since that’s the primary thing driving VPS costs. Ruby (and rails) for web applications is very hard to beat ergonomically. Go also feels this way to me, the development experience is very simple, deployment is even easier than ruby/rack (assuming no docker), and you get the added bonus of using a lot less memory on the server.
- oriolid 5y ago
  To be honest, I don't really understand Ruby either. It's like combination of performance of Python, compatibility of C, transparency of any mystery dependency + build system and yet another syntax on top of it.
  - cyberpunk 5y ago
    Ruby is awesome, but it's insanely powerful. For example: I mean, you can monkeypatch anything (including _Object_) at runtime. You can use this to make 1 + 1 = 3, if you desired, or to add a method to all instances of any class currently instantiated. Want your database to respond to .fuckoff(), no problem.. This kind of stuff is also how rspec (used to?) actually run tests. It's cool, but also pretty insane. irb(main):001:0> class Object irb(main):002:1> def fuckoff irb(main):003:2> "lol" irb(main):004:2> end irb(main):005:1> end => :fuckoff irb(main):006:0> 5.fuckoff => "lol" irb(main):007:0> "Hello World".fuckoff => "lol" irb(main):008:0>
    - ilyash 5y ago
      Next Generation Shell: "hold my beer" F fuckoff(x) "lol" echo(5.fuckoff()) echo("Hello World".fuckoff())
    - Tainnor 5y ago
      Yes, the nice thing is that you can use metaprogramming to create really powerful and readable DSLs. The bad thing is that this is often abused horribly, I blame the Rails ecosystem with its "just add this gem to the Gemfile and it will magically change your application" attitude.
      - smrtinsert 5y ago
        Today's java killer is tomorrow's bad practice
    - oriolid 5y ago
      "I have altered the API, pray that I don't alter it any further"?
pkulak 5y ago
One of Java's weaknesses is that they _didn't_ move to everything is an object. Instead we still have all the primitive types (except unsigned, but that's another topic!) and they autobox to and from their object wrappers. I'm assuming moving to objects was considered and discarded for performance reasons. Now I guess we're getting inline classes soon? Which will solve the performance problem, but only decades later.
- astrange 5y ago
  I think by object he means "reference type" - the only good thing about Java's primitives is that at least it has some value types somewhere! Almost every decision in Java feels like it was chosen to waste memory. Even using less than int size ints is hard, because it makes you write explicit casts everywhere, which doesn't prevent bugs, but then makes overflow wrap silently, which encourages them.
  - oriolid 5y ago
    Yes, "everything is a reference type" describes better what I was thinking. And also, "functions are classes, not objects".
sulam 5y ago
Saying garbage collection never works as intended somehow elides all the very large scale systems built on garbage collected languages including Java. GC is like most things, it has trade offs and you have to understand them to get the best out of it. It’s not impossible to achieve, though.
- oriolid 5y ago
  I have to admit that I have never built a large scale system, but with small to medium scale systems I have always ended up tuning GC parameters and looking for stray references. And of course there is always some piece of code that depends on finalizers to close some resource, so not doing enough GC a problem just as much as doing too much of it. In my current project (C#) there's the additional problem that there are situations where GC just isn't allowed but there are some language features that just create objects behind the scenes without any warning. So yes, it's not impossible to achieve but it's a lot more difficult than dealing with reference counting or C++ smart pointers.
  - Tainnor 5y ago
    > And of course there is always some piece of code that depends on finalizers to close some resource [...] I don't think anyone should use finalizers in Java. It's been deprecated since Java 9 and even before that, it was widely considered a bad practice.
    - oriolid 5y ago
      I don't think anyone should use finalizers in Java either, but it hasn't stopped anyone from doing that.
      - Tainnor 5y ago
        There are footguns in every language. There are certainly more footguns in C, which you're trying to advocate for, if I understand correctly (although I'm really not sure what your point is). FWIW, I haven't ever seen anyone use finalize() in Java. I don't doubt that it happens occasionally, but you can't blame a language for some of its users being incompetent.
voidhorse 5y ago
I used to have similar complaints about Java until I sat down and actually read the JVM and language specs and read some JEPs. The truth is, the Java maintainers have made a lot of good design decisions over the years and they’ve been incredibly careful when it comes to trade offs. Generic erasure for instance, was necessary to prevent major backwards compatibility and break the world problems with the massive existing ecosystem of running java programs. Also it’s not an idea that “poisons” other languages. It’d be pretty uneconomical to preserve generics in the runtime representations of any language—c++ doesn’t do this either and it heterogenous approach (opposed to java’s homogenous approach) has its own set of drawbacks (bloated code size, for instance) In actuality, Java is pretty great and a lot of the pain I experienced using it was not because there was something inherently worse about Java’s design decisions but rather because I had made the (very incorrect) assumption that one could simply port over a lot of the unstated assumptions we make about the semantics of other languages when coding in Java, which isn’t true.
- oriolid 5y ago
  I'm not sure what to answer, except that we live in different realities and in my reality Java is pretty terrible even if a lot of effort has been put into it.
  - Tainnor 5y ago
    Java != JVM. I feel that the two are being confused here (even though this post is literally about another language running on the JVM).
    - oriolid 5y ago
      Java language design decisions affect JVM design, and JVM design affects other languages that run on it. Additionally, it seems that JVM languages justify their existence by FFI to Java, so the Java worldview leaks to other languages that way.
  - voidhorse 5y ago
    Hey, I mean fair enough. I can definitely respect that answer. Mind you I’m not trying to argue that Java should win any awards from an ahistorical perspective, however recognizing that the team had to make decisions in the context of maintaining a solid experience for an already existing large userbase made me appreciate their decisions more. I still wouldn’t choose Java as my favorite or goto language, but it’s not so bad as to warrant some of the disparagement it often receives.

Tainnor 5y ago

In Ruby, everything is an object too (actually even more so than in Java) and in dynamically typed languages, generic type parameters of course don't exist, so I don't understand how those things matter to Clojure or (J)Ruby. Garbage collection pauses may be slow on the JVM, but Java is still miles faster than Ruby (idk about clojure).

swlkr 5y ago
clojure on the jvm has much better performance than ruby, but for my small side projects, that doesn’t matter. I guess I was trying to describe the frustration of switching languages and ecosystems while also trying to ship, thought I could do it, but I couldn’t. I suppose I would have had a much better time and stayed in C-land (and gotten much better performance) if I had tried golang instead of clojure.
- Tainnor 5y ago
  If you have deadlines and can't afford being "bad" at something for a while then, yes, learning new technologies or ecosystems might not be a wise choice. I think that's independent of what those technologies are. I switched to the JVM because I was annoyed enough at the things I had to deal with in Ruby that learning how to do things in a new way was worth it for me in the long run. > I suppose I would have had a much better time and stayed in C-land (and gotten much better performance) if I had tried golang instead of clojure. But Go is a completely different language than Clojure? By what criterion are you deciding which language to focus on? Mostly I'd think that people who choose Clojure do so because they want to use a homoiconic, dynamically typed, functional programming language and not something that looks a lot like a cleaned-up C.
  - swlkr 5y ago
    These days I care less about how the language looks and more about the development/deployment experience, and how much memory it’s going to take on a VPS, since that’s the primary thing driving VPS costs. Ruby (and rails) for web applications is very hard to beat ergonomically. Go also feels this way to me, the development experience is very simple, deployment is even easier than ruby/rack (assuming no docker), and you get the added bonus of using a lot less memory on the server.
oriolid 5y ago
To be honest, I don't really understand Ruby either. It's like combination of performance of Python, compatibility of C, transparency of any mystery dependency + build system and yet another syntax on top of it.
- cyberpunk 5y ago
  Ruby is awesome, but it's insanely powerful. For example: I mean, you can monkeypatch anything (including _Object_) at runtime. You can use this to make 1 + 1 = 3, if you desired, or to add a method to all instances of any class currently instantiated. Want your database to respond to .fuckoff(), no problem.. This kind of stuff is also how rspec (used to?) actually run tests. It's cool, but also pretty insane. irb(main):001:0> class Object irb(main):002:1> def fuckoff irb(main):003:2> "lol" irb(main):004:2> end irb(main):005:1> end => :fuckoff irb(main):006:0> 5.fuckoff => "lol" irb(main):007:0> "Hello World".fuckoff => "lol" irb(main):008:0>
  - ilyash 5y ago
    Next Generation Shell: "hold my beer" F fuckoff(x) "lol" echo(5.fuckoff()) echo("Hello World".fuckoff())
  - Tainnor 5y ago
    Yes, the nice thing is that you can use metaprogramming to create really powerful and readable DSLs. The bad thing is that this is often abused horribly, I blame the Rails ecosystem with its "just add this gem to the Gemfile and it will magically change your application" attitude.
    - smrtinsert 5y ago
      Today's java killer is tomorrow's bad practice
  - oriolid 5y ago
    "I have altered the API, pray that I don't alter it any further"?

pkulak 5y ago

One of Java's weaknesses is that they _didn't_ move to everything is an object. Instead we still have all the primitive types (except unsigned, but that's another topic!) and they autobox to and from their object wrappers. I'm assuming moving to objects was considered and discarded for performance reasons. Now I guess we're getting inline classes soon? Which will solve the performance problem, but only decades later.

astrange 5y ago
I think by object he means "reference type" - the only good thing about Java's primitives is that at least it has some value types somewhere! Almost every decision in Java feels like it was chosen to waste memory. Even using less than int size ints is hard, because it makes you write explicit casts everywhere, which doesn't prevent bugs, but then makes overflow wrap silently, which encourages them.
- oriolid 5y ago
  Yes, "everything is a reference type" describes better what I was thinking. And also, "functions are classes, not objects".

sulam 5y ago

Saying garbage collection never works as intended somehow elides all the very large scale systems built on garbage collected languages including Java. GC is like most things, it has trade offs and you have to understand them to get the best out of it. It’s not impossible to achieve, though.

oriolid 5y ago
I have to admit that I have never built a large scale system, but with small to medium scale systems I have always ended up tuning GC parameters and looking for stray references. And of course there is always some piece of code that depends on finalizers to close some resource, so not doing enough GC a problem just as much as doing too much of it. In my current project (C#) there's the additional problem that there are situations where GC just isn't allowed but there are some language features that just create objects behind the scenes without any warning. So yes, it's not impossible to achieve but it's a lot more difficult than dealing with reference counting or C++ smart pointers.
- Tainnor 5y ago
  > And of course there is always some piece of code that depends on finalizers to close some resource [...] I don't think anyone should use finalizers in Java. It's been deprecated since Java 9 and even before that, it was widely considered a bad practice.
  - oriolid 5y ago
    I don't think anyone should use finalizers in Java either, but it hasn't stopped anyone from doing that.
    - Tainnor 5y ago
      There are footguns in every language. There are certainly more footguns in C, which you're trying to advocate for, if I understand correctly (although I'm really not sure what your point is). FWIW, I haven't ever seen anyone use finalize() in Java. I don't doubt that it happens occasionally, but you can't blame a language for some of its users being incompetent.

voidhorse 5y ago

I used to have similar complaints about Java until I sat down and actually read the JVM and language specs and read some JEPs. The truth is, the Java maintainers have made a lot of good design decisions over the years and they’ve been incredibly careful when it comes to trade offs. Generic erasure for instance, was necessary to prevent major backwards compatibility and break the world problems with the massive existing ecosystem of running java programs. Also it’s not an idea that “poisons” other languages. It’d be pretty uneconomical to preserve generics in the runtime representations of any language—c++ doesn’t do this either and it heterogenous approach (opposed to java’s homogenous approach) has its own set of drawbacks (bloated code size, for instance) In actuality, Java is pretty great and a lot of the pain I experienced using it was not because there was something inherently worse about Java’s design decisions but rather because I had made the (very incorrect) assumption that one could simply port over a lot of the unstated assumptions we make about the semantics of other languages when coding in Java, which isn’t true.

oriolid 5y ago
I'm not sure what to answer, except that we live in different realities and in my reality Java is pretty terrible even if a lot of effort has been put into it.
- Tainnor 5y ago
  Java != JVM. I feel that the two are being confused here (even though this post is literally about another language running on the JVM).
  - oriolid 5y ago
    Java language design decisions affect JVM design, and JVM design affects other languages that run on it. Additionally, it seems that JVM languages justify their existence by FFI to Java, so the Java worldview leaks to other languages that way.
- voidhorse 5y ago
  Hey, I mean fair enough. I can definitely respect that answer. Mind you I’m not trying to argue that Java should win any awards from an ahistorical perspective, however recognizing that the team had to make decisions in the context of maintaining a solid experience for an already existing large userbase made me appreciate their decisions more. I still wouldn’t choose Java as my favorite or goto language, but it’s not so bad as to warrant some of the disparagement it often receives.