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

261–270 of 358 posts

Re: New language features since Java 8 to 17

#261

Post by frant-hartm »

jmfldn wrote: post #136
hota_mazi wrote: post #100

Earlier quoted context omitted.

Interestingly, I have the exact opposite opinion. Scala has been declining steadily for a decade now, and Scala 3 is going to precipitate this state of affairs by splitting the shrinking community even further. Kotlin, on the other hand, has done nothing but grow for the past five years, no doubt helped by Google's formidable support for it. I just took a quick look at one of its Slack channels, "getting-started", an…

It's not in decline imho, it has settled as middle ranking language in terms of popularity and is v popular in its niche. It depends where you are of course but in London it's used in loads of places from major corporations to startups. The market is hot.

I used to contract in London, I still occasionally get info about contracts from recruiters, Kotlin largely replaced Scala, compared to 5 years ago.

Re: New language features since Java 8 to 17

#262

Post by cageface »

jpgvm wrote: post #56
jmfldn wrote: post #41

Earlier quoted context omitted.

Hmm yes I guess you might be right given Android. It's a shame in a way that Kotlin was invented as Scala could have filled the niche too imho but that ship has sailed. It's too similar to both Java and Scala and doesn't really bring anything new to the table. Is that fair or does it have a great USP other than massive Google backing?

I don't think Scala ever could have filled that niche, I say this as someone that wanted Scala to be successful. The truth of it is that Kotlin is incredibly easy to learn, even for non-Java devs. It is definitely focused on a very low barrier to entry. I don't think this was an original goal but it's become a significant focus of the language especially after being selected to be the next platform language for Andro…

Which big companies are adopting Kotlin on the backend?

Re: New language features since Java 8 to 17

#263

Post by fulafel »

pron wrote: post #160
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…

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

Question from a non Java programmer, where can I read more about algebraic data types in Java? The article doesn't mention the term.

Re: New language features since Java 8 to 17

#264

Post by nlitened »

hota_mazi wrote: post #122
sgt wrote: post #45

Earlier quoted context omitted.

Yeah I think most Java devs are a bit in awe of Clojure, just not sure about the leap needed to get there.

Anyone who values static typing will never be in awe of Clojure. Or any dynamically typed language, for that matter. And Java developers care a lot about static typing.

> Anyone who values static typing will never be in awe of Clojure

I used to value static typing, then I got older.

Re: New language features since Java 8 to 17

#265

Post by 66fm472tjy7 »

pron wrote: post #160
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…

Thank god for that, because those feature are either horrible on their own or superseded by better ones. You're getting a car and complaining for not getting faster horses. The features Java has adopted -- specifically, algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.

  those feature are either horrible
I speculate that most users of languages that have these features (Kotlin has all of them) would be unhappy if you took them away.

  algebraic data types and pattern-matching -- will lead to better development practices, rather than making it easier to work with inferior ones.
I am not arguing against those features, but the ones I asked for seem easier to implement by comparison as they are already in other successful JVM languages. Furthermore, they are far more frequently useful for my use case of web services storing, transforming and moving data around, often without caring too much about their semantics. I speculate that a large portion -probably a majority- of JEE/Spring devs are in the same position.

I am disturbed by how universally true you seem to consider your positions - as if there were no cases in which mutability is preferable to immutability (even if that is sometimes just due to the way some ORM or serialization library works).

If these features are such bad ideas there should be plenty of stories of Kotlin/C# devs cursing the language for providing them with these footguns.

Having a JDK dev respond like this only strengthens my argument that cageface has no reason to fear that Kotlin will lose steam - Java has different priorities. There is nothing wrong with that, but more developers who want these features should be aware that they will not be getting them from future Java versions.

Re: New language features since Java 8 to 17

#266

Post by jamesfinlayson »

abraxas wrote: post #214
dunefox wrote: post #175

Earlier quoted context omitted.

> seems to be antithetical to the principles of a strongly-typed language. So does this now reclassify Java as a weakly- or dynamically-typed language? Var and type inference are neither antithetical to static typing nor do they make a language dynamically typed. They're antithetical to the verboseness of Java.

Except that having the type info is really, really useful at the call site. I know the IDE is able to infer it and display it but it's still a pain to see all the vars during a code review in a browser.

Yeah I'm not sure where this originated (recent C++ has something similar with auto and I think C# now has var as well) but if I'm doing a code review rather than writing code in an IDE, var is a bit of a hindrance.

Re: New language features since Java 8 to 17

#267

Post by netvl »

filoeleven wrote: post #252
riwsky wrote: post #241

Earlier quoted context omitted.

I’ll gladly grant that the mutable date types of pre-jdk8 Java were ugly APIs, but you’re still missing my point here: the LocalDate class was added in the same release as Instant was—it’s not a worse Instant, it’s solving a different problem.

I guess what I’m aiming for (and perhaps not hitting the mark with) is that LocalDate’s 9 static constructors should be reduced to a single constructor that takes an Instant. If Instant does some translation from “whatever -> Instant”, it should do all the translation. If you want something like a birthday, you’re already making assumptions about the beginning and end of that day. Ask a 21-year old from Australia abo…

The whole point of a local date is that it is just a container for three values - year, month and day, and nothing more than that. You cannot go from `Instant` to `LocalDate` without specifying time zone/offset information, and vice versa.

“Local date” is a useful concept on its own, and it is not at all always derived from an absolute instant of time. Some examples:

1. Date in a file/directory name, which often happens with big data processing. There is no way to tie these dates to some absolute frame of reference without external information, but it is often not really necessary, and there is still a need to work with these values as dates, e.g. compare them or compute offsets.

2. Anything which is tied to the user’s local time frame, e.g. alarms. They simply cannot be tied to some absolute time reference, because they always represent some time wherever the user is located right now. Even birthday is something like this, because for the purposes of celebration, people care about the specific calendar day, not the actual moment of time in whatever absolute time scale there is (at least, most of the people I know think like that!)

Re: New language features since Java 8 to 17

#268

Post by aww_dang »

grishka wrote: post #107
weatherlight wrote: post #95

Java sucks, and should stop being taught as the defacto language in computer science curriculums. It's extremely busy and verbose. There are better OO languages out there, if the point is to teach OO. (I'm ready for this post to get downvoted into oblivion)

Being verbose is a plus. I really really really hate the terseness of Kotlin and how it's basically unreadable without an IDE. Languages should be dumb. Standard libraries should be smart. Not the other way around. The number of syntax constructs that generate standard library calls when compiled should be minimized as much as possible. Edit: one more thing, operator overloading is extremely harmful for readability.

I like verbosity. I like knowing what I am getting. I like explicitly specifying the defaults, rather than assuming or having the details buried in the documentation.

Solving problems and formulating a problem solving approach takes time. This is the important part of writing software. A few extra keystrokes are relatively minor in comparison.

"I want to write software, but I don't want to type too much", never made sense for me.

Re: New language features since Java 8 to 17

#269

Post by xxs »

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…

PowerMock is a mistake on its right own; I outright reject pull requests if anyone attempts writing unit tests that need modification of final state.

Re: New language features since Java 8 to 17

#270

Post by goto11 »

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…

You shouldn't need to mock a sealed class in the first place. Consider them like a more powerful enum or an algebraic data type.

You wouldn't mock en enum either (hopefully).

Post reply on HN