Here is your unicorn https://en.wikipedia.org/wiki/...

I'm still not convinced that Option have any value. It looks more that it complicates development and is only here for null-phobic developers. But thank you for your time.

How does Option helps in find(), search(), indexOf()? Why not just use exceptions or return null?

If a function can't return a meaningful value, it looks for me like a code smell. It should always return a meaningful value or throw an exception. The return of -1 in the find() method is a code smell and just bad design. Sadly, it's tradition (carried over from C) and we have to live with it. The find() method should throw an exception or return Integer and null if no item was found.

Yes, and that should always be the case, except if it's clear that the method can also return nothing, like in find(). public Integer find() can obviously return null if no value was found, for example. Other methods are search(), indexOf(), etc. Again, those methods should return null and not the idiomatic -1.

You are correct, Java's final is more like a const. Although I still don't see the point in avoiding null. Obviously you can't, so better to live with it and provide tools to detect a null pointer/reference, i.e. treat access to null like a bug. We already have div 0 bugs, overflow bugs, etc. and we have tools to detect them.

Yes, it can. Static code analyzers. But anyway, how does Option is suppose to work? Now every variable is by default Option.None and I have to sprinkle my code everywhere with foo.unwrap(default)? That's convenient (sarcasm). And what does the default should be? I don't have a default, that's the whole point! The value have no default, that's why it's null or Option.None in the first place. And we went full circle, and the only sensitive thing the app should do is either crash or show a big error message and exit. Btw, of course an app should gracefully shutdown, and that is possible even with null.

We already have that with static code analyzers. But how would you even do that with dynamic languages, where the type can just change at runtime?
Furthermore, TypeScript is handling null just like Java. So the statement that "every mainstream programming language continues to support the null concept" is even more nonsensical, because TypeScript is one of those languages. // Compiled with --strictNullChecks
let x: number;
let y: number | null;
let z: number | undefined;
x; // Error, reference not preceded by assignment
y; // Error, reference not preceded by assignment

That is just like Java's final keyword.

final int x; // compile error

Because you cannot do without. The computer cannot guess a value of a variable, so the default is always "Not Set" aka Null. Other languages use a Type.NULL or whatever, but it's just the same as Null. So, every language have a null concept.

It's just the same thing. Call it None or null, who cares.

Yes, please mod him +10. I'm sick and tired of people afraid of NPEs (NullPointerException, Java) or of null. A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.

- "Because it is not slow?"
If a JS web site like the Kibana dashboard maxes out my CPU core (I have an Intel 5), how is it not slow?
Compared to a native application that would use up max. 3% to 10% of my CPU.

- "You seem not to get it: some people like the language that is why they use it. And: if you want to have the same technology on frontend and backend it makes sense to use node.js on the backend."
Use whatever you like. I'm discussing facts.

- "From a language designer standpoint it is a fine language, a few quirks, yes."
No. From a language designer standpoint it's like the worst language out there, maybe worse than even PHP. Even Brainfuck is better.
The need for === alone makes it the worst language.

- "Your arguments make no real sense in our times. JavaScript is now in its 6th reincarnation, it is extremely fast and much safer has less bugs etc."
Citation needed. It still have the same bugs, and it's still very slow. Even the WebGL demos max out my CPU core. A native app would be around 1% of my CPU. The slowness is inherent to JS, I don't think the devs are incompetent.

- "Ofc there could be other scripting languages for browsers ... but they never got traction and the ones we use in our days as alternatives are compiled to JavaScriot anyway."
They never got traction because the W3C and the browsers devs are drinking the JS cool-aid. And because JS would die very fast if the browser devs would allow for any other language. For their benefit, they have their reasons of course. To have just one language for the Web is of course a benefit.

Again, the simpler solution would be to have a byte code standard, like the JVM have. Since the JS engines are all VMs anyway, it wouldn't be a problem. Another solution would be to fix JS, but that would brake a lot of web sites so that will never happen.

Yes, current alternative languages must compile to JS, so there is little or no benefit for using them. So it's no wonder they don't get any traction.

The demo (angry bots) still uses about 30% of my CPU resources. It doesn't lag because the graphic is all done by the GPU by OpenGL, but JS still sucks. On a phone it will drain the battery way faster than a native application.

Btw, I really don't get how devs are all in denial about the fact that JS is still slow as shit.
Go to http://demo.elastic.co/
If I do anything on the graphs (like moving the mouse cursor over a graph), it's a noticeable lag in the UI, and my CPU goes up to 20% for Firefox.
A native app (in any language) would be at 0-1% CPU and there would be no lag at all.

- "I doubt you know from your head a language that has prototype inheritance ..."
Again, it's not a good thing in and out itself. Other languages have other good features, it all depends how can I have my work done.
I bet JavaScript can't access OpenGL, it needs to go through WebGL and other slow and cumbersome APIs.
JavaScript put the web at least 10 years behind what it could have been. UI in JS are slow and unresponsive, that's in part the fault of JS itself.
What do prototype inheritance me any good, if the JS code puts my CPU at 30% and makes my whole browser unresponsive.
The browsers devs reacted by putting each tab into a new process. But again, that's just an attempt to fix the symptoms and not the decease.
The W3C should have just released a byte code standard, and we could be free of JS (you could still use JS), and the browser devs could just concentrate on optimizing the byte code, instead of writing one slow JS parser after another.

- "The fact that you don't like the language does not make the language inferior."
No, the bugs do. And that after 20 years of JS we still have slow and unresponsive UIs.

- "No idea what you mean with "automatic semicolon", in JavaScript semicolons are optional."
You have really no clue about JS. The parser puts semicolons automatically into your code, that's the reasons why they are optional for you.

- "Of course it has ... it just escapes you as you never tried it."
That's a reply like from a religious person. "the love of God escapes you as you never tried it"
- "You failed to name one ... "
Like every other language that is not JS.
All languages have the same power, so obviously I was talking about them.
- "The bugs of what?"
===, the automatic semicolon, "0" = true, and other bugs like the IEEE 754 standard.
- "Nope ... plenty of tools are written in JavaScript ..."
From 0.15% to 0.20% in a year.
https://w3techs.com/technologi...
Java (Tomcat), from 0.52% to 0.57%
https://w3techs.com/technologi...
So, there are way more Java tools written in a year than for Node.js.