[HN Gopher] Java 21: What's New?
___________________________________________________________________
Java 21: What's New?
Author : agluszak
Score : 105 points
Date : 2023-08-09 19:45 UTC (3 hours ago)
(HTM) web link (www.loicmathieu.fr)
(TXT) w3m dump (www.loicmathieu.fr)
| whartung wrote:
| Yummy.
|
| Java's rocket sled continues to burn.
| ryanianian wrote:
| What?
| eastbound wrote:
| Anyone knows when the Java 21 LTS certification book will be out
| ("OJP exam" or something like that)?
|
| I'm tempted to pass the exam with Java 17, since the wait for
| Java 21 will be too long, assuming it will be several months
| after the GA date, September 21st.
| hmottestad wrote:
| You'll probably be fine without it. If I'm interviewing someone
| and they have a Java 6 certification I'll just think that
| someone forced them to get it, but if they have 17 or newer it
| would be a big red flag unless they are straight out of uni and
| working at a consulting firm.
| Espionage724 wrote:
| For a while I was only interested in newer Java releases just to
| see if Runescape ran on it :p
|
| The usefulness seemed to cut-off with Java 11 though and now the
| RS Java client is being deprecated.
| lfmunoz4 wrote:
| [dead]
| sigzero wrote:
| Is Java 21 the next LTS version?
| ajdoingnothing wrote:
| I can't wait until major frameworks (such as Spring in version
| 6.1) support virtual threads. Reactive programming (e.g.,
| Webflux) would become a niche (unless your use case truly
| requires streaming with a high number of TPS).
| sohamgovande wrote:
| Java 21 is great but every enterprise java system I've seen is
| still stuck on JDK 8
| jph wrote:
| The matching syntax looks really good to me: //
| Java 21 if (obj instanceof Point(int x, int y)) {
| System.out.println(x+y); } // Older Java
| if (obj instanceof Point p) { int x = p.x();
| int y = p.y(); System.out.println(x+y); }
| riku_iki wrote:
| Its not substantial improvement, but another invariant which
| need to be learned and adds more brain load.
|
| I hope someone will design some jvm SimpleLang eventually,
| which will have very few syntactic constructions but cover
| all/most of use cases.
| sbjs wrote:
| That was _literally the point of Java_ , to be syntactically
| and semantically simple, in contrast to the extreme
| complexity of C++. But just like with Lisp, that only moves
| necessary complexity to another layer. True wisdom in
| language design is understanding the line between necessary
| and unnecessary complexity, and perfectly incorporating
| necessary complexity into the language so users don't have to
| reinvent the wheel at the library or precompiler level.
| Blackthorn wrote:
| We're programmers. It's our job to know these things. There
| really aren't _that_ many to learn. It 's a much simpler task
| than various engineering fields.
| riku_iki wrote:
| the job is to produce software and make this process
| reliable and efficient.
|
| > There really aren't that many to learn.
|
| I think there are a lot to learn in java ecosystem.
| yazaddaruvala wrote:
| The job is to communicate effectively while producing
| software more reliably and with less time than someone
| else that might get hired.
|
| There are many of us who think Java has very little to
| learn - asking us to go slower - while probably good for
| society in general, is a losing strategy in a Capitalist
| economy.
|
| You can keep up, or be left behind. Meanwhile,
| fortunately the "communicate effectively" is 100x more
| valuable as "produce software more reliably and faster"
| ie learning all of these new languages and language
| improvements.
| maxfurman wrote:
| Sounds like Kotlin to me
| riku_iki wrote:
| in my non-expert opinion, kotlin also added bunch of
| creative, unobvious and opinionated constructs to not be
| qualified as "simple lang"
| pizza234 wrote:
| Destructuring (/pattern matching) itself is supported by
| several languages (although more in general, its flexibility
| depends on the language). It makes sense to support it in
| modern languages, as it's practical and intuitive.
|
| IMO it's a significant syntactical improvement, as it
| considerably reduces boilerplate assignments.
| riku_iki wrote:
| > It makes sense to support it in modern languages
|
| the problem is that Java not modern language, but carrying
| all legacy features from last 20 years, so having all
| legacy features + new modern creative ideas make Java very
| complex.
| unlikelytomato wrote:
| What are some examples of these legacy features?
|
| Overwhelmingly, I see complaints that java has been too
| simple compared to virtually all other languages. I agree
| that cognitive load is important. However, it feels
| really strange to me to suggest that java has reached the
| complexity of other similar languages. What am I missing?
| The_Colonel wrote:
| Destructuring is nice, but this here seems to work only in
| conjunction with instanceof which is a quite rare (and
| somewhat smelly) operator.
|
| I mean, how are you going to use it? Something like this?
| Point p = getPoint(); if (p instanceof
| Point(int x, int y)) { System.out.println(x+y);
| }
|
| ... that seems pretty bad. Or am I missing something?
| the-smug-one wrote:
| You'd do if (getPoint() instanceof ...) if you know it's
| a Point. But then, you probably don't need to deconstruct
| it anyway. You can just do p.x+p.y.
|
| This type of pattern matching is mostly useful when you
| have some T and a few cases, there is also a switch/case
| equivalent for when you've got a lot of them.
|
| Maybe we'll see some syntax for deconstructing values
| directly into variables, a la Python in the future.
| heavyset_go wrote:
| You can have a parent class/interface with many
| subclasses/implementations.
|
| You can then use pattern matching to switch on instances
| of those subclasses while destructuring objects to access
| attributes at the same time. Kind of like enums and
| pattern matching in Rust.
|
| In your example there is no reason to use `instanceof`
| with `p`, you already know what it is.
| hibikir wrote:
| The idea is that you deconstruct when a method returns a
| sum type: An interface with a defined set of implementers
| that doesn't change. A very common pattern in, say,
| Haskell or Scala. In Scala you'd also get a warning if
| you forgot to check one possible type to deconstruct. If
| you aren't defining your data types like that, yeas, it's
| a bit weird.
|
| This, along with the underscore, and even the sequence
| type, shows that the language designers are well aware of
| what Scala does, and are picking and choosing which
| things to bring in without risking exposing Java devs to
| the traditional monad salads that you see in many a Scala
| codebase.
| eastbound wrote:
| Oh yes, without the .stream()....collect(toList()) cruft!
| Just lists with .map() on them!
|
| Also without the :: operator, it's uglier than the arrow
| equivalent and it's yet-another-construct to parse.
| appplication wrote:
| I disagree. One of the major critiques of Java is how verbose
| and full of boilerplate it is. And sure, you can hand wave
| that as devs being picky, but this is a real reason people
| avoid picking up new projects in Java. The verbosity serves
| no purpose, and less code is generally better.
|
| As for there now being multiple ways to write the same thing,
| this seems like something that could be easily linted into
| consistency. So you would really only have to learn the less
| verbose way for any newer Java projects.
| piwi wrote:
| My comparison with c++ shows java is not more verbose if
| you take into account headers.
| rf15 wrote:
| I think people are very aware that c++ is a lot more
| verbose than Java. What's the advantage of making this
| particular comparison?
| riku_iki wrote:
| I actually think c++ is not necessary more verbose than
| java as a language.
|
| But memory management/safety, weaker IDE support and
| ecosystem make it less productive than Java for business
| dev.
| jimmaswell wrote:
| I actually appreciate the simplicity of bare Java. It can
| be verbose on one hand but on the other there are no
| surprises because everything is just a method call on an
| object with no operator overloading etc. Seems like they're
| kind of ruining that with bizarre things like "obj
| instanceof Point(int x, int y))". That doesn't connotate at
| all that it's calling x() on the point to get x, it looks
| like a field. Compare with C# which has a ton of
| convenience features and syntactic sugar but it's all
| intuitive and self-explanatory. Really I wish Java would go
| away and .NET would take over but it's too entrenched.
| riku_iki wrote:
| > of Java is how verbose and full of boilerplate it is.
|
| yes, new SimpleLang can have lessons learned during last 20
| years implemented, as in example from another commenter:
| https://news.ycombinator.com/item?id=37068380
|
| Currently, for a given task, Java usually have 5 legacy
| deprecated ways to solve, and two more in newish Java
| versions, and dev needs to keep all of them in memory to be
| able to read and understand other's code.
|
| > As for there now being multiple ways to write the same
| thing, this seems like something that could be easily
| linted into consistency.
|
| that's if you don't work with any legacy systems and 3p
| libraries and never switch projects/jobs
| user432678 wrote:
| Sounds like Kotlin is exactly such SimpleLang.
| lmm wrote:
| Kotlin is even worse; it's younger than Java but also has
| 5 legacy ways to solve the problem and two more in the
| newer version, it's just that the legacy ways have been
| removed so any examples you find online won't work any
| more.
| seanmcdirmid wrote:
| Ya, I'm not sure why people would use Java anymore given
| that the SimpleLang is pretty good.
| nkh wrote:
| Isn't that Clojure?
|
| (let [p obj] (if (instance? Point p)
| (let [x (.x p) y (.y p)]
| (println (+ x y))))
| Per_Bothner wrote:
| Or Kawa: (if (? p::Point obj)
| (... p:x p:y))
|
| This succeeds if obj matches the pattern p::Point,
| declaring p to be the value of obj coerced to a Point. This
| is integrated with Kawa's static type-checking/inference.
|
| https://www.gnu.org/software/kawa/Conditionals.html
| riku_iki wrote:
| I think Clojure is not statically typed? which is a big
| disadvantage, and also syntax is very different from
| current mainstream languages, so even more effort to learn
| is required.
| nkh wrote:
| When type checking is needed, I find the Truss library*
| does the trick quite well.
|
| As for the syntax, there is very little, which can make
| it a harder lift but once you have the hang of it you
| won't deal with the issues identified in the parent
| comment.
|
| * https://github.com/taoensso/truss
| The_Colonel wrote:
| I don't know what Truss is, but I know that I inherited a
| few smaller Clojure projects / services, and it's untyped
| hell. Having optional typing means most people are not
| going to use it.
| earthboundkid wrote:
| Someone (I think pg?) said that patterns are just
| insufficient language features, but the flip side applies
| too: you can apply a pattern in any language, but a feature
| is limited to what the language designers provide. Patterns
| you can learn once and write anywhere (for better or worse).
| Jtsummers wrote:
| Peter Norvig: http://norvig.com/design-patterns/ (slide 4)
| monksy wrote:
| Scala
|
| obj match { case Point(x,y)=> println(x+y) }
| diarrhea wrote:
| Very similar in Python and Rust as well.
| switchbak wrote:
| Sadly no one wants to talk about Scala any more.
| throwaway5959 wrote:
| Even for Spark?
| brap wrote:
| Thanks I hate it
| the_af wrote:
| You hate that it takes 2 lines instead of 4 (excluding curly
| braces) to accomplish the same? The new syntax is not even
| convoluted, it's pretty intuitive destructuring syntax
| already available in many modern languages.
| coding123 wrote:
| What is it saying here. Is the (int x, int y) from getters or
| the constructor? It LOOKs like a constructor, but I can't
| possibly imagine it's doing anything with the constructor in
| this call....
|
| Which probably explains the person saying "I hate it".
| trealira wrote:
| And that "older Java" example itself is an alternative (added
| in Java 16, from looking it up) to what existed before.
| if (obj instanceof Point) { Point p = (Point) obj;
| int x = p.x(); int y = p.y();
| System.out.println(x + y); }
| klysm wrote:
| Pretty much the same as C#
| LatticeAnimal wrote:
| The syntax for the string template surprised me. Are there other
| languages that use a `STR.` prefix to indicate string formatting?
| papercrane wrote:
| It kind of reminds me of JS tagged templates syntax.
|
| https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
| TrianguloY wrote:
| Python requires a prefix too f"{x} + {y} = {x+y}". I guess you
| can now almost simulate it by using f."\\{x}...".
|
| The new java way is strange, but maybe it was to avoid having
| to touch the language parser too much.
| mdaniel wrote:
| the Java one is _pluggable_ , whereas if one wanted to
| implement the cited PreparedStatement-strings in Python it'd
| be a parser bump since there is no `sql""` in the grammar
| TrianguloY wrote:
| What I wanted to mention is that maybe (although probably
| not possible with the current grammar) an alternative would
| have been to remove the dot. STR"x=\{x}"
| munificent wrote:
| The "STR" isn't syntax, it's the name of template processor the
| user has chosen to process that template.
|
| Users can define their own template processors to control how
| the interpolation behaves: sanitize inputs, etc.
| The_Colonel wrote:
| > Users can define their own template processors to control
| how the interpolation behaves: sanitize inputs, etc.
|
| This part honestly seems like overengineering. Like Java
| architects resisted operator overloading for decades, and now
| they pull off this in the first version of templated strings
| ...
| paulddraper wrote:
| I disagree.
|
| This has existed in JavaScript and Scala for years, and is
| a very useful feature.
|
| Like for SQL queries: sql`SELECT * FROM
| account WHERE name = ${name}`
| The_Colonel wrote:
| Java is a much more conservative language than either
| JavaScript or Scala. It seems like almost DSL-like
| feature which is very uncharacteristic for Java.
|
| Personally I write JavaScript daily, and I've never seen
| this feature being used.
|
| Even this example - will this create a prepared statement
| or insert a correctly escaped value into the SQL string?
|
| Either way this seems pretty niche. Are there some major
| use cases for it?
| paulddraper wrote:
| > Personally I write JavaScript daily, and I've never
| seen this feature being used.
|
| I see it be used for SQL specifically in loads of
| projects.
|
| https://www.npmjs.com/package/sql-template-strings
|
| https://www.npmjs.com/package/squid
|
| > will this create a prepared statement or insert a
| correctly escaped value into the SQL string?
|
| Always prefer server-side parameterization. If you are
| referring to java.sql.PreparedStatement specifically,
| that requires a connection, so this is only an
| intermediate value to creating that.
| mdaniel wrote:
| Python does so via its "f-strings":
| https://docs.python.org/3/reference/lexical_analysis.html#fo...
| although as the link implies, that's done at the grammar level,
| and not via a static field that is a StringTemplate.Processor
| as it is in Java https://openjdk.org/jeps/430#The-STR-template-
| processor
| xwowsersx wrote:
| I don't believe so.
| theandrewbailey wrote:
| > Java collections don't have a type representing an ordered
| sequence of elements, Java 21 fills this gap by introducing the
| SequencedCollection, SequencedSet and SequencedMap interfaces.
| These interfaces provide methods for adding, modifying or
| deleting elements at the beginning or end of the collection, as
| well as for iterating over a collection in reverse order.
|
| That sounds like a deque, and it's been in Java for a long time.
| (No set or map implementations though.)
|
| https://docs.oracle.com/en/java/javase/18/docs/api/java.base...
| [deleted]
| joaonmatos wrote:
| Some of the methods were explicitly lifted out of the Deque
| into this interface. Basically the aim of the new interface is
| to provide an unified experience and standard methods to all
| the collections that can feasibly support it.
| whalesalad wrote:
| For those in the ecosystem these days - is there a compelling
| reason to choose Java over Kotlin? I am under the impression that
| Kotlin is a better Java without any sacrifices. Is this true?
| mardifoufs wrote:
| At this point I think the more relevant question is: is there
| any point to using kotlin if you are not doing android dev?
| afavour wrote:
| Personally I find it more enjoyable to code in than Java.
| There's also maybe an argument to be made around Kotlin
| Native, KotlinJS too.
| robertlagrant wrote:
| Also Kotlin Multiplatform.
| xwowsersx wrote:
| Sure, assuming you are happy with most of the language
| constructs and it feels ergonomic to you, Kotlin can make
| sense for backend/APIs, while still having access to all the
| Java libs/packages. I'm starting several new largeish
| projects now and have decided on using Kotlin.
| mdaniel wrote:
| Having `@Nullable`/`@Nonnull` (or its dumb `Optional<T>`
| friend) is nothing compared to NPE being a compilation
| failure
|
| Also, all hail `val`; `final var` is objectively worse
| iraqmtpizza wrote:
| var is write-only and won't catch type errors
| exabrial wrote:
| Better is subjective. Java is a great language, has a mature
| and stable codebase, it runs at near-Cpp speed, has built-in
| SNMP-like monitoring, and the developers are super careful
| about not breaking backwards compatibility. That's all about
| there is to say about it. Kotlin is also a good language for
| many of the same reasons, mainly because it is run on the JVM.
| One really isn't better, they're just different. Use the tool
| you know how to use, and master it.
|
| The only category I would say is objectively "better" is Java
| (and other JVM languages like Kotlin) has the best IDEs out of
| _any_ language. There is nothing on-par for Python, Ruby,
| C/Cpp, etc as far as autocompletion, type inference, automated
| refactoring, partial recompiles, hot code swapping, unit test
| integration, Tomcat or server integration, code formatting,
| etc. Java is great because of it's IDEs. If we were writing
| Java in notepad.exe it'd be a pretty clunky experience, but
| nobody serious does that.
| ebiester wrote:
| AFAIK, most people using Kotlin are somehow tied to some
| variant of Java 8, such as Android. Kotlin is very useful for
| that use case, but otherwise was a useful kick for Java but I
| don't know if I'd start a new project in it.
| The_Colonel wrote:
| Java still has no counterparts to many important Kotlin
| features - number one being null safety. Java is not even
| trying to address it (no, JSR305, checker framework,
| Optional are not solutions).
| cogman10 wrote:
| > Java is not even trying to address it
|
| Valhalla might. There's been a lot of time put into nulls
| and primitives for valhalla. How that manifests seems to
| be up in the air still. But I would not be surprised to
| find non-nullable types in the future (like `int`).
| randoglando wrote:
| > The only category I would say is objectively "better" is
| Java has the best IDEs out of _any_ language.
|
| Kotlin was made by the people behind IntelliJ. I'm not sure I
| understand your point.
| exabrial wrote:
| sorry, I should have included Kotlin in that part of my
| comment. IntelliJ Kotlin is quite incredible. Every time
| I've needed to use it, my expectations have been met.
|
| Makes switching to vscode feeling going from an framing
| nailer to beating in rusty iron nails with a rock.
| iraqmtpizza wrote:
| extension functions can be scattered across any number of
| files and the import statements do not tell you where
| they are declared. kotlin was specifically designed to
| drive sales of IntelliJ
| coldtea wrote:
| That's a single IDE from a single vendor though.
| wiseowise wrote:
| And it's slow as molasses without feature parity.
|
| One feature that comes to mind is rearrange methods. I
| haven't used Java in years so someone who actually uses
| both can find more cases where Kotlin support is worse than
| Java's.
| nikanj wrote:
| The developers absolutely wrecked backwards compatibility by
| shuffling classes between namespaces just a few years ago. I
| guess the new names are somehow better, but so many things
| broke because things needed renaming For Reasons
| CraigJPerry wrote:
| Yeah the backwards compatibility point is overplayed i
| think. It is mostly true but The java world paused at 8 for
| a hair too long and when it came time to move to 11,
| workarounds were needed for things like JavaEE and JavaFX
| being removed.
| jiggawatts wrote:
| While I miss IntelliJ IDEA, I've found Visual Studio has
| mostly caught up for C# refactoring. If that's not enough for
| your use-case, there's always the Rider plug-in.
| fiddlerwoaroof wrote:
| I've always viewed this the opposite way: Kotlin isn't better
| enough to prefer it to recent Java versions.
| randoglando wrote:
| Kotlin is less verbose, has better null safety and mutability
| is clearer.
| vips7L wrote:
| Those just are not enough for many of us to warrant the
| switch. Mutability is fine if you're not going over thread
| boundaries, many of us don't struggle with null, and
| brevity does not always equal clarity.
| The_Colonel wrote:
| > Those just are not enough for many of us to warrant the
| switch.
|
| I understand that, but for starting new projects the
| equation can be different.
|
| > many of us don't struggle with null
|
| Sorry, but I don't believe there's anybody like that. I
| guess many people accepted/internalized the struggle.
| ivan_gammel wrote:
| Null safety at application level is just a good
| architecture, test coverage and regular code reviews. It
| is not an internalized struggle of any sort. Last time I
| saw uncaught NPE in server logs was a long time ago: why
| would it necessarily be more frequent than some data
| validation error?
| hibikir wrote:
| I have worked at over a dozen companies where they were
| using Java. I have yet to see one where null checks and
| error handling thanks to said null checks doesn't occupy
| a significant percentage of the application. Maybe I am
| unlucky, or maybe you've done so much Java now you don't
| even read the null checks and attached error handling
| everywhere.
| fiddlerwoaroof wrote:
| I've never found that the differences of Kotlin matter
| enough to be worth it.
| richbell wrote:
| Kotlin also has a better standard library and collections.
| jasmer wrote:
| [dead]
| DarkNova6 wrote:
| Which platform?
|
| For Android? Kotlin all the way.
|
| Servers? Java is much closer to the JVM and Kotlin is an
| abstraction over it which honestly does not provide much extra
| compared to Java 21.
|
| Kotlin has several design decisions which are neater 80% of
| time, but Java is the better general purpose language for those
| 20%. OC, much is a matter of taste. And in Kotlin will find
| yourself in awkward positions where you have to use Java
| Collections and you lose all the advantages of Kotlin (HashMaps
| not having non-nullable values is one of them).
| adra wrote:
| All kotlin collection types are essentially Java ones (at
| least for a JVM target), the difference is that the IDE and
| compiler are smart about its type inference system so that it
| can tell when a variable use is nullable or not.
|
| Java has come a long way in recent years and it's far better
| than it was in the past. Kotlin stands on the great baseline
| of features that Java has established and there are certainly
| many advantages to (mostly ergonomics), to using Kotlin over
| Java at least for the time being.
| eweise wrote:
| Java is still pretty ugly when you have to use the functions
| api https://docs.oracle.com/javase/8/docs/api/java/util/funct
| ion.... I don't know why they can't make it like kotlin and
| scala where you just can just type the function definition
| instead of trying to find a class that represents what you
| want. This streams API for example, is unreadable.
|
| <R> R collect (Supplier<R> supplier, BiConsumer<R, ? super T>
| accumulator, BiConsumer<R, R> combiner)
| dullcrisp wrote:
| > HashMaps not having non-nullable values
|
| Not sure about that example since it's easy to do
| class MapWithDefault<K, V>( private val map: Map<K,
| V>, private val defaultValue: V ) {
| fun get(k: K) = map.get(k) ?: defaultValue // ...
| }
|
| Edit: or I'm sure there's something that does this already.
| jayd16 wrote:
| It's probably about having to box value types.
| DarkNova6 wrote:
| Still, this is not a first-class citizen in the Kotlin
| space, even-though you would assume it to be the case.
| Introducing such custom classes is always a little icky
| when working in a team.
| derriz wrote:
| Some reasons that spring to mind:
|
| - Compile speed - Kotlin is still painfully slow - about 4-5
| times slower than equivalent Java functionality (rough
| estimate)
|
| - Kotlin is completely proprietary, no community or openness,
| no alternative to Jetbrain's IDE
|
| - Kotlin (for me) has passed from being a simpler/more
| terse/attractive version of Java into being a complex language
| with lots of strange corner cases. Particularly largish Kotlin
| code-bases can be hell to read as Kotlin supports and
| encourages a DSL like approach.
| wcerfgba wrote:
| Isn't Kotlin licensed as Apache 2?
| cempaka wrote:
| Java's structured concurrency approach to async code eventually
| may result in much simpler libraries compared to Kotlin's
| approach, which introduces function coloring with the "suspend"
| modifier.
| wiseowise wrote:
| https://elizarov.medium.com/how-do-you-color-your-
| functions-...
|
| That's a feature, not a bug.
|
| > We could eliminate suspend modifiers from pure-Kotlin code,
| but should we? I'm inclining to answer no. Having to mark
| asynchronous functions with suspend modifier is a small price
| to pay, but in return you get better insight into your code.
| You immediately see which functions are allowed to perform
| potentially long communications and which are supposed to
| complete quickly.
| coldtea wrote:
| Using Java means going with the less fuss default
| (instrastructure and support) wise. And the gap is closing in.
| smokel wrote:
| One of the most interesting things with respect to the future
| of Kotlin is its mission to be a multi-platform language.
|
| When WebAssembly/gc becomes generally available, it will be
| exciting to see which languages will successfully target it.
| Kotlin has quite good chances of succeeding as a full-stack
| language, because of its growing ecosystem of multi-platform
| libraries that work in the JVM, in a browser, and on a native
| system. Note that the Java standard library is great, but it
| does not interoperate well with the JavaScript ecosystem. The
| same goes for C# and Rust.
|
| As a personal pet project, and to check if the multi-platform
| concept actually works, I have written an emulator for an old
| computer in Kotlin. Initial development was done in the JVM,
| because I was familiar with JavaFX and sound output in Java. I
| then later compiled it to JavaScript, which was trivial and
| required _no_ code changes, except for an implementation of
| canvas and audio rendering.
|
| A serious problem is the IDE experience though. Interactive web
| development in VSCode with TypeScript is a breeze, with a
| subsecond edit-compile-run cycle. Kotlin compilation is still
| clunky, and fixing a typo requires at least 10 seconds of my
| patience, even on a decent workstation. Work is underway to
| improve this, but only time will tell if things succeed.
| geodel wrote:
| Its better _without sacrifices_ similar ways as :
|
| 1) Cloud is better than data centers without sacrifices
|
| 2) Meal kits are better than grocery shopping without
| sacrifices
|
| 3) Online shopping is better than going to store without
| sacrifices
|
| 4) SAAS is better than locally installable software without
| sacrifices
| lmm wrote:
| Kotlin has a less good backward compatibility record and
| interacts awkwardly with newer JVM/standard library features -
| e.g. streams are cumbersome to work with because Kotlin has a
| different approach to absence/nullability. Async in particular
| is a place where Kotlin has gone through multiple incompatible
| rewrites and is doing something that's not necessarily going to
| align with the JVM way of doing things in the future (Project
| Loom - which I have my own doubts about, but if you believe in
| it then that's definitely a reason to use Java over Kotlin).
|
| (Plus if you're going to go to the trouble of using a non-Java
| language it would be a real waste to use Kotlin over Scala)
| crickey wrote:
| I mean what are your goals, its never as clear cut as X is
| objectively better in all use cases over Y
| smallerfish wrote:
| I still prefer Kotlin, though the gap is closing. Null
| checking, extension functions, type inference, and various
| other features are really nice.
|
| I'm not sure what's on the Kotlin roadmap / whether JetBrains
| see value in making major improvements to the language.
| softwaredoug wrote:
| > JEP-448 - Vector API: sixth incubation of this feature. This
| new version includes bugfixes and performance improvements.
|
| Rant:
|
| JFC Java, its 2023 and people use Java to run actual databases
| and develop machine learning infrastructure. Yet the ability to
| do SIMD in the JVM is on its _sixth_ incubation.
| the-smug-one wrote:
| That's because they want to get it right. The same with
| Valhalla. The same with Loom.
| marginalia_nu wrote:
| I'd rather have a good API late than a bad API early in a
| language as committed to backward compatibility as Java.
| spockz wrote:
| It remains a bit bitter sweet to see that so many features that
| we've had for 13+ years in Scala and longer in languages like
| Haskell and were ridiculed back then, now find their way to
| mainstream Java.
| oh_sigh wrote:
| On the flip side, how many features are in those languages that
| java benefited from _not_ introducing?
| lmm wrote:
| I can only think of XML literals (which Scala did eventually
| manage to remove) and the first version of value types. (Plus
| some new things in Scala 3 which time will tell about). From
| Haskell maybe Python-style list comprehensions (Haskell has
| two sets of syntax sugar for using monads more easily and
| Python took the bad one).
|
| Pretty poor tradeoff on the whole if you ask me - but Scala
| is always there for anyone with enough sense to pick it up.
| zokier wrote:
| Ridiculed? Really?
| the-smug-one wrote:
| I'm sure you can find a flame war or three about pattern
| matching. Oh boy, the threads you'd have 10 years ago about
| this stuff.
| lmm wrote:
| Yes, ridiculed. E.g. someone posting (presumably trolling)
| /r/scala today: "I just wonder how can people think something
| as arcane and absolutely out of this world as the typelevel
| stack or ZIO can have a place in the industry."
| earthboundkid wrote:
| The only Haskell feature I can think of people ridiculing is
| laziness, which makes sense because it sucks and makes
| performance hard to reason about.
| earthboundkid wrote:
| Oh and burritos. Burritos are funny.
| the_af wrote:
| They only ridicule it because they don't use it or
| understand it.
|
| Laziness by default is my favorite Haskell feature.
| BaseballPhysics wrote:
| So you've never had a space leak? Be honest...
| the_af wrote:
| I've seen lots of things and problems in languages both
| with and without lazy evaluation.
|
| On the whole, I like it in Haskell. In languages without
| lazy evaluation (by default) I tend to miss it.
|
| I've never seen it "ridiculed" by anyone proficient with
| the language or who used it for an actual project,
| either.
| BaseballPhysics wrote:
| Great non-answer.
| monksy wrote:
| This feels like Option/Optional all over again.
| augustk wrote:
| I also wonder if perfection is reached when there is nothing
| more to add ;-) Current popular languages seem to converge.
| wongarsu wrote:
| One major upside of newer languages like rust is that they
| can start out with these "newer" primitives, with a standard
| library designed around them and without tons of "legacy
| primitives" that do the same thing, but worse (like how
| python has 4+ distinct ways to print a string with variables
| in it, all in various degrees of popular use).
|
| Once your language has aged a little it's hard to impossible
| to take old primitives away, but you still want to adopt
| ergonomic improvements in order to not be left behind. Until
| at some point you become a language nobody can master in its
| entirety.
| _a_a_a_ wrote:
| They seem to be converging on Scala :)
| clhodapp wrote:
| They're converging on Kotlin, but of course 75% of the
| difference between Java and Kotlin consists of Scala
| features that have been laundered of their dirty "academic"
| origins for acceptance in polite industry.
| speed_spread wrote:
| And it'll be another 5 years before JDK21 becomes a widespread
| target for production and then another 5 years for the new
| features to be accepted in code reviews. Culture changes
| slowly.
___________________________________________________________________
(page generated 2023-08-09 23:01 UTC)