5 ms·

The downside is that also means a lot of the core APIs are a huge pain in the ass to work with, especially relative to something like Python, and the “solution”

by jrs95 7y ago

The downside is that also means a lot of the core APIs are a huge pain in the ass to work with, especially relative to something like Python, and the “solution” to this problem ends up being something like Spring which has to use so much reflection and metaprogramming to accomplish what it does that it also relies heavily on exceptions for control flow. So without even getting into the other issues, debugging becomes a lot more complicated than it would be otherwise. Personally I would second Go as a good answer for this. It has its limitations, but it’s simplicity and it’s standard library more than make up for that from a pragmatic standpoint imo

nine_k 7y ago
Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. You can't have it both ways, OTOH current JVM can still correctly run bytecode compiled by Java 1.0.1 (or maybe even earlier), so the backwards compatibility is indeed excellent.
- mcny 7y ago
  I am not a go programmer but I would love to revisit this conversation but with golang twenty years from now. Please correct me if I am wrong but I believe golang is essentially complete, right? and golang programmers like golang?
  - Alupis 7y ago
    > Please correct me if I am wrong but I believe golang is essentially complete, right I'm confident every programming language thought it was complete at some point... but eventually it's users demand some new "hot" feature and then you're back to releasing new versions again. The C programming language just had a release in June 2018, C18. For a language released 47 years ago... and it's a pretty basic language compared to most other languages. Fortran was released 62 years ago, and just released Fortran 2018 in November of 2018.
  - mongol 7y ago
    Go is not complete. But it does not evolve by revolution as of now.
    - Insanity 7y ago
      Complete is hard to define, no language stops evolving. But Go language is perfectly suitable for large projects, and is pretty much my Go-to nowadays. (Pun intended)
- vbezhenar 7y ago
  Not necessarily. Java currently ships two date libraries, for example: java.util.Date and java.time.*. There are some duplicating classes like Vector from the old times and ArrayList from new times. There are two I/O frameworks: old I/O (File, FileInputStream, etc) and nio (Path, FileSystem, etc). While I don't like the particular way Java did that, basically you just have to ship all old versions and keep them working and ship new versions with some adapters to ease migration.
- dragonwriter 7y ago
  > Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. > You can't have it both ways, You can have a continuously improving platform with full backward compatibility, and all the improvements that aren't just efficiency of established operations are opt-in.
Alupis 7y ago
If you're using something like Spring or Spring-Boot (highly recommended!!!) - you rarely, if ever, are going to be debugging Spring's code... any issues are going to be in your code. With Spring-Boot you can even start treating Spring and friends like a "Black Box", and stop caring about how it does what it does.
- crtlaltdel 7y ago
  personally i loath blackbox systems, regardless of how well the docs are written. i want to know how it does things...even if only to satisfy my curiosity.
  - Alupis 7y ago
    It's not blackbox in that you can't look inside... it's blackbox in that you can choose to ignore it and be just fine. Springboot takes an opinionated approach to a lot of things, but always lets you override it and do whatever you want wherever you want. I suppose that's more of a greybox...
    - crtlaltdel 7y ago
      ah, yes! point taken.
  - vbezhenar 7y ago
    You can use Spring without all that magic. I, personally, hate Spring Boot and would never use it, exactly because of all that magic. But Spring itself is perfectly fine and I can control every single bit of it with explicit configurations.
    - neeleshs 7y ago
      For us, springboot gave about 90% of what we wanted out of the box. The 10% that we wanted customized (special authentication related things or transparent multitenant database switching with repositories etc), it let us override and do what we wanted it to do. It certainly is a lot of magic, but nothing that cannot be deduced if you are familiar with Spring, and/or look at the source.
matwood 7y ago
Java 8+ is so easy to work with I think it bores a lot of people so they go looking for something more. Spring boot + jooq is easy to work with and breaking changes are slow. I'm also coming around on Go. The simplicity was a turn off at first, but now that I've used it to implement a graphql server I like the simplicity. I don't want to have to be a programming language researcher to quickly get work done. IMO Go delivers in that mission.
- betaby 7y ago
  Java is paid platform without clear pricing, licensing and patents.
  - Discombulator 7y ago
    Many (most) JDK distributions are free for all usages and fully open source. Can you give some references for the patents issue you mentioned?
    - betaby 7y ago
      So you agreed pricing and licensing is not clear? If still not, here is the source https://upperedge.com/knowledge-center/documents/oracle-podcasts/podcast-changes-to-oracle-java-licensing-in-2019/ https://upperedge.com/knowledge-center/documents/oracle-podc... As for the patents I don't have a source quickly available. Pricing and licensing are already bad enough. If I sell java based software, customers have to worry about licensing from Oracle. If I sell SaS I have to worry for what and how to pay. Those factors are big risks.

by jrs95 7y ago

nine_k 7y ago

Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. You can't have it both ways, OTOH current JVM can still correctly run bytecode compiled by Java 1.0.1 (or maybe even earlier), so the backwards compatibility is indeed excellent.

mcny 7y ago
I am not a go programmer but I would love to revisit this conversation but with golang twenty years from now. Please correct me if I am wrong but I believe golang is essentially complete, right? and golang programmers like golang?
- Alupis 7y ago
  > Please correct me if I am wrong but I believe golang is essentially complete, right I'm confident every programming language thought it was complete at some point... but eventually it's users demand some new "hot" feature and then you're back to releasing new versions again. The C programming language just had a release in June 2018, C18. For a language released 47 years ago... and it's a pretty basic language compared to most other languages. Fortran was released 62 years ago, and just released Fortran 2018 in November of 2018.
- mongol 7y ago
  Go is not complete. But it does not evolve by revolution as of now.
  - Insanity 7y ago
    Complete is hard to define, no language stops evolving. But Go language is perfectly suitable for large projects, and is pretty much my Go-to nowadays. (Pun intended)
vbezhenar 7y ago
Not necessarily. Java currently ships two date libraries, for example: java.util.Date and java.time.*. There are some duplicating classes like Vector from the old times and ArrayList from new times. There are two I/O frameworks: old I/O (File, FileInputStream, etc) and nio (Path, FileSystem, etc). While I don't like the particular way Java did that, basically you just have to ship all old versions and keep them working and ship new versions with some adapters to ease migration.
dragonwriter 7y ago
> Either you have a stable platform, and it reflects the state of the art form the year of its inception, or you have a platform that keeps on improving, but this means you need to change your code along with it, to keep up with the improvements. > You can't have it both ways, You can have a continuously improving platform with full backward compatibility, and all the improvements that aren't just efficiency of established operations are opt-in.

Alupis 7y ago

If you're using something like Spring or Spring-Boot (highly recommended!!!) - you rarely, if ever, are going to be debugging Spring's code... any issues are going to be in your code. With Spring-Boot you can even start treating Spring and friends like a "Black Box", and stop caring about how it does what it does.

crtlaltdel 7y ago
personally i loath blackbox systems, regardless of how well the docs are written. i want to know how it does things...even if only to satisfy my curiosity.
- Alupis 7y ago
  It's not blackbox in that you can't look inside... it's blackbox in that you can choose to ignore it and be just fine. Springboot takes an opinionated approach to a lot of things, but always lets you override it and do whatever you want wherever you want. I suppose that's more of a greybox...
  - crtlaltdel 7y ago
    ah, yes! point taken.
- vbezhenar 7y ago
  You can use Spring without all that magic. I, personally, hate Spring Boot and would never use it, exactly because of all that magic. But Spring itself is perfectly fine and I can control every single bit of it with explicit configurations.
  - neeleshs 7y ago
    For us, springboot gave about 90% of what we wanted out of the box. The 10% that we wanted customized (special authentication related things or transparent multitenant database switching with repositories etc), it let us override and do what we wanted it to do. It certainly is a lot of magic, but nothing that cannot be deduced if you are familiar with Spring, and/or look at the source.

matwood 7y ago

Java 8+ is so easy to work with I think it bores a lot of people so they go looking for something more. Spring boot + jooq is easy to work with and breaking changes are slow. I'm also coming around on Go. The simplicity was a turn off at first, but now that I've used it to implement a graphql server I like the simplicity. I don't want to have to be a programming language researcher to quickly get work done. IMO Go delivers in that mission.

betaby 7y ago
Java is paid platform without clear pricing, licensing and patents.
- Discombulator 7y ago
  Many (most) JDK distributions are free for all usages and fully open source. Can you give some references for the patents issue you mentioned?
  - betaby 7y ago
    So you agreed pricing and licensing is not clear? If still not, here is the source https://upperedge.com/knowledge-center/documents/oracle-podcasts/podcast-changes-to-oracle-java-licensing-in-2019/ https://upperedge.com/knowledge-center/documents/oracle-podc... As for the patents I don't have a source quickly available. Pricing and licensing are already bad enough. If I sell java based software, customers have to worry about licensing from Oracle. If I sell SaS I have to worry for what and how to pay. Those factors are big risks.