[HN Gopher] JDK 20 and JDK 21: What we know so far
___________________________________________________________________
JDK 20 and JDK 21: What we know so far
Author : mikece
Score : 114 points
Date : 2023-03-09 17:30 UTC (5 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| PaulHoule wrote:
| When I saw sequenced collections earlier I didn't like the design
| but I completely approve of the latest revision. One nice thing
| about the process they use to develop Java is that they really do
| work and rework new features to make them great.
|
| I just wish that instead of Streams they'd made something more
| like
|
| https://github.com/paulhoule/pidove
|
| With the possibility of making something more fluent and less
| lispy.
| mindcrime wrote:
| Pidove sounds really awesome. I'm totally going to give that a
| try!
| PaulHoule wrote:
| It has a sibling project which is still half-baked
|
| https://github.com/paulhoule/ferocity
|
| which is about developing a lispy DSL in which it is possible
| to write Java-in-Java to transform it to make syntactic
| macros. It's kinda crazy
|
| https://github.com/paulhoule/ferocity/blob/main/ferocity0/sr.
| ..
|
| and somebody might think it combines the worst of Java and
| Common LISP but I did enough work on it to be sure there were
| no major barriers. ferocity0 is a bootstrap implementation
| that it's possible to write a code generator that can
| generate code to make stubs for the standard library and
| write ferocity1 in ferocity0 and write ferocity2 in ferocity1
| with the full power of code generation to hide the accidental
| complexity of Java... But other projects got in the way.
| brabel wrote:
| Looking at your examples, this looks like
| https://github.com/square/javapoet
| PaulHoule wrote:
| Yeah, that's very similar. Thanks for the link.
|
| It's got the difference though that they are using
| (mostly) strings to write the method bodies and my
| approach builds those up with the lispy DSL. The
| class/method/field definitions are basically the same.
| (ferocity contains three languages, one of expression
| trees, one of class definitions, another of compound
| statements that doesn't exist yet)
|
| Mine can also run 'lispy Java' in an interpreted mode (as
| well as writing code that goes through javac) and I
| discovered the interpreter has a type system which is a
| little richer than the Java type system, namely I
| discovered (not invented) 'quote' and 'eval' so that
| expressions are a first class data type that can be
| manipulated.... I have to define some set of operators to
| make it easy to traverse and work on expressions which
| would make it easy to metaprogramming, probably taking
| back some of the verbosity that comes with the lispy
| java-in-java embedding.
| pjmlp wrote:
| I would already be happy if they provided some adapters for
| exceptions in lambdas, instead of us having to create our own,
| or use one of the several libraries that provide them.
| nickpeterson wrote:
| Oh great more shit to learn! I'm moving my entire bowling alley
| codebase to forth.
| lolive wrote:
| Bash FTW!
| bcrosby95 wrote:
| I was wondering this morning, with regards to the pattern
| matching for switch:
|
| Is there a performance consideration here? When using sealed
| classes, can the JVM do a better job optimizing pattern matches
| for switch? Are there also considerations with how it interacts
| with Project Valhalla?
|
| The team evolving Java seem pretty good at evolving the language
| with higher level goals in mind, so I wasn't sure if there were
| interrelated factors here.
| tadfisher wrote:
| > When using sealed classes, can the JVM do a better job
| optimizing pattern matches for switch?
|
| Yes! In the Pair<I> example from the JEP, if the number of
| subclasses of I is large enough, it may be worth generating a
| perfect hash function [0] to match the pattern in O(1) time
| instead of the naive O(n^2). This is only possible in the
| general case for exhaustive switch statements, which sealed
| classes allow for with instanceof-style patterns.
|
| [0]: https://en.wikipedia.org/wiki/Perfect_hash_function
| foolfoolz wrote:
| modern java is a huge improvement over old java. switch pattern
| matching will be huge, this has been in preview for a long time
| bombolo wrote:
| Call me around the year 3004 when they add unix datagram
| sockets, fork(), and native support for syslog... so that one
| can implement sane server software.
| adra wrote:
| Unix sockets were released in java 16 officially though it
| was always supported before that in third party software.
|
| C style fork() seems insane for any gc-type languages, so ??
| Threading in Java post virtual threads has been so pleasant
| that I'm like why would one bother?
|
| The vast majority of applications use third party logging and
| many have the ability to call out to syslogd.
|
| I'm not entirely interested that every language fits
| perfectly into the UNIX classical "everything's a process /
| pipe" style model.
| pjmlp wrote:
| None of that is required for Cloud development, yet another
| one that missed the irrelevancy of POSIX in modern software
| development.
| papito wrote:
| Look, I haven't done Java in more than 10 years, but I have
| done Scala. Honest question - isn't Java just trying to "steal"
| Scala's concepts and catch up to the "cool" languages?
| marginalia_nu wrote:
| Java's stated goal has always to be conservative with adding
| new features, to implement what the "cool" languages are
| doing after it's been battle tested. It's been this way since
| the start.
| mayank wrote:
| All modern languages heavily borrow from each other's latest
| iterations. In the case of Java though, playing catch up is
| by design since it's intended to be a conservative/stable
| language.
| sfritz wrote:
| Their philosophy is to "adopt" language features once they're
| well worn by other languages so they can learn from their
| mistakes / successes.
| NwpierratorR wrote:
| While philosophy is good, Java makes a very questionable
| syntactic choices when adopts that said features.
|
| Pure slowness in how java develop feels like you have to
| wait 5 years to get something that other languages have,
| only to get it in the most aesthetically unpleasant way.
|
| It seems like devs add unnecessary verbosity whenever they
| can.
|
| Java adopted lambdas after many other languages, yet still
| decided that allowing to move last parameter closure {}
| outside of () is too radical, even though it is much more
| visually pleasant choice and quite common in other
| languages.
|
| default methods in interfaces instead of static extensions.
| This one is controversial as static extension methods were
| not really common when java came up with this, but end
| result does not look impressive.
|
| Same with their new sealed classes. They just chose the
| most verbose version they came up with.
|
| Some inconsistency of choices also kinda baffles me. First
| they added support for skipping necessity of mentioning
| generic type inside <> during instantiation, only to
| introduce local vars later that require you to mention
| generic types within the same <>. Now you either mention
| generics by their full type always, or embrace the
| inconsistency and have it skipped when type mentioned in
| prefix and type it when using local vars. Or do not use
| local vars and have consistent codestyle with increased
| verbosity.
|
| Java is still a good language, but it feels dated in
| syntax. TBH I have no idea why would anyone chose java in
| 2023 when there's kotlin, which not only fully covers the
| same functionality(okay, no pattern matching and no
| loom/valhalla until java merges it), but does it while
| being much more concise and readable.
| marginalia_nu wrote:
| I'd choose Java over Kotlin in 2023, in fact I'd do so
| most years. I'll pretty much take conservative language
| design over developer comfort every day of the week.
| Alupis wrote:
| But you do not have to choose Java over Kotlin - you can
| use them both in the same project without any side
| effects.
|
| This was by design for Kotlin, and is probably their
| smartest/best feature. _All_ existing Java code /libs
| _just work_ in Kotlin. Conversely, most Kotlin code /libs
| _just work_ in Java, although some care needs to be made
| there.
|
| Kotlin is amazing to use and read. For most things, the
| Kotlin version is easier to read and comprehend than the
| Java version in my experience.
|
| As Java adds language features, Kotlin either gets them
| for free or already had them (and now can use native
| features instead of their own custom features).
| krzyk wrote:
| In my case Kotlin was harder to read than Java, so it
| really depends on the person.
|
| (Same thing with Groovy, but that one is even worse than
| Kotlin)
|
| On the other hand Scala looks nice.
| pjmlp wrote:
| Kotlin adds Jetbrains only as IDE, additional build
| plugins, an ecosystem of Kotlin libraries for more
| idiomatic code, stack traces completly unrelated to
| Kotlin as JVM only understands Java, and it needs plenty
| of boilerplate to emulate co-routines and functions in
| JVM bytecodes.
|
| Other than Android, there are no reasons for additional
| complexity in development tooling.
| Alupis wrote:
| Most of your points are not really valid if you
| understand Kotlin. It's not different than understanding
| Java really...
|
| > Kotlin adds Jetbrains only as IDE
|
| Not true, you can use any IDE you want. Of course
| IntelliJ is the "blessed" IDE, but really, Kotlin is just
| a bunch of libs, any IDE will work.
|
| > additional build plugins
|
| I don't see why this would matter. Any non-trivial build
| is going to use a bunch of plugins.
|
| > an ecosystem of Kotlin libraries for more idiomatic
| code
|
| Which are optional.
|
| > stack traces completly unrelated to Kotlin as JVM only
| understands Java
|
| I don't know what you mean. The stack traces are from
| bytecode, which Kotlin compiles to just like Java. The
| stacks are identical...
|
| > needs plenty of boilerplate to emulate co-routines and
| functions in JVM bytecodes
|
| You do not write the boilerplate though. That's the
| difference. Of course _all_ higher level languages with
| High Order functions are going to suffer this same issue.
| It 's abstractions all the way down..
|
| You probably already use Kotlin and don't even know it.
| The popular okHttp library from Square is Kotlin - but
| you'd never know that if you just used it in your Java
| project.
| pron wrote:
| Programmers rarely have consensus on anything language-
| related, but their preferences are not always evenly
| distributed. Our decisions re Java aim to cater for the
| majority of _professional teams_ , which may not
| necessarily be represented by the majority of commenters
| on HN. If you don't understand why many more teams prefer
| a language with choices that appeal to you less over
| languages with choices that appeal to you more, the
| answer may be that your preferences are not the same as
| those of the majority of teams.
| skitter wrote:
| This is the most infuriating kind of answer: There are
| concrete complaints and this comment addresses none of
| them. Claiming that there are people who prefer Java's
| syntax to be inconsistent isn't useful without saying why
| they do.
| davnicwil wrote:
| Yes, and that's a fantastic strategy.
|
| Steal the bits that work, don't steal the bits that don't
| work, get cooler but slowly without adding a bunch of useless
| rough bits along the way.
| ackfoobar wrote:
| And Scala is stealing OCaml's named pattern matching for
| records, while Java is replicating Scala's deficiency
| (positional destructuring only) from a decade ago.
|
| https://github.com/scala/improvement-proposals/pull/44/files
| [deleted]
| cbm-vic-20 wrote:
| The Java team is very conservative in building out new
| language features- they find the things that have been battle
| tested in the wider language space, and take their lessons
| and adapt them into Java features. IMO this is a good thing.
| If it's "stealing" then every other language is "stealing"
| from each other, too.
| [deleted]
| pjmlp wrote:
| It is called Java Virtual Machine, not Scala Virtual Machine.
|
| The guest languages are just that, guests that eventually
| leave the party.
| andylynch wrote:
| I was just reading the final chapter of The Well-Grounded
| Java Developer, and it quotes thus on the borrowing of ideas,
| which is apt to mention here:
|
| _One of the surest of tests is the way in which a poet
| borrows. Immature poets imitate; mature poets steal; bad
| poets deface what they take, and good poets make it into
| something better, or at least something different._
|
| --T. S. Eliot
| nativecoinc wrote:
| Comparing ten-years-ago Java with todays: Yeah, it's come a
| long way but it's nowhere close to what Scala is (for better
| or worse; I truly don't know).
| zokier wrote:
| > Honest question - isn't Java just trying to "steal" Scala's
| concepts and catch up to the "cool" languages?
|
| Is that somehow bad thing?
| Kwpolska wrote:
| Scala is not cool in any way, shape or form. It's an
| unsuccessful, niche language, that has implemented probably
| every possible feature ever done in a programming language,
| including some really backwards ones (like putting XML in the
| middle of your code). Having all those features makes Scala
| harder to learn and understand. Programming language features
| aren't "stolen", since they aren't really "owned" by any
| given language.
| nradov wrote:
| You're getting down voted but your comment is basically
| correct. Scala contains some good ideas but due to high
| complexity and weak tooling support it has failed to gain
| mainstream adoption. And it's widely recognized now that
| embedding XML literals in the code was a bad idea; if we
| want to do something like that then it should be a more
| generalized mechanism that could support other hierarchical
| data formats such as YAML or JSON instead of being locked
| in to XML.
|
| Despite its flaws, Scala isn't a bad language necessarily.
| It will still continue to see niche use. But it no longer
| seems like the obvious path forward for general purpose
| application coding.
| Kwpolska wrote:
| I don't think a generalized mechanism that would
| simultaneously suport XML and JSON would work, because
| they have different structures, uses, and
| generation/parsing mechanisms (XML/HTML is often
| generated using textual templates, but JSON is generated
| and parsing by going by plain old objects.
|
| While Scala is perhaps not a "bad language", it contains
| many flaws and I don't see much of a bright future for
| it. (Also, Scala 3 brings new single-use features, and an
| entire alternate Python-style syntax, because learning
| one syntax is apparently not enough.)
| nradov wrote:
| My point was that XML and JSON (and YAML and
| S-expressions) are fundamentally similar in that they can
| be modeled as tree structures. So, in principle it might
| be possible for a programming language to have
| generalized support for tree structured data literals
| which could then be encoded into multiple different
| external formats. As to how that could work syntactically
| without turning into a huge mess, I'm not sure.
| JackFr wrote:
| Honestly I've used Scala in production in 3 separate
| companies and ten years ago everyone realized that XML in
| the code was a terrible idea. No one serious does it.
|
| I'm working in Java now, but I thought Scala was
| fantastic. The problem was that it attracted functional
| programming puritans and the category theory astronauts
| -- both groups had some really good ideas -- but
| pragmatism is at odds with elegance and focusing on
| delivering business value versus developing knowledge of
| theory can be a tough balancing act.
| SillyUsername wrote:
| The only company I've ever known to use Scala in a big
| way, based on their job ads, is Disney Streaming. Now
| their streaming service is successful and stable, so it
| clearly was the right choice for them, but honestly I
| can't help but think they chose the runt of the litter. I
| imagine it's a developer who wanted the latest fad
| functional language on their CV many years ago, abandoned
| the company (or got promoted out of the dept.), and now
| Disney's current developers have to support a language
| that is mostly not idiomatic with the OOP libraries it
| uses, and lacks the userbase and support other languages
| enjoy.
| valenterry wrote:
| Then can you explain why Scala's spec is so small? Even
| Java's spec is much larger.
|
| I'll tell you the answer: because the language is
| comparably well designed, with a lot of foresight, and the
| fundamental features work well together. Also you are
| totally right about XML. This was a total mistake and in
| fact already has been removed from the language - I think a
| few years ago.
|
| Maybe you still have the old Scala in your head? That would
| explain your post a bit I guess.
|
| > Programming language features aren't "stolen", since they
| aren't really "owned" by any given language
|
| I agree with that though and I think it's great that Java
| is progressing. There is no shame in copying the good
| things.
| Kwpolska wrote:
| > Then can you explain why Scala's spec is so small? Even
| Java's spec is much larger.
|
| Are the two specs comparable? Looking at the Scala 2.13
| [0] (I can't find a Scala 3 spec) and Java 19 [1] specs,
| while the Java spec is much longer page-wise, it is also
| much more formal and detailed:
|
| * The Java spec sometimes defines things that might count
| as part of the standard library (eg. how threading and
| wait/notify work).
|
| * The Scala specs just says "Scala source code consists
| of Unicode text.", but the Java specification says what
| Unicode is, and talks about UCS-2/UTF-16 and why chars
| have surrogates (over almost two pages).
|
| * The Java specification also talks a lot about the JVM
| and bytecode. The Scala spec does not include any details
| or assumptions about the underlying execution
| environment.
|
| * Scala also delegates a lot of things that you would
| consider part of the language (e.g. the + operator for
| integers) to the standard library. Also, how do I figure
| out how large an Int can be in Scala without reading
| stdlib docs or writing a program to query Int.MaxSize?
|
| * Similarly, comparing the keyword count of Java and
| Scala doesn't necessarily yield sensible results, since
| Java considers `int` to be a keyword, but in Scala, this
| is just the name of a standard library class.
|
| Also, the size of the language specification has nothing
| to do with how easy a feature is to grasp. Implicits may
| take 8 pages in the specification, but they are difficult
| to understand and tricky, especially if the implicit
| keyword meant 4 semi-related things in Scala 2.
|
| ---
|
| > Maybe you still have the old Scala in your head? That
| would explain your post a bit I guess.
|
| Which "old" Scala? Scala 3 still has ~all the features of
| Scala 2. It also has two separate syntaxes, a Java-like
| and a Python-like syntax, to add even more confusion and
| even more things to learn.
|
| > This was a total mistake and in fact already has been
| removed from the language - I think a few years ago.
|
| From the Scala 3 docs [2]:
|
| > XML Literals are still supported, but will be dropped
| in the near future, to be replaced with XML string
| interpolation[.]
|
| [0] https://scala-
| lang.org/files/archive/spec/2.13/spec.pdf
|
| [1]
| https://docs.oracle.com/javase/specs/jls/se19/jls19.pdf
|
| [2] https://docs.scala-lang.org/scala3/reference/dropped-
| feature...
| emodendroket wrote:
| For the operator thing, isn't that just because there is
| no difference between an operator and a method in Scala?
| Kwpolska wrote:
| Pretty much, yes. Operators being methods of stdlib
| classes and being a guest language on the JVM are two
| things that let the spec be shorter by omitting details a
| developer needs to know.
| emodendroket wrote:
| I suppose I've always seen the audience for the spec as
| language implementors, not users, who are unlikely to
| look at it.
| darksaints wrote:
| > Which "old" Scala? Scala 3 still has ~all the features
| of Scala 2.
|
| You linked to a page that has several actual dropped
| features from Scala 3. If Scala 3 didn't drop features,
| it would still be Scala 2. What exactly is the point of
| all this edgelordery? We get it, you think Scala is
| uncool, but that's just like your opinion man. Did you
| really jump onto a comment about Scala just to shit on
| Scala? I'm horrified to think of using a language that
| someone like you might actually think is cool.
| Kwpolska wrote:
| The list of dropped features isn't very long, and many of
| them are very minor or niche things. Nothing comparable
| to Python 2 - 3, for example.
|
| I started by commenting on the OP's statement calling
| Scala "cool" and talking about the feature bloat in Scala
| (that makes it uncool and hard to learn).
| valenterry wrote:
| You make some valid points. I still think after removing
| the points you mentioned, Scala's spec will still be
| shorter - but I'm too lazy to do that.
|
| And reasons are for example that the language just has
| less exceptions. Like the + "operator" which is just a
| method. And Int just being a datatype - no need to put
| this in the spec. Or that "int" is not a keyword in Scala
| - well, I think that is totally a good thing and also
| comparable, why not?
|
| > Also, the size of the language specification has
| nothing to do with how easy a feature is to grasp
|
| Sure, but your original claim wasn't just "it's hard to
| learn Scala" because with that claim I would agree.
|
| > Scala 3 still has ~all the features of Scala 2
|
| Scala 3 has removed a lot of features. In particular
| powerful features like Scala 2's macros. So what you say
| is just wrong (the tilde in front of the all really
| doesn't make it better).
|
| > It also has two separate syntaxes, a Java-like and a
| Python-like syntax, to add even more confusion and even
| more things to learn.
|
| That's a valid point, but if _this_ is your level of
| complaint, then you must hate Java much more than Scala.
| It has way more warts and confusions than Scala. I know
| both languages in and out.
|
| > > XML Literals are still supported, but will be dropped
| in the near future, to be replaced with XML string
| interpolation[.]
|
| Careful here. XML _literals_ are still supported (even
| though deprecated), but that is _not_ xml support. XML
| support has been completely removed from the compiler and
| is now in a library that needs to be imported. This is
| different from before, where XML was really built into
| the language.
|
| In other words: try to use XML without that library and
| it will simply not compile.
| Kwpolska wrote:
| > Scala 3 has removed a lot of features. In particular
| powerful features like Scala 2's macros. So what you say
| is just wrong (the tilde in front of the all really
| doesn't make it better).
|
| Sure, macros were removed, but they were an experimental
| thing in Scala 2 (and another case of language bloat
| IMO). If you look at features used in day-to-day
| programming (in [0] or [1]), the list of removed features
| is quite short, and many of them are very minor things
| that can be usually automatically replaced, and some of
| them were still supported in Scala 3.0 (perhaps with a
| compatibility flag).
|
| [0] https://docs.scala-
| lang.org/scala3/guides/migration/incompat... [1]
| https://docs.scala-lang.org/scala3/reference/dropped-
| feature...
| valenterry wrote:
| Cool, now we are from
|
| > Scala 3 still has ~all the features of Scala 2
|
| to "Scala 3 has most of the day-to-day (from a language-
| user's point of view) programming features". I'm fine
| with that. :)
| MajimasEyepatch wrote:
| Part of the reason that Scala's spec is so small that so
| many features are incredibly generic. Concepts like
| implicit are overloaded in a bunch of different ways and
| give rise to powerful but complex patterns that you need
| to understand to use the language, even if they're not
| strictly required for it. And since all of these
| different features and patterns are optional, you end up
| with every Scala codebase using a slightly different
| subset of the language, and different communities
| evolving very different ways of doing things. Look at
| Spark code vs. ZIO code and it's like night and day in a
| lot of ways.
|
| Scala 3 improved the situation a bit by breaking the
| "implicit" concept down into a few discrete concepts, but
| the language is still incredibly expansive, despite the
| "look how few keywords we have" talking point.
|
| Honestly, I do think that modern Scala is very well
| designed. But unfortunately the ecosystem and tooling and
| corporate support for it never really got to the point
| where it feels like a practical choice for most teams.
| 62951413 wrote:
| It's a pity its adoption is stagnant. But it was highly
| successful in at least two respects:
|
| * introducing Java developers to the world of FP about ten
| years ago (i.e. before JDK8 and Kotlin) with a lot of that
| knowledge transferable to Kotlin in particular
|
| * significantly influencing Kotlin and evolution of Java
| itself
|
| Don't forget that it also made Spark (and to a lesser
| degree Flink and Kafka) possible.
| MajimasEyepatch wrote:
| Ironically, that XML(ish)-in-code idea did survive in
| JavaScript, where embedding HTML in code with things like
| JSX is now pretty standard. But that's the rare case where
| a programming language is so deeply entwined with a markup
| language that it's natural to bring them together. XML
| proper is increasingly rare as a data format nowadays, so
| Scala's support for it feels like a strange relic of a
| bygone era.
| bcrosby95 wrote:
| Many of these changes are made with an eye towards having
| better support for data oriented programming in Java:
|
| https://www.infoq.com/articles/data-oriented-programming-
| jav...
| [deleted]
| tpoacher wrote:
| My honest reply to that would be, do some more java and see
| for yourself. Your last experience with java was Java 5,
| which is ... ancient.
|
| Java has gone through a lot of changes, and is actually a
| very nice, streamlined language now.
|
| You'll probably be very surprised to hear it even comes with
| a jshell and jwebserver these days!
| SillyUsername wrote:
| I would not call Java streamlined by any measure, API size,
| library size, or LOCs. If you want to see a streamlined
| API, see Typescript + Webpack which will trump in all of
| those metrics.
|
| Source: Me, Java coding professionally since Java 1.0 when
| it was "streamlined" in 1997, and Typescript for the last 5
| years.
| vips7L wrote:
| That doesn't seem like much of a source. Do you have
| specific examples?
| SillyUsername wrote:
| I'm sorry if 25 years of experience in Java programming
| doesn't seem a lot to you. Given it's almost as long as
| Java has been about, and I've worked at EA and other
| companies full time as a mobile server side architect, am
| an open source contributor (albeit not a popular
| contributor, but one who codes in 4 languages regularly)
| perhaps you might like to reconsider my experience as
| sufficient.
|
| Java has a lot of required infrastructure, typically
| Spring these days, which brings with it all the boiler
| plate. Spring Boot is an "opinionated stack" (Google it)
| which basically is needed because _there is so much
| configuration required_ due to its enterprise level
| design, you can't just strip Spring out and have Java
| serve a basic 200 RESTful endpoint in the same footprint
| as other modern languages.
|
| Additionally most projects typically include a lot of
| legacy mis-steps or third party Apache libs that have
| added bloat (3-4 logging libraries in a single project
| not uncommon, 2-3 Date apis, numerous XML or JSON parsers
| etc etc). So while code on the surface seem compact, in
| actual fact it's built on bloat. And my God the stupid
| FactoryFactoryFactory antipattern and similar over-
| engineered crap (I'm ashamed of the neckbeards of my age
| that actually thought this was a good idea).
|
| In contrast TS (or JS), for server side do not require
| boilerplate, and the syntax lends itself to near native
| JSON handling removing the need for heavyweight parsing
| of RESTful or GraphQL endpoint arguments and responses.
| Then there's Serverless... Java cold starts in themselves
| are still a joke, Java is clearly better when it comes to
| batch work and warmed up, but need a quick small AWS
| Lambda to do something, a true one purpose "microservice"
| and TS will be both shorter to write and quicker to
| start, moreover it's half the cost owing to memory and
| CPU overhead (there are cloud metrics out there to prove
| this) but Java is more performant and we're talking about
| streamlining here so I've gone off topic.
|
| If you're a Java fanboy, like I once was, you'd do well
| to spend some time in other languages, not just to play
| in some small projects, then you'll come back to Java
| with a different perspective.
| fidgewidge wrote:
| Try compiling a program that prints Hello World to the
| console and see how many bytes it takes in both source
| and shipped form. JS/TS will indeed win every time in
| those metrics.
| vips7L wrote:
| Why is that a metric that matters?
| fidgewidge wrote:
| Download latency is important in many contexts.
| vips7L wrote:
| But isn't important in the hello world context and in
| other contexts I don't think it's a great comparison.
|
| Typical node apps will ship with megabytes of extra files
| for functionality that would be present in the Java
| standard library. Even if I take your claim as fact,
| programming languages are about trade offs. While Java
| might suffer from download latency it will more than
| likely beat TS on execution time and gc latencies.
| Jtsummers wrote:
| It isn't. It tells you nothing about how the language
| scales up, only how simple it can get when you want to
| print a value.
|
| https://rosettacode.org/wiki/Hello_world/Text
|
| You can see that some languages are simpler than others
| (even JS can be beat by this useless metric, check out
| APL). But it gives you no idea how the language scales up
| for complex tasks.
| SillyUsername wrote:
| HelloWorld doesn't. These do (make sure to scroll):
| https://programming-language-benchmarks.vercel.app/java-
| vs-t...
| [deleted]
| mindcrime wrote:
| Meh. Take pattern matching for example... that dates back at
| least to the SNOBOL[1] days. So you could say that every
| language that has first class patterns and pattern matching
| is "stealing" from SNOBOL. Or probably SNOBOL "stole" the
| idea from some predecessor. My point is, "imitation is the
| sincerest form of flattery." Languages have been "borrowing"
| ideas from each other dating back to the beginning of
| programming languages. There's nothing particularly notable
| about Java continuing that tradition.
|
| [1]: https://en.wikipedia.org/wiki/SNOBOL
| aardvark179 wrote:
| We are all taking stuff that ML had 40 years ago, or maybe
| Lisp 50 years ago. I wish the debates around language
| features could just get past the idea that language X is
| stealing from my favourite language Y.
| javier2 wrote:
| In that case you need to look at the people designing
| java/C# in the 90s.
| nradov wrote:
| As an industry we have amnesia. Many developers, including
| programming language designers, are simply unaware of what
| was done decades ago and thus end up reinventing the wheel.
|
| Before jumping into writing new code we should develop the
| discipline to start by researching what has been done
| before in similar domains. Even if the old code isn't
| reusable we can often apply the same design patterns or at
| least avoid making the same mistakes.
| xg15 wrote:
| Pet peeve warning.
|
| I'd like to propose a very simple JEP for JDK22: Let me omit the
| useless {} at the end of a record declaration.
|
| I get that records are technically classes and that sometimes,
| you want to add helper methods, additional constructors, etc. But
| the canonical - and most common - usecase for records is a dumb
| immutable data structure, and for that you shouldn't need
| anything except the fields and generated methods. That's the
| whole idea behind them.
|
| I always found it strange that Java has you write an awkward
| empty class block for the standard usecase here, while reserving
| the more natural syntax for exotic uses.
| krzyk wrote:
| Do you really think they just forget about it? It has a
| purpose: https://mail.openjdk.org/pipermail/amber-
| dev/2020-April/0058...
| javier2 wrote:
| These things are what I love the most about JEPs. Someone
| already discussed it.
| imoverclocked wrote:
| That's the fun thing about backward compatibility. You can
| never clean up technically supported things that were never
| intended.
|
| It would be cool if we could have some kind of pragma or
| alternate syntax (file extension?) that gets rid of these
| unwanted ambiguities every decade or so. How to do that while
| avoiding the whole "Perl 6" can of worms might be the hard
| part though.
| nativecoinc wrote:
| Perl 5 has that.
|
| Perl 5 seems to have all these annoying boilerplate lines
| that you need to add to every file in order to get "Perl
| The Good Parts". But I think (I read) that they managed to
| boil it down to just one line.
| KptMarchewa wrote:
| Rust editions? They work on per crate, rather than per file
| level though.
| xg15 wrote:
| Thanks for digging out that thread, that really gives some
| insight!
|
| I still disagree though. First, there is precedent with
| interfaces and abstract methods, which also leave out the
| method body and terminate with a semicolon.
|
| Second, the point here is that you _almost always_ leave the
| body of a record empty, while you rarely do so for a class or
| method.
|
| They are worried that if you use arcane constructs like non-
| static initializers, the syntax _might_ become confusing -
| but are fine if you have clutter in the common case. That
| seems backwards to me.
| bcrosby95 wrote:
| > I'd like to propose a very simple JEP for JDK22: Let me omit
| the useless {} at the end of a record declaration.
|
| Meh. Pet peeve warning: I hate this. Sneaking in stuff like
| this that might save 1 or 2 characters every hundred or
| thousands of lines is just frustrating.
|
| If I'm regularly discovering cute one-off things like this in a
| language I work in then I'm gonna hate the language. And
| unsurprisingly, I hate most modern languages.
| capableweb wrote:
| Unless your doing mostly lisp programming, it does sound like
| you hate most languages (which to be honest, is the position
| I'm in so wouldn't surprise me)
|
| To turn it around, what languages do you love?
| [deleted]
| illiarian wrote:
| My pet peeve is that all properties could be in the class body,
| and then both classes and records could enjoy object
| initialisation a la C# if the committees that be ever wanted to
| add any useful ergonomics to the language.
|
| Alas.
| DeathArrow wrote:
| In C# you can declare a record like a method body.
| emodendroket wrote:
| Tantalizing to know how many useful features are being added all
| the time and yet so many apps are stuck on JDK8.
| lolive wrote:
| I see more and more the JDK11 to be an absolute minimum. (which
| leads to issues because of that [still mysterious to me] move
| to modules management)
| marginalia_nu wrote:
| Foreign Memory API can't come soon enough. The weird hoops you
| have to jump through to allocate large buffers of memory in Java
| are perhaps my least favorite aspect of the language right now.
| marcosscriven wrote:
| What I'd really love to do is limit memory by Java thread,
| rather than per process. Allowing things like job runners to
| not crowd out others.
| Phelinofist wrote:
| Structured concurrency sounds amazing, but it will probably take
| some time till it is widely usable :(
| clumsysmurf wrote:
| The only reason why I am looking at Golang is because of its fast
| startup and low memory usage. I prefer the Java ecosystem and
| Kotlin specifically; how is the JVM's progress in this area for
| serverless, etc?
| vbezhenar wrote:
| Not good.
|
| Java needs set of microservice libraries reimagined from the
| ground up. Optimized for size and RAM consumption. Optimized
| for GraalVM compilation (it's bad, but it's not that bad,
| libraries make it that bad). Also preferably including new tool
| for building because Maven and Gradle are bad.
|
| I'm in the same boat. I love Java, but I hate Java ecosystem. I
| hate golang, but I love its ecosystem. And I think that it's
| possible to write golang-like ecosystem for Java. After all
| there're people who wrote deno and bun to oppose node.js.
| Hopefully vaja will appear.
| fidgewidge wrote:
| That's what libraries like Quarkus, Helidon etc are.
| ActorNightly wrote:
| Golang is many times well better designed than Java ever will
| be. Java has fundamental issues with the language (which is the
| reason Groovy and Kotlin exist in the first place).
|
| If you want performance, stick with Golang. If you want rapid
| prototyping/dev, go with Python, 3.11 is much better in
| performance than older versions.
| pjmlp wrote:
| Yeah, their design of enumerations is tip top.
| threeseed wrote:
| There is GraalVM native image [1] which works well.
|
| And libraries like Quarkus [2] that leverage it that can launch
| in < 0.016s with < 12MB of RAM.
|
| [1] https://www.graalvm.org/22.0/reference-manual/native-image/
|
| [2] https://quarkus.io
| dschulz wrote:
| unfortunately, compilation times are not so good.
| msgilligan wrote:
| Well, you do most of your compilation, test, and debug
| under the JVM and only do final test (and possibly debug)
| with native compilation.
| carimura wrote:
| Check out Project Leyden [1] in OpenJDK for work being done in
| this area.
|
| [1] https://inside.java/tag/leyden
| FlyingSnake wrote:
| How is the generics story going in golang? I wonder if it
| brought a major paradigm shift in the way Go is written.
| bbkane wrote:
| I don't know about a paradigm shift, but the craziest use of
| them I've seen is https://github.com/jhbrown-
| veradept/gophercon22-parser-combi... .
|
| I watched the talk, thought I understood it "enough", then
| completely fell on my face trying to write a JSON parser.
|
| Could be me though, maybe I should try it again now that it's
| been a few months
| dgunay wrote:
| It is definitely better than before, but doesn't really
| change the game much. It has severe limitations.
|
| My biggest hope when generics were announced was that we'd
| finally get an alternative to writing `if err != nil` 10+
| times per function, but it doesn't support generic method
| type parameters. That alone kneecaps it severely by making
| type-safe method chaining useless in most scenarios (unless
| you never need to map to another type, ever, I guess. Lucky
| you.)
| zinclozenge wrote:
| It's pretty rare you need to write anything generic unless
| you're writing a library, or library like functionality.
| pjmlp wrote:
| Depends if you want to pay for one of the commercial offerings
| for AOT compilation that have existed for 20 years, or rather
| go with the free beer offerings from GraalVM and OpenJ9.
| endisneigh wrote:
| It's been a while since I've programmed in Java. I wonder how
| good the concurrency stuff is these days. On a somewhat related
| note I was talking to a team from a random bay area company on
| how they switched from Java/Spring to Node and that Node is
| slower but since it's single threaded they load balance a bunch
| of servers and in practice it's just as fast when considering the
| developer productivity.
|
| Compute is really cheap these days, so I wonder how much it's
| worth it to squeeze every drop of performance out now.
| RedShift1 wrote:
| They are using the cluster module right?
| https://blog.appsignal.com/2021/02/03/improving-node-applica...
| foepys wrote:
| > Compute is really cheap these days, so I wonder how much it's
| worth it to squeeze every drop of performance out now.
|
| And that's why every single Electron app is slower on a modern
| 4.7 GHz 8 core CPU than a (although not as pretty) native app
| on a single core CPU in 1999. Spotify is slow as molasses and
| has less features than foobar2000, MS Teams is slower than any
| messenger I used in 2005, and all those Postman-like apps are
| just a horror to use compared to a simple bash script with
| wget.
|
| Case in point: I cannot use MS Teams on my state of the art
| computer when I'm compiling. It's just so slow to type and
| switch chats.
| vosper wrote:
| > and all those Postman-like apps are just a horror to use
| compared to a simple bash script with wget.
|
| Personally I like having collections of requests, automatic
| formatting of responses, dedicated fields to enter headers
| into, automatic parsing of cURL / HAR etc, the ability to
| generate code in various languages...
|
| There's a lot more to most of these Postman-like apps than
| just making requests!
|
| Though I have seen Insomnia just completely choke up on large
| responses (10s of MBs) that Sublime renders in a flash - so
| you're not completely wrong, just throwing the baby out with
| the bathwater :)
| krzyk wrote:
| > just as fast when considering the developer productivity
|
| I wouldn't use Javascript and developer productivity in the
| same sentence.
| marginalia_nu wrote:
| Compute is cheap if you're doing trivial things that doesn't
| require much compute.
|
| Flip side is that this is true for everyone. If you're only
| doing trivial things that could have been done 20 years ago,
| you really don't have much competitive advantage. It's
| difficult to be competitive in the area of solving easy
| problems.
| imtringued wrote:
| Compute is cheap if you only run one program on your
| computer. The moment two or more "compute is cheap" programs
| run on a computer is the moment when cheap is not so cheap
| anymore.
|
| Nothing like IntelliJ crashing during a video conference and
| then indexing your entire project from scratch... Encoding
| video in real time is CPU intensive, indexing a hundred
| libraries adds oil into the fire.
| CharlieDigital wrote:
| > Compute is cheap if you're doing trivial things that
| doesn't require much compute.
|
| A lot of the work on the web/API side is I/O bound (e.g.
| waiting for network I/O to database) so unless throughput is
| your game (e.g. Stackoverflow), it seems that Node is "good
| enough" for most web/API work.
| marginalia_nu wrote:
| It is I/O bound because you aren't using the available
| compute as much as you could.
|
| Modern hardware is insanely powerful. Like it's absolutely
| bonkers how much you can do on a modern computer. Although
| most modern applications have capabilities on par with a
| 2006 flash game.
| bombcar wrote:
| The vast, vast majority of "business code" even at startups
| and unicorns like AirBNB and Uber is not doing "compute-
| bound" things. They're all basically fancy CRUD apps.
| marginalia_nu wrote:
| Yeah, you can do more though, is my point. The CRUD market
| is pretty crowded.
|
| Feels like a lot of the AI hype is the sudden discovery
| that modern computers are actually pretty fast and
| squandered doing book-keeping in small-to-medium SQL tables
| (not that you need LLMs to do interesting things with
| them).
|
| Basically anything that required a data center in the year
| 2000 you can do on a powerful desktop PC today.
| Traubenfuchs wrote:
| > I wonder how good the concurrency stuff is these days.
|
| What were you missing? Java had threading, task, threadpool
| capabilities for ages. It comes with all kinds of concurrent
| collection classes and running something in parallel could be
| just one .parallelStream() away. There are also countless
| reactive frameworks that minimize thread count. Java Loom /
| green threads are available since Java 19 (hidden behind a
| flag).
| endisneigh wrote:
| Sorry, I meant in terms of developer ergonomics and ease of
| use, not purely compute performance.
| winrid wrote:
| The Reactive java frameworks are way more developer
| ergonomic than NodeJS if you use the virtual threads
| previews, otherwise you have to use callbacks/futures. But
| at least you have runtime type checking...
|
| Vertx is way better than Node in a lot of ways, and faster,
| and easier to debug. Lock the event loop? You immediately
| get a log that you did something bad.
| winrid wrote:
| Like I just got an error in my IDE with TypeScript
| "ChartConfiguration is not generic". So I cmd+click into
| the type definition and it's a ChartConfiguration<T>.
| okay...
|
| The whole ecosystem feels super fragile. It hurts
| productivity and moral. This just doesn't happen with
| Java.
| NERD_ALERT wrote:
| It's about to get much better once Project Loom is ready. This
| will introduce virtual threads and structured concurrency.
|
| https://developer.okta.com/blog/2022/08/26/state-of-java-pro...
| fidgewidge wrote:
| _> Node is slower but since it 's single threaded they load
| balance a bunch of servers and in practice it's just as fast
| when considering the developer productivity_
|
| This sentence doesn't make any sense. It can't be both slower
| and just as fast, developer productivity is a totally different
| concept to performance. And being single threaded just means
| you have to spend more RAM to saturate your CPUs (threads are
| cheaper than processes), nothing stops you running many single
| threaded JVMs and load balancing across them, it's just
| inefficient.
| ithrow wrote:
| Genuine question, why developer productivity was higher in
| node?
| SillyUsername wrote:
| Node is much simpler to work with, and if you're running one
| shot, short serverless ops (i.e. not batch), faster to start
| (no JVM cold start) and cheaper to run (less RAM) than Java.
|
| If they're really concerned about performance they'd not go
| wrong by using Deno which often has at least double the
| performance of Node https://medium.com/deno-the-complete-
| reference/node-js-vs-de...
|
| Deno for a lot of operations is actually comparable to Java
| level performance: https://programming-language-
| benchmarks.vercel.app/java-vs-t...
| fidgewidge wrote:
| Of course there is cold start. Both Node and Deno use JIT
| compilation just like regular Java, which means they warm up.
| JS code will use _more_ RAM than Java for equivalent
| constructs, not less. You may be fooled though, by the way
| that the JVM by default will use free RAM rather than burn
| energy /CPU collecting garbage when it doesn't need to. So it
| will look like your app is using a lot of RAM but in reality
| the JVM will give it up when asked.
| SillyUsername wrote:
| My experience of paying for cloud services does not back
| that up.
|
| Java AWS Lambdas are typically 2-3x heavier in memory usage
| than a TS/JS equivalent, and the benefit of that warmup is
| negated if the Lambda shuts down due to idle time.
|
| "Give it up when asked" !== less streamlined, it means
| expanding heap is required for normal operation. Too little
| heap, it buckles, GC is almost constant, and performance
| goes out of the window.
| throw0101a wrote:
| > _Compute is really cheap these days, so I wonder how much it
| 's worth it to squeeze every drop of performance out now._
|
| "What Andy [Moore of Intel] giveth, Bill [Gates of Microsoft]
| taketh away."
|
| * https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
|
| See also:
|
| > _Wirth 's law is an adage on computer performance which
| states that software is getting slower more rapidly than
| hardware is becoming faster._
|
| * https://en.wikipedia.org/wiki/Wirth%27s_law
___________________________________________________________________
(page generated 2023-03-09 23:01 UTC)