http://blog.vavr.io/idiomatic-javaslang-the-for-comprehension/
http://blog.vavr.io/redundancy-of-the-java-language/
Hi everyone,
My team is considering using Vavr in a new production service - we were just wondering, how well maintained is this library? Looking at the GitHub commits it seems active, although I can see that the last release was back in August. Will the library be supported long term?
Thanks!
The users are happy so far. Not all feature requests are implemented because we keep the API surface area small. During the last months, there weren't many bug reports (which is a good sign).
There are two upcoming releases planned, a major one (which is really overdue) and one feature backport to the the current version.
I stopped to plan dates, very much like other teams, for example at Facebook.
But I can tell you what I want to change. Option/Try and Either method names will be aligned to the Scala counterparts. I will prepare the classes to be used with Java’s native pattern matching and the deprecations will be mostly removed.
My problem with readability in Java is that types are prefixed instead of being suffixed:
// types are prefixed
Function<Integer, String> myFunction = String::valueOf;
int myInt = 10;
CompletableFuture<Optional<String>> myCompletableFuture = null;
// types are suffixed
myFunction: Function<Integer, String> = String::valueOf;
myInt: int = 10;
myCompletableFuture: CompletableFuture<Optional<String>> = null;In languages that suffix the types, it is more natural to just leave them away, if the context is clear.
// explicit types
var myFunction: Function<Integer, String> = String::valueOf;
var myInt: int = 10;
var myCompletableFuture: CompletableFuture<Optional<String>> = null;
// inferred types
var myFunction = String::valueOf; // type inference does NOT work for lambdas and method references
var myInt = 10;
var myCompletableFuture = null;In languages like JS / TS, we pass around JSON objects and transform/consume them using functions.
Again, in that case it is natural leave the type away:
// explicit type
const person: { name: string, age: number } = { name: "Piet", age: 33 }
// inferred type
const person: { name: "Piet", age: 33 }I think Java is a bit more verbose with its types. Therefore code with inferred types is a little bit harder to read.
Sometimes, I experience the same with JS /TS code and tend to add types for clarity.
type Person = { name: string, age: number }
// explicit type
const birthday: (p: Person) => Person = (p) => {...p, age: p.age + 1}
// inferred type
const birthday = (p: Person) => {...p, age: p + 1}