Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

241–250 of 358 posts

Re: New language features since Java 8 to 17

#241
post #200

Earlier quoted context omitted.

Why are you blaming a class called “LocalDate” for not giving you global timestamps? The java doc for the class has an entire paragraph on how it is not a time. If you want to model a specific instant in time, use Instant.

This is a fair criticism. Java Instant should be the standard, and anything that doesn’t use it as its base should be deprecated. I have to support older JDKs, so I don’t know. The article starts with Java 9, and Instant was included with 8, so it is not a fault of the article.

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.

Re: New language features since Java 8 to 17

#242
post #211

Earlier quoted context omitted.

I can understand the hate behind null-safe operators, but why properties? Why is bad to have an ability to "upgrade" a member variable into a property, without breaking any existing contracts? I really hate that I need to resort to using setters and getters in Java because those are bad for searchability.

Properties are probably the worst feature on that list, and no experienced language designer would add them to Java. They make it easier to work with setters, while the goal is to reduce their usage altogether! Records achieve that much better. Unencapsulated component access is standardised on classes with good contracts (construction and deconstruction are duals for records) and will work well with patterns, all wh…

Thanks for the thorough explanation. Now I understand where Java is heading for. The aesthetics regarding withers concerns me a bit though, because I don't like prepending anything to the name of an acceessor (a transformer, in this case?), which was why I liked the idea of properties in the first place.

I hope both Java and Kotlin can converge into a common coding style. As you said regarding C#, Kotlin's emphasis on properties makes it easier to use getters and setters and thus may hinder getting rid of them in the Java ecosystem. I'm not sure if I should support Kotlin's success at this point.

Re: New language features since Java 8 to 17

#243
post #146

Earlier quoted context omitted.

teach javascript, ruby, rust, go, kotlin....scheme. literally anything else.

how's javascript better than java in its design or elegance?

Well for one, it has a repl. As per single core performance, javascript is faster and has had first-class-functions from the beginning.

and you don't need 10 lines of code to print hello something to the screen.

and JavaScript(ES6) is actually multiparadigm.

don't get me wrong, JS has its warts (and oh my god that is indeed the case.) but you can literally run it in any browser any where, which makes for an excellent teaching aid.

Elegance isn't the first word I'd reach for when describing Java

Re: New language features since Java 8 to 17

#244
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…

>The truth of it is that Kotlin is incredibly easy to learn That's not my truth. I tried it, after not doing "real" programming for a while, and found it the most obfuscated, incomprehensible language I've ever run into. What new concepts are there in Kotlin that justify it? "Expressiveness" sounds toxic to me - along the lines of "facilitates a personal idiom that makes your code impossible to understand and you irr…

Kotlin can be written very densely indeed. It's a bit like Scala in the regard that disciplined usage is necessary (although nowhere near as bad, no implicit conversions/parameters, restrained operator overloading).

But then, I've seen some shit Java too.

Re: New language features since Java 8 to 17

#245
post #2

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.

I think one could argue exactly the same thing for the same reasons about C# vs F# on .NET, which is my area of expertise - but honestly I'm not so sure it's true. C# has grown into an enormous language as it tries (consciously or not) to subsume F#, and F# is always going to remain so much cleaner just because you aren't having to ignore 90% of the language features when you code in it.

Agree with this. What's more interesting is on the feature level languages do borrow/converge on each other in order to try to secure a position in the market. I note that as an example Java is consdering a .NET like Span feature (https://openjdk.java.net/jeps/412) as an example probably to close the gap w.r.t performance. There are others.

What matters more in all honesty, and what's hard to change IMO is:

- The base of the language (is it verbose, how the base features interact with each other) vs being "tacked on". A language with these features initially. e.g. you mention F# and I know it uses HM type inference, immutability by null, makes null hard to express by default, etc.

- Anything that breaks backwards compatibility (e.g. Java's generic implementation) for example including existing API's. Adding Async afterwards takes time, and changing the underlying model of the language (e.g. Python's GIL, OcAML multithreading) takes time and needs a lot more consideration. Its code, anything can change, its just harder and maybe easier to take something that was designed for that case initially. Being a polygot isn't a bad thing per se I think if it can be justified tech wise.

Re: New language features since Java 8 to 17

#246
post #24

Earlier quoted context omitted.

I assume OP prefers Kotlin or Scala. Personally, I think one of my favorite things about Java is that, all things considered, it's a small-ish language. So I'm glad that Java is both willing to evolve (slowly, letting other people try stuff out first) but also clearly focused on a curated feature set and resistant to letting new stuff in to bloat it. I am very happy to deal with minor things like no multiline string…

By multiline strings are you referring to text blocks? Those have been added to the language in Java 15: https://docs.oracle.com/en/java/javase/15/text-blocks/index.... .

Tbh I still crave Kotlins inline string interpolation.

Re: New language features since Java 8 to 17

#249
post #152

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…

Dominant outside Android? Keep dreaming, where is the KVM implementation by JetBrains? Yeah right they had to reboot it.

Kotlin is in frequent use on the backend in many places, including Amazon and Google.

Re: New language features since Java 8 to 17

#250
post #215

I used to really love Java, it was my second "real" programming language after C/C++, and GC, type safety, and object orientation really changed the way I thought. I also learned almost all I knew about high-performance VMs (up to 2013) in the context of JVMs. But these days it seems like Java is engaged in one long apology for the "everything is an object" mindset it started out with. It both took it too far and not…

Its not universal to all of .NET though.

F# does support this (e.g. Task) because in F# every function has only one input and one output. Therefore it needs a unit/void type at the lang level at least. This simplification surprisingly results in more power and less code compared to C#. Its part of the base design of the language, and an example of something that is hard to change afterwards in future versions.

In F# overloads for different amounts of type args to a function are not common, unlike C# with different types for each Func or Java with both Supplier and Function types and needing a custom function type for more args last time I checked. A use case that has come up for me would be to dispatch on variadic template args (e.g. loggers) in a typesafe way without reflection penalty, or looking at some of the libraries using overloads that could be reduced (especially in conjunction with inline for the value type overloads I suspect such as found in LINQ). When I see libraries with overloads for parameters like 'Func' I think of this. Wherever you see multiple overloads in C#/Java just for the sake of multiple generic arguments; that can often be simplified if required/worth it.

Post reply on HN