Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

Post reply on HN
Print view View original

351–358 of 358 posts

Re: New language features since Java 8 to 17

#351

Post by fulafel »

The_Colonel wrote: post #54
manishsharan wrote: post #25

Whenever we read about new improvement in Java,it is always inevitably followed by concerns for viability of Kotlin or Scala. However these concerns are never applicable for Closure. I am glad I went all in on Clojure.

It's not applicable, because Clojure already lost the momentum and sinks deeper and deeper into its niche.

I don't think Clojure was ever growing at a huge clip, but it seems to be doing about the same as Scala, see eg the pie at https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-b...

Kotlin is just Java with improvements and it has major corporate push from Google, so it's natural for it to ride the big volumes.

I think long term Clojure is going to keep doing well, despite modest pie slice of JVM dev, because lots of people continue to prefer its simplicity + dynamic FP + unique approach to data, plus the excellent ClojureScript side, and it doesn't really have competition or alternatives on the JVM (unlike Scala, where Kotlin/Java are co-opting features).

Re: New language features since Java 8 to 17

#352

Post by moffkalast »

aldanor wrote: post #176
moffkalast wrote: post #125

Earlier quoted context omitted.

Until your LTS OS gets to end of life and you need to switch to the next one which conveniently deprecates old python versions so you have to rewrite everything.

Why use system Python base environment for production stuff, especially knowing that it will EOL eventually and mayhem may follow? Again, pin your environments using conda, pipenv or whatever else, in which case your base Python version wouldn't matter.

Well if you're using ROS, you get to choose between the two extremes of C++ or Python. It would be great if everything was in C++ to be sure, but ain't nobody got time for that, especially not the cheap results-quickly company I work at.

Re: New language features since Java 8 to 17

#353

Post by filoeleven »

kaba0 wrote: post #296
filoeleven wrote: post #166

Earlier quoted context omitted.

> Languages should be dumb. Standard libraries should be smart. Not the other way around. This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures. Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: i…

That is data. Not every problem is fundamentally about data though — the special case you mention may very well be the whole problem domain. Eg. what percent of data does a compositor work with vs state-holding objects with proper structures like WindowLayoutEngine and the like?

I’m not familiar with compositors, so unfortunately I don’t have a ready answer, only more questions.

What makes a WindowLayoutEngine “a state-holding object with proper structures?” How is it different from “a data tree with proper structure,” except that the former includes methods inside the class instance while the latter relies on functions to operate on the data tree?

Re: New language features since Java 8 to 17

#354

Post by karmakaze »

karmakaze wrote: post #181
pharmakom wrote: post #102

Glad to see Java improve, but I still would like to see more ML features: - ~Exhaustive pattern matching~ it’s here! - Algebraic data types - Tail call optimisation - Do notation - Operator overload Why not use another language? Well, the name “Java” guarantees buy-in at this point. Maybe it will eventually be a Trojan horse for ML :)

The unfortunate stance on ADTs is that Java doesn't want them generalized. The standard answer is use Records and Sealed classes. What does this mean? Well with generics we can have two libraries that know about Map and concrete types TypeA and TypeB and can interface type-safely using Map . What we can't do is have two libraries that know about TypeA and TypeB interface type-safely using a sealed type of TypeA and T…

I've been thinking about the lack of ad-hoc SumTypes in Java. The sealed class approximation isn't good enough. I'm seriously considering taking up TypeScript in earnest as my 'go to' language. It's an outlier in supporting A | B | C and being mainstream with pretty good runtime performance.

One thing I'd have to check is the quality of IDE support for refactoring tooling. Refactoring operations for Java using IntelliJ almost always works and as I expect or better.

Re: New language features since Java 8 to 17

#355

Post by qw »

dmitriid wrote: post #322
pron wrote: post #320

Earlier quoted context omitted.

Easier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it). > And don't get me started on array vs list vs collections none of which are compatib…

> Easier construction for records will come to Java. Once again: when? And why only records? Why does everything in java require someone to manually create an .of method, or create 15000 setter methods or generate those 15000 setter methods? > This is not true. Lists are collections, and while arrays are different, I remember running into an issue with the difference, but can't remember now. Quite possible it was an…

I know it's probably to late to add any value to the discussion, but you can write this in Java;

    var list = List.of("carrot", "fox", "explorer")
You are right about the builder, but most projects I have worked with use Lombok and the @Builder annotation to generate the builder automatically. I agree that a native syntax for this would be better.

Re: New language features since Java 8 to 17

#356

Post by int_19h »

Jweb_Guru wrote: post #238
p2t2p wrote: post #212

Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…

Without sealed classes it's impossible to enforce most interesting invariants. If anything the other way is a mistake.

IMO sealing for classes is unnecessary, so long as methods are opt-in for overriding (e.g. as in C++ or C#, where you need to explicitly say "virtual"). If you can't override anything in a derived class, how can you break invariants?

Re: New language features since Java 8 to 17

#357

Post by int_19h »

pron wrote: post #336
dmitriid wrote: post #332

Earlier quoted context omitted.

> Their focus seems to have shifted to TypeScript C# 9 has more features in the release (one year after the release of C# 8) than java had in the past five years. Whatever "seems" to you, it clearly isn't true. > > It won't, not for another ten years. > You're very wrong about that. Remember that only five years ago, Java didn't have var, didn't have switch expressions, didn't have text blocks, didn't have records, d…

> C# 9 has more features in the release (one year after the release of C# 8) than java had in the past five years. Not even close. They're adding small features to the language, while Java adds huge features to the runtime. .NET is 10-15 years behind Java on the runtime. Roughly speaking, Java's philosophy (going back to Gosling) has been to innovate on the runtime and keep the language conservative, while .NET's has…

Are you saying that e.g. pattern matching is a "small feature"?

As far as runtimes... CLR bytecode is expressive enough to compile C++ into it. Try that with JVM.

Re: New language features since Java 8 to 17

#358

Post by int_19h »

throwaway2037 wrote: post #230
66fm472tjy7 wrote: post #59

Earlier quoted context omitted.

I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collection…

Re: Properties: What is the gain? What is the "pain point"? More typing? Can you share a language where you feel properties is a significant gain? (C#?) Re: Streams API that allows checked exceptions. Brian Goetz has written about this issue. (Search StackOverflow.com) They did not allow because of the optionally parallel (threaded) nature of streams. If multiple parallel streams throw an exception, when/when/where/h…

> Moving exceptions across thread boundaries is a tricky thing in any language.

Not really. C++ has std::exception_ptr for that exact reason, and C# has ExceptionDispatchInfo. Both are very straightforward - you catch the exception, get a handle for it, and then re-throw that handle in another context, with original stack trace preserved.

Multiple concurrent exceptions is also a solved problem. In C#, if you do something like Task.WhenAll(), and one or more task throws, you get back an AggregateException, which can be inspected to see which task threw what. The same can be applied to async streams.

Post reply on HN