This is also a gem: "Because list is already immutable there's no practical need to actually create a copy of the list-instance, therefore list and copy are the same instance. However if you copy a mutable list, copy is indeed a new instance so it's garanteed there's no side-effects when mutating the original list"
So you can get a "reference" to the same data where one reference gives you the data immutably while the other one lets you change it. Sounds like a recipe for subtle bugs.
Looks like Java is slowly but surely catching up to Scala in terms of API, syntactic sugar etc. I wonder if some people disliking Scala compiler slowness would consider the switch back to Java.
Far from it. When Java gets pattern matching, Scala will have moved to version 3.0 with trait parameters, union and intersection types, implicit functions, type lambdas, cleaner macros and many more.
Also, Scala compiler slowness is virtually not a problem any more since introduction of Zinc 1.0. During development, I get repeatedly compile times around 2-5 seconds on Scala 2.11, and recent Scala 2.12.x / 2.13.x showed to be typically 30%-100% faster than 2.11.x.
The whole point of Scala are its advanced features like implicits, higher kinds and macros, and not just syntactic sugar like in Kotlin. Therefore you won't appreciate Scala by just shortly playing with it.
Also in 2018 interop issues or missing tooling problems are long gone.
The first step towards pattern matching will be previewed in JDK 12[1], as a Kotlin-like switch statement, to form the basis of pattern matching[2] together with changes already in JDK 11[3]. I think it will be more like 15 months than 15 years.
I don’t expect higher kinded types any time soon, though.
If it doesn't have what 305 calls "deconstruction patterns" and "nested patterns", it's not really pattern matching. I'll be impressed if those make it in within 15 months.
I saw that on reddit and downvoted it, title says it shows new Java 11 things, so I expected dynamic class-file constants example and explanation, ZGC tuning and showcase, not "var" from Java 10 and HTTP client from Java 9... Your post describes some minor syntax changes and a few new base methods, doesn't cover release notes.
The verbosity in that code is less of the typical (and deserved) Java criticism of over-architected pattern cancer. Instead, almost all of the verbosity there is due to a refusal of the language to assume common defaults.
Whether assuming common defaults or forcing people to think about that stuff is good or bad is debatable. But it's certainly far from deserving of the "uuuuuuuuurgh" of a lot of (mostly older) Java I've had to wade through.
This is really a really weird overdesigned API. Maybe I don't understand the purpose of it but it seems like an excessive use of design patterns.
Why would you need a Builder method on a static object to create a request object? Oh well, let me rephrase that: First you instantiate a Builder object that you need to call the create method on to get a request. Makes no sense to me.
What not make HttpRequest a concrete class and just instantiate it? If there's any good reason for that design please enlighten me.
Many use cases want to make a whole lot of pretty similar (URI, creds, method) requests that vary only in a single way ( e.g. a POST parameter) or don't vary at all (e.g. polling).
A builder is a convenient way to wrap up those common settings so that they can be handed to other parts of the code that don't care about them/want to override specific parts and leave the rest in common.
Now, there are other ways to do that (instantiating a concrete class with common settings and mutable fields for customizations in a function, and then passing references to that function to everything that wants the common-config-defaulted output object). The choice between that kind of strategy (or an instantiate-and-freeze-early and pass your mutators in, or a refactor-all-your-code-to-not-mutate strategy etc...) and a builder pattern is a subjective and debatable one. But the approach taken here is certainly defensible.
Much better than HttpUrlConnection though.
As an aside, the http client API seems really well thought out, supporting all sorts of common use cases for http. Once you convert the examples to some non trivial request response stuff, the new API shines. I think the job of pleasent APIs for starters is left to external libraries here.
Almost nobody uses the standard lib for http in practice. Just use Unirest/OkHttp/SpringBoot then it’s trivial. SpringBoot is the best framework that I have worked with regardless of language. It covers most use case out of the box and everything is still completely configurable.
The difference is that the JSX snippet is translated in plain JavaScript which means you can automatically check for syntax errors, type errors (when using TypeScript or Flow) and semantical errors (by writing simple unit tests), whereas the PHP snippet is just a big mess. JSX also runs on clients, servers and mobile devices which is a big plus to me.
This is fine:
<?php
if (condition) {
?>
<div>whatever</div>
<?php
{
?>
We use Youtrack at our company. It's a fully fledged issue tracker with a lot of features, e.g. custom fields, top notch search, batch operations, keyboard shortcuts, agile boards, workflows via own DSL, reports and statistics etc.
Really? The new mobile Twitter site is super fast and reliable on my phone. The native app is still better but it gets really close in terms of performance and usability. However apps still have better OS integrations (notifications, sharing) and touch handling (swipe etc).
Really? It doesn't like my phone. And every time the train enters a tunnel, Twitter tells me my connexion is unavailable and ruins whatever I was doing at the time.
Kotlin is currently my favorite alternative JVM language. Kudos to all collaborators for the great work. After 5 years of hard work, you finally made it!
Here's a little starter project for Kotlin webapps using Spring Boot and React.js, I made a while ago:
>Building a JVM container with Docker. So you can put your interpreter inside your JVM inside your Docker container inside your Kubernetes inside your VPS inside your OS and be happy.
Since 15 it also works damn near flawlessly for me on Ultimate, they also seem to be faster on getting the plugins upto date with the individual IDE's which is a major win for me.
Current project I'm using PHP and Python for different parts and it is absolutely flawless, also if anyone hasn't used them Facets and Aspects are incredible!
https://winterbe.com/posts/2018/09/24/java-11-tutorial/