301–310 of 327 posts
What's the state of tail call optimization on JVM nowadays?
It's a compiler level thing, not runtime. ie. Scala has tail call optimization but Java doesn't, but they both run on the same JVM.
Earlier quoted context omitted.
Speaking from personal experience, the creators of most of the recent JDK versions have made very poor efforts to explain the changes, it's mostly just a list of RFC type documents, and who has time? An example of something that compares favourably would be Go, where they always blog about the changes, and there's easy to find official language documentation (and not just autogenerated API docs).
Have you tried for example the linked article with all the JEPs listed with lengthy descriptions? And with links to relevant mailing lists if it didn’t satisfy your curiosity?
- A list of links is not a summary. The list is too short, reading every individual linked document is too long. The format of JEPs tends to bury the lede. As such it feels like wading through mud.
- Changes that affect the programmer experience are mixed at random with changes that affect internal details of the implementation.
- Changes that introduce experimental features are mixed at random with changes that are final.
Earlier quoted context omitted.
If you're using "application servers" and not containers then definitely do not touch intermediate releases.
Why? I would say, try it out and see.
Earlier quoted context omitted.
Not considering async/await (because I'm not really a fan), they're neck-and-neck in my opinion. I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has; but in many cases you can almost compile a block of Java as C# and vice versa. I think the primary differentiator is what toolchain/ecosystem you prefer, and I'm solidly on the Java side of tha…
>I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has You say "careful", others would say "stubborn". The refusal to add things like operator overloading lead to a much less aesthetically pleasing language to read and write.
As a student most of the way through a Java course, I'm wondering what Java is still used for. Java applets are dead, Android is moving on to Kotlin (apparently Google got in legal trouble with Oracle even though Java is "open source?"), and I can't think of any desktop applications that use Java anymore. Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run…
As a MS paid shill. FTFY
Happy with the number of comments on this release. HN is a funny place.One day you are convinced no smart person on HN is still writing Java and the next day you see droves discussing about a java release.
Earlier quoted context omitted.
I work in embedded. Embedded Java has always been a huge set of tradeoffs, which is why it never took off outside of application platforms like mobile phones and set-top boxes. If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embed…
> Remember the portability disaster that was symbian and Java ME? Don't forget Java Card in that list. Which Oracle still tries to claim as a Java portability win, even though it doesn't support basically anything. And I don't mean missing standard libraries, I mean like it doesn't support char, double, float, and long, or multidimensional arrays. Support for int is even optional. Doesn't support exceptions and you c…
Earlier quoted context omitted.
There is an nginx in front of it. What was wrong with Apache?
Apache feels like a forgotten gem in the ops world. Everyone moved onto Nginx and at some point will run into some use-case that needs a feature that's only in Nginx+. And since Nginx+ is so expensive people end up just patching the OSS Nginx with the modules they need. But that whole time Apache was there with every conceivable battery and feature already included.
Earlier quoted context omitted.
Apache feels like a forgotten gem in the ops world. Everyone moved onto Nginx and at some point will run into some use-case that needs a feature that's only in Nginx+. And since Nginx+ is so expensive people end up just patching the OSS Nginx with the modules they need. But that whole time Apache was there with every conceivable battery and feature already included.
Except its configuration language is awful. Nginx is pretty bad too, and then there's Caddy which seems the most tolerable so far. Usability matters quite a lot!
I, too, believe that usability matters a lot, and I'm curious what you think of bash.
Earlier quoted context omitted.
Except its configuration language is awful. Nginx is pretty bad too, and then there's Caddy which seems the most tolerable so far. Usability matters quite a lot!
It is probably fairly easy to create a fork of Apache with a better configuration language. The fact that no such fork exist (or more precisely, the fact that you don't mention it, which is strong evidence that you know of no such fork) is evidence that most Apache users are OK with or roughly indifferent toward its conf language. (I know nothing of it.) I, too, believe that usability matters a lot, and I'm curious w…