Live data from Hacker News

Java 12

jdk.java.net

401–410 of 478 posts

Re: Java 12

#401
post #399
post #393

Earlier quoted context omitted.

Groovy had Netbeans and Eclipse support, which was dropped when it started fading away. We move in different worlds, no InteliJ installations around here. I remember when Groovy was popular, with every JUG in Germany having weekly talks and Sun talking how the next JEE revision would support Groovy for writing beans. Popularity doesn't write software.

I don't understand how Groovy is fading away when it is getting more and more popular. Groovy is also very similar to Java. There is no learning curve, you are immediately creating value.

More popular where?

Had it not been for Google's adoption of Gradle for Android and it would have been left for Grails maintenance projects.

And even then, the pressure for perfomance has been so much that it is being superceded by a Kotlin based DSL.

How to improve Gradle has been a common talk at every Android conference since Android Studio has been introduced.

Re: Java 12

#402
post #349

Earlier quoted context omitted.

> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. There was definitely an era of that, but over the past decade or so it's been acknowledged as a problem, and there's been a lot of effort put into making things simpler and more vanilla. Modern Spring is much much closer to plain old code. (Of cours…

The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. I've developed Java apps since almost the beginning, and am as much of a markup geek as could be, but still hate maven with a passion, and often times do…

> Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc.

Could you be a bit more concrete? I don't recognize any of your descriptions in my experience of maven.

There are probably some bad plugins out there, but as in any system the solution is not to use them.

The complete lifecycle is listed in the documentation, and it's all very common-sense.

pom.xml isn't meant to be Turing-complete, and if you try to use it like a Turing-complete build language you will get yourself in trouble (as many of the early Ant diehards did). You need to treat it as a declarative config file, no different from e.g. Cargo.toml.

> I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads.

It's just the opposite. I don't expect anyone to want to maintain Ant or Gradle builds in the future, since they can have any kind of crap in them. But Maven builds are forced to be kept sensible; the tool just isn't flexible enough to let you put crap in your build definition, by design. (If you really insist on doing crap you can make a crappy plugin, but your plugin is then forced to be versioned, tagged in VCS etc., so stands a better chance of being picked up by your organisation's normal code quality efforts).

Re: Java 12

#403

Earlier quoted context omitted.

Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go. IMO Java is the most well rounded language, but I'm not trying to convince you of that. Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtual…

Can do higher concurrency is a nonsensical phrase. Please show me your benchmarks versus Erlang at 10M web socket connections. You’re not understanding what I’m talking about when I say restarting. I’m talking about the JVM process. I also just said hot reloading is counter to modern practices. You’re not understanding what I told you.

If you want to build systems at scale you want to use a lot of commodity boxes, not a few huge or 'special' machines.

I don't drool over the raw horsepower of each of my individual boxes.[1] All I care about is that I can cost effectively create a cluster of them to serve the application's needs.

Because of this, even if Java could not handle as many concurrent connections, you might still chose it over this fabled 10M socket erlang server you keep talking about.

You might chose Java because:

* It is well understood and has a lot of mature libraries surrounding it.

* You can easily hire people to work on it.

* It is a stable language.

And so on...

I would summarize your original post like this: "I don't like Java, I prefer other things," which is fine as far as it goes, but then you basically say: "Therefore, everyone should also prefer the same things I do," which does not follow.

[1] I never particularly cared how many fps I can get on my machine, and I'm not that chuffed about my machine's geekbench score. IMHO this obsession with hardware metrics beyond diminishing returns is mostly a gamer thing.

Re: Java 12

#404
post #393

Earlier quoted context omitted.

> What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Seeing that both Eclipse and Netbeans are now more or less dead (and speaking as a long time Eclipse user, from the very first version to around 4), yes, first class vendor-direct InteliJ support is more than enough. And more than most languages (including Groovy) ever had. > As for Kotlin/Native, there is nothing to worr…

Groovy had Netbeans and Eclipse support, which was dropped when it started fading away. We move in different worlds, no InteliJ installations around here. I remember when Groovy was popular, with every JUG in Germany having weekly talks and Sun talking how the next JEE revision would support Groovy for writing beans. Popularity doesn't write software.

>Groovy had Netbeans and Eclipse support, which was dropped when it started fading away.

I know, I've used it. What I said is that it did not have the first class IDE attention of a major vendor, those were mostly third party sub-par plugins compared to the Java focus of those IDEs. For Kotlin, however, it was first class IDE support as a primary concern from the start.

>We move in different worlds, no InteliJ installations around here.

Then we indeed move in different worlds.

>Popularity doesn't write software.

No, its just the only thing that matters when it comes to get paid for it.

Re: Java 12

#405
post #392

Earlier quoted context omitted.

Groovy was a random JVM-based dynamic language with no major company support and no special tooling. Kotlin has IntelliJ (and thus a great IDE) and Google standing behind it, and Steve Yegge's nod of approval.

Not every Java shop is going to drop Eclipse and Netbeans just to make JetBrains happy. As for Android, lets see what happens with Fuchsia. The overwhelming majority of Java developers don't even know who Steve Yegge is.

>Not every Java shop is going to drop Eclipse and Netbeans just to make JetBrains happy.

True. They will drop them because Eclipse has been faltering for ages and has been dropped by IBM, and Netbeans has always been a subpar unloved stepchild used by the kind of devs that don't know better and think SlickEdit or Notepad++ are great editors.

>The overwhelming majority of Java developers don't even know who Steve Yegge is.

That's on them.

Re: Java 12

#406
post #6

The most interesting new feature I think is the Shenandoah GC. The summary from [1]: "Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB." The original algorithm…

This thread reads eerily like threads about Go's low latency GC from 2015 and how 10ms isn't good enough and throughput will be impacted and on and on. Three years later Go treats any 500 microsecond pause as a bug as Go continues to focus on throughput. Shenandoah is being put together by some very very smart people and I'm optimistic that the only thing that stands in the way of Java reaching the "500 microseconds is a bug" level is engineering hours and resources. More kudos for this achievement are in order.

Re: Java 12

#407
post #401
post #399

Earlier quoted context omitted.

I don't understand how Groovy is fading away when it is getting more and more popular. Groovy is also very similar to Java. There is no learning curve, you are immediately creating value.

More popular where? Had it not been for Google's adoption of Gradle for Android and it would have been left for Grails maintenance projects. And even then, the pressure for perfomance has been so much that it is being superceded by a Kotlin based DSL. How to improve Gradle has been a common talk at every Android conference since Android Studio has been introduced.

Everywhere?

Google Trends says Groovy is just as popular as it was 10 years ago. The number of downloads has increased significantly but it is not because of Gradle, as Gradle bundles Groovy. It is also currently placed #16. on TIOBE Index

And last, Groovy with compile static is in most cases, just as fast and memory efficient as Java.

Some people always talk down Groovy, yet the numbers speak for them self. Before Kotlin, Groovy was attacked by Scala developers.

The major thing Groovy has over both Scala and Kotlin is strong similarity to Java syntax which makes the learning curve non-existing. And that is a bigger deal than a random cryptic/confusing programming expression. Code readability is very important.

Re: Java 12

#408

I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It's like watching people keep coal trains going while people are moving to cars. Why? Besides being owned by Oracle, which is enough of a reason to never use Java ever again, it's also lost the niches that brought it into existence. Java no longer runs everywhere. Java on the web is dead, and you can now…

So far I did not find anything comparable to replace Java for website server language. Go is a terrible extremely verbose language without vital features. JavaScript on Node is limited by single-thread and JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby). Rust is awesome, but I don't think that it'll be ever usable for mediocre developers, therefore it can't b…

LASR 14 hours ago [dead] [-]

> JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby)

You know, I used to think that languages had a single axis of Good. And each language sat at a certain point in that one dimension.

After several years each of experience writing large web applications using C++, Java, C#, JS, Python, Ruby and Go, that mental model of languages being good, bad or terrible seems incredibly naive now.

But overall, if someone were to ask me to write a web app today, I would probably use Python server-side and break it down into microservices. Client-side, probably just pure js + HTML5 APIs.

Why? Because I don't have the time to argue about languages being better or worse. I am too busy writing code that does useful things.

In a high-skill rockstar team, dev time is by far the most expensive resource. In a startup environment, using your dev time wisely is the difference between a unicorn and a failed business. Nobody gives a fuck if your route handler executes in 1ms or 20ms. I'll gladly pay the 20x hosting costs if that will get my feature out to customers a week earlier.

i don't know why this comment was downvoted so much. i fully agree with every point that LASR makes. if you disagree, i'd like to see your counterpoints please.

Re: Java 12

#409
post #83
post #33

Earlier quoted context omitted.

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements). More importantly, the JVM ecosystem is m…

> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it…

The new parser is available in the Groovy 3 alphas.

Re: Java 12

#410
post #393

Earlier quoted context omitted.

Groovy had Netbeans and Eclipse support, which was dropped when it started fading away. We move in different worlds, no InteliJ installations around here. I remember when Groovy was popular, with every JUG in Germany having weekly talks and Sun talking how the next JEE revision would support Groovy for writing beans. Popularity doesn't write software.

> Groovy had Netbeans and Eclipse support, which was dropped when it started fading away. I know, I've used it. What I said is that it did not have the first class IDE attention of a major vendor, those were mostly third party sub-par plugins compared to the Java focus of those IDEs. For Kotlin, however, it was first class IDE support as a primary concern from the start. > We move in different worlds, no InteliJ inst…

Delivering working software as per customer's RFP is what matters, everything else is fluff.
Post reply on HN