Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

81–90 of 358 posts

Re: New language features since Java 8 to 17

#81

Earlier quoted context omitted.

This reads like, "VisualBasic already has everything you need for pointers. You can define your own classes and pass by reference."

Not sure what you mean, sorry? Are you just objecting to the verbosity of method calls over operators? Yes it's a bit annoying, but the functionality is all there.

It is very easy to mess up signed with unsigned then - because they are the same static type. You have to put comments in the code to clarify the interpretation of bits.

Re: New language features since Java 8 to 17

#83
post #61
post #56

Earlier quoted context omitted.

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…

I hear this a lot about Scala, and I am a Scala dev so maybe I'm biased, but I don't get the difficulty angle particularly. I'm in no way exceptional as a programmer or IQ-wise but I picked up Scala easily as part of my first job. The difficulty thing doesn't compute to me but it could just be that I'm well-suited to the language. It works beautifully as a better Java if that's how you wish to use it. Granted, it mig…

The first time I tried Scala, I got a type error based on the result of an implicit conversion, which succeeded locally but not for the entire expression. It took me a while to figure out what had happened. Advanced (mis) features such as this combined with encoding everything into objects with subtyping make Scala very complex. F# and OCaml are examples of much simpler languages that have most of the advantages (albeit no JVM).

Re: New language features since Java 8 to 17

#84
post #77

Earlier quoted context omitted.

If you're on Android I'd be programming in Kotlin in any case.

Shameless plug: I recently wrote a blog post on Java 17's new features using the implementation of a tiny actor runtime as the running example. If you are interested you can find it here https://evacchi.github.io/java/records/jbang/2021/10/12/lear...

Apparently I mistakenly posted this as a reply...

Re: New language features since Java 8 to 17

#85
post #42

Earlier quoted context omitted.

reading and processing bytes mostly. Many people get confused due to the need of bitwise and, yet even if that would be removed I can't quite see the intrinsic benefits, given how difficult would be having another primitive type.

So, when processing bytes, can you name an operation where the existence of an unsigned type would even make a difference? I'm still not seeing it.

Java bytes are signed. They aren't useful when working with unsigned 8-bit values (say, a scaling factor or an index in whatever binary format you are trying to parse). You need a larger integer type, and indeed that bitwise and operation to get the range of values you need.

Re: New language features since Java 8 to 17

#86
post #44
post #30

Earlier quoted context omitted.

Because plenty of people judge Java by their pre-Java 8 frozen knowledge. At least it isn't yet another link to re-written in Rust headlines.

I must be in the minority of thinking java 7 was the last great version of Java. What I see today is a nearly different language.

I liked Java 1.4. Generics were a mess. And Java before generics was so wonderfully simple. Yes, you had to cast, but that wasn’t a big issue.

My favourite language would be Java 1.4 with carefully redesigned standard library (because old standard library was not very nice).

Re: New language features since Java 8 to 17

#87
post #44

Earlier quoted context omitted.

I must be in the minority of thinking java 7 was the last great version of Java. What I see today is a nearly different language.

Honestly, I don't see anyone using any of the new features. Oddly enough I do get asked about them in interviews.

This just makes me hate interviews even more. Why ask questions that are supposed to be looked up anyway, or once used, are known? I mean, certainly if you saw a new feature being used in a codebase at that workplace then you would be able to use it, too.

I probably would not be able to answer it with regarding to Kotlin, for example, but I would certainly be able to notice (or at the very least look it up), understand, and use. Would it make me fail the interview?

Re: New language features since Java 8 to 17

#88

Earlier quoted context omitted.

Not sure what you mean, sorry? Are you just objecting to the verbosity of method calls over operators? Yes it's a bit annoying, but the functionality is all there.

It is very easy to mess up signed with unsigned then - because they are the same static type. You have to put comments in the code to clarify the interpretation of bits.

So yes it's also error-prone. But there's no overhead, as the original comment implied.

Re: New language features since Java 8 to 17

#89

Earlier quoted context omitted.

It would sure be helpful if they took some effort to focus less on adding crazy new stuff every 2 days and instead on maintaining older versions for a change. Maintaining a python dependant system these days is an absolute nightmare, at least with C++ you know that new compilers will be backwards compatible, gah.

How does this feel with Python being dynamic? I always felt very uneasy writing Python precisely because if some random module became incompatible, especially via a transitive depndency, I might not find out until it was running in production.

What's to be uneasy about? Lock your environments, pin your dependencies, especially in production.

Re: New language features since Java 8 to 17

#90
post #61
post #56

Earlier quoted context omitted.

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…

I hear this a lot about Scala, and I am a Scala dev so maybe I'm biased, but I don't get the difficulty angle particularly. I'm in no way exceptional as a programmer or IQ-wise but I picked up Scala easily as part of my first job. The difficulty thing doesn't compute to me but it could just be that I'm well-suited to the language. It works beautifully as a better Java if that's how you wish to use it. Granted, it mig…

It's difficult because the language is gigantic compared to Java, it has all the OOP bits Java has (and Scala needs in order to be relevant) then a whole bunch of FP stuff on top. This is a lot for newer programmers and while they might be able to do "hello world" equally quickly I do feel like they soon hit a wall of "I don't understand why this works" when looking at idiomatic Scala.

It can be used as a better Java but requires discipline. Things like implicits can easily cause an unnecessary amount of pain. Kotlin on the other hand implemented extension methods in a way that doesn't detract from the better Java paradigm. This is only one example though, there are many many reasons why Kotlin is more suited for the "better Java" role. Namely it's simply not that different to Java. It's effectively Java with a more modern syntax and polished extensions to the Java standard library.

Post reply on HN