5 ms·

What always strikes me about posts like this is the lack of introspection: why did younger developers reject Java? It’s easy to say “because they’re hipsters f

What always strikes me about posts like this is the lack of introspection: why did younger developers reject Java? It’s easy to say “because they’re hipsters following trends” but I dipped my toe in the Java world years ago and found it immensely frustrating. Eclipse was awful compared to the lightweight editors I was using at the time. The language got in my way more often than it helped me. I’m sure that’s not the case these days (indeed I’ve done a little Android-adjacent stuff and found it to be fine) but the idea that there were no downsides to Java at the time strikes me as unlikely.

jfengel 2y ago
The design of Java is focused on code maintenance. That's exactly what young developers lack experience in. They know how to write greenfield code, by themselves. They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?" Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later. Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.
- jen20 2y ago
  > But the reason it's still around is that it's core principles are oriented to code that sticks around. You could equally say this of COBOL. > They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?" Ironically, "what they hell were they thinking" is exactly the reaction I have to even Greenfield code written using Spring Boot or any of the other annotation driven nonsense. The idea that programs written in Java are more maintainable than programs written in (say) Go, where you can read what the program does end-to-end instead of having to guess at what garbage has been generated by Lombok or overridden by some random JAR on the class path is bizarre. Let's not even talk about Gradle.
  - jfengel 2y ago
    Yeah, I'll defend Java, but I won't defend Spring. I have no idea what they were thinking. A lot of external Java framework is about inversion of control. It looks good on PowerPoint slides, but I think it's horrific to maintain (as well has hard to write). Inversion of control means you have no control, and the most common error case is "why didn't my code run?" But you can't use a debugger to tell you what didn't happen. Any breakpoints have to be set inside the framework code, which is open source but is not intended for your eyes.
    - abraxas 2y ago
      Yeah, spring was and still is, an abomination. Spring boot also. But it's not a requirement even if many Java projects fell into that trap.
  - sorokod 2y ago
    My opinion is that Spring usage should be minimised as much as possible but it is a matter of fact that Spring is not Java.
    - jen20 2y ago
      Spring may not be Java (The Language), but it absolutely is Java (The Ecosystem).
    - wiseowise 2y ago
      It is mainstream Java, though.
      - sorokod 2y ago
        Yes, it (Spring) is. However its current scope creates more problems then it solves.
  - pjmlp 2y ago
    //go:generate Yep no magic... Have you ever read Kubernetes source code?
- hot_gril 2y ago
  I have experience with code maintenance. The only upside of Java is that it's faster than JS or Python. It's otherwise a worse language and ecosystem, and it was even worse before it had lambdas.
  - hot_gril 2y ago
    Actually... if it's for a web backend, NodeJS might be faster in practice.
- nouveaux 2y ago
  Java was so bad that Android took a hard pivot to Kotlin. If anyone understands the importance of code maintenance, it's Google. They built a language for it (Go). I think it's ok to look at historical Java for what it is and learn from it's mistakes. Modern Java is better. Unfortunately, it's developed a bad rap, and it looks like it's in a decline. Fortunately we have Kotlin, Go, Typescript, etc.
- wink 2y ago
  It's a very one-dimensional view. My problems with Java are startup time and memory consumption (and NPEs). If that's not your problem - fine. But writing web apps in the Java ecosystem has been terrible for many of the most important years (let's say 2005 to 2015) and that's where all the "young people" forsake it for... PHP, Rails, node.js. (You can already guess that I'm not even counting myself as part of the younger generation here. I'd used used Java and the JVM intermittently between 2000 and 2020 but it has never been my favourite stack).
javajosh 2y ago
But the comment you're replying to doesn't say Java doesn't have any downsides. It just says that Java has a great story for doing shared types between client and server, which is true. It's also true that Java as a language has gotten a lot better over time. This is I think thanks to pressure from other languages written for the jvm like kotlin, And also developer feedback for those who work in other languages like JavaScript. Java is old and boring. Just like go is new and boring. Rust has plenty of downsides this idea that it's easy to use. Seems wrong to me. The borrow checker is famously difficult to work with despite being a central feature of the language. The really big upside to JavaScript is that it's the native language of browsers and so in a weird way. If you want to get closest to the metal so to speak, JavaScript is a better option for most deployed applications. It's interesting to note that the op's article mostly points to build tools that are written in rust rather than applications and I think that's telling.
- ludwik 2y ago
  > But the comment you're replying to doesn't say Java doesn't have any downsides Yet it blames "hipsters" for throwing "it all in the garbage," implying that there was no rational reason for people to switch away from Java. Naturally, people respond by sharing their reasons.
abraxas 2y ago
It had a steeper learning curve than other languages or environments but that was for a reason. You got a lot in return. And those lightweight editors and environments are like that because they don't do very much. And talk not to me about lightweight. I'm currently on Day 4 of setting up a Python environment in VsCode that doesn't suck. I'm nearly there though it's still a bit inferior to a 20 year old JBuilder install for Java but I guess it needs a few more years to get there. Oh and as I said, I'm on a long quest here to pave the road for my devs but it looks like this hodgepodge of extensions still won't deliver the experience I had decades ago.
- MrMcCall 2y ago
  Isn't using VsCode for a non-Microsoft language going to be difficult, by (MS's) design? I'm not saying it can't/hasn't be/been done, but I doubt MS are making it easier to do so. It's been their m.o. for a long time now. I'm also not saying there's a better option for you and your team, either, my friend. As a python programmer using bare-bones vim (on purpose), having abandoned all fancy IDEs, I really wouldn't know where the state of the art is, anyway, but I doubt the MS leopard has changed its spots.
  - surfaceofthesun 2y ago
    This feels true for other Microsoft products, but not VSCode. Besides, they embedded Python into Excel (for 365 users) over Typescript or C#.
    - MrMcCall 2y ago
      Interesting. Embrace & extend complete ;-) This time it looks like 'integrate' will be the third step. Thanks for the great info.
  - dagw 2y ago
    Isn't using VsCode for a non-Microsoft language going to be difficult Python is pretty close to a 'Microsoft language' these days. They've hired several Python core developers to make sure windows is first class citizen for python and the developing python on windows and with VSCode is as good an experience as possible. They also develop the official VS Code Python extension and language server as well as many other python tools and extensions. I'd say the current state-of-the-art is either VSCode with the Microsoft python extensions or Jetbrain's PyCharm. Personally I slightly prefer PyCharm Pro, but it's pretty much a toss up.
maccard 2y ago
Java is verbose, is a resource hog, requires runtime management for basic app performance, the major frameworks (used to) require an awful lot of boiler plate, the developer tooling almost necessitates an IDE which 10-15 years ago meant eclipse which was slow, bloated, and unstable. There’s also always been licensing “fun” with oracle, sun, and the jdk.
- watwut 2y ago
  What are you talking about, seriously. 10-15 years ago, eclipse was neither slow nor unstable. It worked perfectly well. IntelliJ was not slow or unstable. There were not real major licensing issues. As a newcommer to javascript, I was able to learn faster and produce same quality faster then non-IDE developers. Not because I would be smarter or more talented, but because I had no emotional need to prove myself by not using ide.
  - ludwik 2y ago
    > What are you talking about, seriously It's probably unavoidable that people's memories will differ, but personally, as someone who worked with Java 10–15 years ago and then ran away as fast as he could, these are the things I remember most: the IDEs being awfully slow and unstable (though quite powerful for their time) and the language/ecosystem being painfully verbose and full of boilerplate and layers of indirection. I remember how, after switching away from Java, I felt elated by how easy and maintainable things could be when I was allowed to use simple, fast tools and write straightforward code that just did what it was supposed to do.
  - maccard 2y ago
    Eclipse was _the_ tool when I was working with Java at the time. Slow and unstable is definitely my lasting memory, compared to virtual studio 2008/2010 which was fast and powerful. > there were not real licensing issues Oh yes there were. Even in 2024 the “which JDK are you running on” debate still goes on. There are notable differences between corretto and openjdk, and openjdk and Oracle JDK. Here [0] is a stack overflow question that notes it was asked 10 years ago that talks about the various JDKs and the license change where oracle started charging for JDK access. As for your point about IDE’s vs non-IDE’s that’s a straw man. I said that you were forced to used an IDE for Java (which is of course not technically true but compared to rails which took of at that time it is), but also that the IDE du jour (eclipse) was pretty monstrous. I’ve said this on here before but the minute maven gets introduced into a project build times are measured in minutes. My current work project is c# and I can run my entire test suite faster than the jvm got itself up and running on my last kotlin project. Even IntelliJ and co suffer from these limitations - manually bumping the memory limits for IntelliJ and friends in 2024 is practically a requirement, and the startup times are very Java inspired. [0] https://stackoverflow.com/questions/22358071/differences-between-oracle-jdk-and-openjdk https://stackoverflow.com/questions/22358071/differences-bet...
watwut 2y ago
In my experience, young people who hated java never worked in java and knew nothing about it except that it is evil. The second thing however is that fronted is better off in non-java languages, you can afford to do small backend in typescript and what not. And larger enterprise projects were done in java the whole time.
littlestymaar 2y ago
Exactly! I got my first job in Java after a few years as hobbyist programmer in other languages (mostly PHP and JavaScript but a few others too) and what struck me was that the tooling was both mandatory and painful to use. I wasn't fond of JavaScript (In particular, I never liked dynamic typing), but when I had the opportunity to work in node.js instead of Java I took it immediately, just to avoid the pain and suffering that the Java toolchain inflicted on me.
- FeloniousHam 2y ago
  Java is a language of bondage and discpline. And architectures. And myriad pointless interface definitions. And overblown class hierarchies for problems ill-suited to the OO paradigm. I started my career in Java, and worked in it for 20 years before I really started using Javascript in anger. I didn't (and don't) like Javascript, but the freedom for prototyping was a revelation. When Typescript appeared, I fell in love.
cosmic_cheese 2y ago
At least from an Android point of view, the JVM world still has its share of frustrations and lack of polish/QoL relative to other software development spheres. Gradle has me pulling my hair out multiple times each year for example, and yet for some reason nobody sees it fit to replace it with something less ridiculously complex and prone to error (user or otherwise).
- abraxas 2y ago
  Yeah, gradle/maven was a mistake that happened along with most "app store" style 3d party library slingers. I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty
  - pjmlp 2y ago
    As long as you don't get to debug such builds.... As someone that was writing Ant scripts when CruiseControl was modern, and there was no Ivy in sight, not sure if it was such a better place. I hated Maven at the beggining, exactly because we got some hipster company pushing for it during Maven early days, it was still hot out of the oven. 20 years later, I don't see a reason to use anything else other than Maven.
- mike_hearn 2y ago
  Jetbrains have a project to try and replace Gradle. I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first. Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
  - pjmlp 2y ago
darthrupert 2y ago
Yup. As an older programmer I can say that there were indeed very good reasons back then to stop using Java. Mostly related to JVM but also the language lacked lots of features. Java today looks like a fine platform, though.
bitwize 2y ago
Speaking as a younger developer at the time, Java just seemed weak compared to my favorites -- Common Lisp and Scheme. It lacked a proper procedural abstraction and forced you to do everything through classes and objects in a way that not even Smalltalk, having blocks, demanded. This was especially the case when it became an enterprise language and the standard development process involved lots of boilerplate. Also, a lot of kids came out of school knowing almost only Java, and it seems they were cut off from different worlds of development which could provide some insights. Even C++, which I loathed, had things to teach. I've grown up a bit since then, and so has Java. These days I work in Java for my day job, and it's perfectly fine. I don't even mind all the boilerplate, I can look at a page of code and just see blonde, brunette, redhead. But I still love Common Lisp and Scheme much more.
cratermoon 2y ago
> The language got in my way more often than it helped me Got in the way how? By insisting that things have types and one cannot blindly add an object to an array [] + {} and expect it to behave? Never mind that in Javascript adding an array to an object {} + [] gives a different result. ETA: for bonus points, what does {} + {} return?

jfengel 2y ago

The design of Java is focused on code maintenance. That's exactly what young developers lack experience in. They know how to write greenfield code, by themselves. They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?" Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later. Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.

jen20 2y ago
> But the reason it's still around is that it's core principles are oriented to code that sticks around. You could equally say this of COBOL. > They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?" Ironically, "what they hell were they thinking" is exactly the reaction I have to even Greenfield code written using Spring Boot or any of the other annotation driven nonsense. The idea that programs written in Java are more maintainable than programs written in (say) Go, where you can read what the program does end-to-end instead of having to guess at what garbage has been generated by Lombok or overridden by some random JAR on the class path is bizarre. Let's not even talk about Gradle.
- jfengel 2y ago
  Yeah, I'll defend Java, but I won't defend Spring. I have no idea what they were thinking. A lot of external Java framework is about inversion of control. It looks good on PowerPoint slides, but I think it's horrific to maintain (as well has hard to write). Inversion of control means you have no control, and the most common error case is "why didn't my code run?" But you can't use a debugger to tell you what didn't happen. Any breakpoints have to be set inside the framework code, which is open source but is not intended for your eyes.
  - abraxas 2y ago
    Yeah, spring was and still is, an abomination. Spring boot also. But it's not a requirement even if many Java projects fell into that trap.
- sorokod 2y ago
  My opinion is that Spring usage should be minimised as much as possible but it is a matter of fact that Spring is not Java.
  - jen20 2y ago
    Spring may not be Java (The Language), but it absolutely is Java (The Ecosystem).
  - wiseowise 2y ago
    It is mainstream Java, though.
    - sorokod 2y ago
      Yes, it (Spring) is. However its current scope creates more problems then it solves.
- pjmlp 2y ago
  //go:generate Yep no magic... Have you ever read Kubernetes source code?
hot_gril 2y ago
I have experience with code maintenance. The only upside of Java is that it's faster than JS or Python. It's otherwise a worse language and ecosystem, and it was even worse before it had lambdas.
- hot_gril 2y ago
  Actually... if it's for a web backend, NodeJS might be faster in practice.
nouveaux 2y ago
Java was so bad that Android took a hard pivot to Kotlin. If anyone understands the importance of code maintenance, it's Google. They built a language for it (Go). I think it's ok to look at historical Java for what it is and learn from it's mistakes. Modern Java is better. Unfortunately, it's developed a bad rap, and it looks like it's in a decline. Fortunately we have Kotlin, Go, Typescript, etc.
wink 2y ago
It's a very one-dimensional view. My problems with Java are startup time and memory consumption (and NPEs). If that's not your problem - fine. But writing web apps in the Java ecosystem has been terrible for many of the most important years (let's say 2005 to 2015) and that's where all the "young people" forsake it for... PHP, Rails, node.js. (You can already guess that I'm not even counting myself as part of the younger generation here. I'd used used Java and the JVM intermittently between 2000 and 2020 but it has never been my favourite stack).

javajosh 2y ago

But the comment you're replying to doesn't say Java doesn't have any downsides. It just says that Java has a great story for doing shared types between client and server, which is true. It's also true that Java as a language has gotten a lot better over time. This is I think thanks to pressure from other languages written for the jvm like kotlin, And also developer feedback for those who work in other languages like JavaScript. Java is old and boring. Just like go is new and boring. Rust has plenty of downsides this idea that it's easy to use. Seems wrong to me. The borrow checker is famously difficult to work with despite being a central feature of the language. The really big upside to JavaScript is that it's the native language of browsers and so in a weird way. If you want to get closest to the metal so to speak, JavaScript is a better option for most deployed applications. It's interesting to note that the op's article mostly points to build tools that are written in rust rather than applications and I think that's telling.

ludwik 2y ago
> But the comment you're replying to doesn't say Java doesn't have any downsides Yet it blames "hipsters" for throwing "it all in the garbage," implying that there was no rational reason for people to switch away from Java. Naturally, people respond by sharing their reasons.

abraxas 2y ago

It had a steeper learning curve than other languages or environments but that was for a reason. You got a lot in return. And those lightweight editors and environments are like that because they don't do very much. And talk not to me about lightweight. I'm currently on Day 4 of setting up a Python environment in VsCode that doesn't suck. I'm nearly there though it's still a bit inferior to a 20 year old JBuilder install for Java but I guess it needs a few more years to get there. Oh and as I said, I'm on a long quest here to pave the road for my devs but it looks like this hodgepodge of extensions still won't deliver the experience I had decades ago.

MrMcCall 2y ago
Isn't using VsCode for a non-Microsoft language going to be difficult, by (MS's) design? I'm not saying it can't/hasn't be/been done, but I doubt MS are making it easier to do so. It's been their m.o. for a long time now. I'm also not saying there's a better option for you and your team, either, my friend. As a python programmer using bare-bones vim (on purpose), having abandoned all fancy IDEs, I really wouldn't know where the state of the art is, anyway, but I doubt the MS leopard has changed its spots.
- surfaceofthesun 2y ago
  This feels true for other Microsoft products, but not VSCode. Besides, they embedded Python into Excel (for 365 users) over Typescript or C#.
  - MrMcCall 2y ago
    Interesting. Embrace & extend complete ;-) This time it looks like 'integrate' will be the third step. Thanks for the great info.
- dagw 2y ago
  Isn't using VsCode for a non-Microsoft language going to be difficult Python is pretty close to a 'Microsoft language' these days. They've hired several Python core developers to make sure windows is first class citizen for python and the developing python on windows and with VSCode is as good an experience as possible. They also develop the official VS Code Python extension and language server as well as many other python tools and extensions. I'd say the current state-of-the-art is either VSCode with the Microsoft python extensions or Jetbrain's PyCharm. Personally I slightly prefer PyCharm Pro, but it's pretty much a toss up.

maccard 2y ago

Java is verbose, is a resource hog, requires runtime management for basic app performance, the major frameworks (used to) require an awful lot of boiler plate, the developer tooling almost necessitates an IDE which 10-15 years ago meant eclipse which was slow, bloated, and unstable. There’s also always been licensing “fun” with oracle, sun, and the jdk.

watwut 2y ago
What are you talking about, seriously. 10-15 years ago, eclipse was neither slow nor unstable. It worked perfectly well. IntelliJ was not slow or unstable. There were not real major licensing issues. As a newcommer to javascript, I was able to learn faster and produce same quality faster then non-IDE developers. Not because I would be smarter or more talented, but because I had no emotional need to prove myself by not using ide.
- ludwik 2y ago
  > What are you talking about, seriously It's probably unavoidable that people's memories will differ, but personally, as someone who worked with Java 10–15 years ago and then ran away as fast as he could, these are the things I remember most: the IDEs being awfully slow and unstable (though quite powerful for their time) and the language/ecosystem being painfully verbose and full of boilerplate and layers of indirection. I remember how, after switching away from Java, I felt elated by how easy and maintainable things could be when I was allowed to use simple, fast tools and write straightforward code that just did what it was supposed to do.
- maccard 2y ago
  Eclipse was _the_ tool when I was working with Java at the time. Slow and unstable is definitely my lasting memory, compared to virtual studio 2008/2010 which was fast and powerful. > there were not real licensing issues Oh yes there were. Even in 2024 the “which JDK are you running on” debate still goes on. There are notable differences between corretto and openjdk, and openjdk and Oracle JDK. Here [0] is a stack overflow question that notes it was asked 10 years ago that talks about the various JDKs and the license change where oracle started charging for JDK access. As for your point about IDE’s vs non-IDE’s that’s a straw man. I said that you were forced to used an IDE for Java (which is of course not technically true but compared to rails which took of at that time it is), but also that the IDE du jour (eclipse) was pretty monstrous. I’ve said this on here before but the minute maven gets introduced into a project build times are measured in minutes. My current work project is c# and I can run my entire test suite faster than the jvm got itself up and running on my last kotlin project. Even IntelliJ and co suffer from these limitations - manually bumping the memory limits for IntelliJ and friends in 2024 is practically a requirement, and the startup times are very Java inspired. [0] https://stackoverflow.com/questions/22358071/differences-between-oracle-jdk-and-openjdk https://stackoverflow.com/questions/22358071/differences-bet...

watwut 2y ago

In my experience, young people who hated java never worked in java and knew nothing about it except that it is evil. The second thing however is that fronted is better off in non-java languages, you can afford to do small backend in typescript and what not. And larger enterprise projects were done in java the whole time.

littlestymaar 2y ago

Exactly! I got my first job in Java after a few years as hobbyist programmer in other languages (mostly PHP and JavaScript but a few others too) and what struck me was that the tooling was both mandatory and painful to use. I wasn't fond of JavaScript (In particular, I never liked dynamic typing), but when I had the opportunity to work in node.js instead of Java I took it immediately, just to avoid the pain and suffering that the Java toolchain inflicted on me.

FeloniousHam 2y ago
Java is a language of bondage and discpline. And architectures. And myriad pointless interface definitions. And overblown class hierarchies for problems ill-suited to the OO paradigm. I started my career in Java, and worked in it for 20 years before I really started using Javascript in anger. I didn't (and don't) like Javascript, but the freedom for prototyping was a revelation. When Typescript appeared, I fell in love.

cosmic_cheese 2y ago

At least from an Android point of view, the JVM world still has its share of frustrations and lack of polish/QoL relative to other software development spheres. Gradle has me pulling my hair out multiple times each year for example, and yet for some reason nobody sees it fit to replace it with something less ridiculously complex and prone to error (user or otherwise).

abraxas 2y ago
Yeah, gradle/maven was a mistake that happened along with most "app store" style 3d party library slingers. I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty
- pjmlp 2y ago
  As long as you don't get to debug such builds.... As someone that was writing Ant scripts when CruiseControl was modern, and there was no Ivy in sight, not sure if it was such a better place. I hated Maven at the beggining, exactly because we got some hipster company pushing for it during Maven early days, it was still hot out of the oven. 20 years later, I don't see a reason to use anything else other than Maven.
mike_hearn 2y ago
Jetbrains have a project to try and replace Gradle. I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first. Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
- pjmlp 2y ago

darthrupert 2y ago

Yup. As an older programmer I can say that there were indeed very good reasons back then to stop using Java. Mostly related to JVM but also the language lacked lots of features. Java today looks like a fine platform, though.

bitwize 2y ago

Speaking as a younger developer at the time, Java just seemed weak compared to my favorites -- Common Lisp and Scheme. It lacked a proper procedural abstraction and forced you to do everything through classes and objects in a way that not even Smalltalk, having blocks, demanded. This was especially the case when it became an enterprise language and the standard development process involved lots of boilerplate. Also, a lot of kids came out of school knowing almost only Java, and it seems they were cut off from different worlds of development which could provide some insights. Even C++, which I loathed, had things to teach. I've grown up a bit since then, and so has Java. These days I work in Java for my day job, and it's perfectly fine. I don't even mind all the boilerplate, I can look at a page of code and just see blonde, brunette, redhead. But I still love Common Lisp and Scheme much more.

cratermoon 2y ago

> The language got in my way more often than it helped me Got in the way how? By insisting that things have types and one cannot blindly add an object to an array [] + {} and expect it to behave? Never mind that in Javascript adding an array to an object {} + [] gives a different result. ETA: for bonus points, what does {} + {} return?