New Features in Java 14 • Hacker News Board

Re: New Features in Java 14

#161

Post by cxr » Wed, Mar 04, 2020, 8:27 PM UTC

pjmlp wrote: post #160

cxr wrote: post #156

Earlier quoted context omitted.

First, you didn't describe an exception; you described additional restrictions. But now you're pivoting to talk about exceptions. These are fundamentally different things. One enlarges the set of actions a recipient is free to do relative to what vanilla GPL allows. This is permitted (and in the case of the classpath exception, endorsed) by FSF. The other attempts to shrink the size of that set by denying the user th…

Well, I let Gosling speak about Google's then https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

How about a straightforward response, rather than trying to change the subject again?

What's more, I've seen this interview multiple times. Listening to Gosling stutter and be coy is not illuminating in the least. He has no idea how to answer the question he was asked, much less what's being discussed here now.

Can you substantiate your claim or not?

Re: New Features in Java 14

#162

Post by exabrial » Wed, Mar 04, 2020, 8:48 PM UTC

sickmartian wrote: post #155

exabrial wrote: post #151

How do I propose a language change? One thing I'd really like to see is optional type declarations in Lambdas to bulletproof them. Take this simple Lambda List names = new ArrayList (); names.stream().filter(String name -> "Bob Vance".equals(name)).findFirst().get(); By adding the String type declaration, a whole host of bugs in really complicated Lambdas can be eliminated and found easier when the original types and…

Can't you do .filter((String name) -> "Bob Vance".equals(name)) already?

I just learned something today.

Re: New Features in Java 14

#163

Post by [deleted] » Wed, Mar 04, 2020, 9:08 PM UTC

hcarvalhoalves wrote: post #67

Sharlin wrote: post #15

Earlier quoted context omitted.

In Java you're passed a reference to an object. Might it be null? Can it be null? Who knows! Mostly you're just going to ignore the possibility and hope for the best. In Rust you're passed a reference to an object. Can it be null? No, it simply can't! There does not exist a magic "null" value for references. To represent the possible absence of a value, you explicitly encode it into the type system by using `Option `…

Just changed from having a bottom null type for all types to everything being a boxed Option type. It’s equivalent. The actual difference is the reliance on pattern matching and the compiler enforcing coverage on those languages.

[deleted]

Re: New Features in Java 14

#164

Post by strbean » Wed, Mar 04, 2020, 9:14 PM UTC

thu2111 wrote: post #125

Sharlin wrote: post #98

Earlier quoted context omitted.

Huh, what? You don’t need or want most values to be potentially absent.

Yes, the difference is a combination of types being non-null by default and compiler enforced checking. This doesn't require an option type. Option types are actually quite awkward compared to language integration. Kotlin doesn't use an Option type yet still delivers all the same benefits as Rust/Haskell's approach, with benefits (e.g. zero overhead, integrated syntax). Note that Option type overhead isn't merely abo…

Doesn't that approach make the "nothing branch" extremely expensive? Makes sense in scenarios where you really always expect Something and not Nothing. In practice, Options are very often used where something is optional, and you can expect to get Nothing a good percentage of the time. Using exceptions in such cases seems silly.

Re: New Features in Java 14

#165

Post by strbean » Wed, Mar 04, 2020, 9:31 PM UTC

reificator wrote: post #41

fidelramos wrote: post #12

Earlier quoted context omitted.

The key difference is that in your second example you can just forget about the else branch, while in Rust you must explicitly handle the None case, otherwise it won't compile.

No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don…

Isn't unwrap(x) just

    match x {
        Some(v) => return v
        None => die painfully
    }

?

If so, the None is still handled. Dying painfully is an escape hatch out of the type system in any language that lets you do it.

Re: New Features in Java 14

#166

Post by benibela » Wed, Mar 04, 2020, 10:04 PM UTC

aw1621107 wrote: post #35

benibela wrote: post #17

Earlier quoted context omitted.

And you can write sth.unwrap() in Rust, and then it panics when it is null. Kotlin solves it much better. sth?.do_something() ?: nothing_to_do

Rust does in fact have a ? operator [0], but it works slightly differently than Kotlin's in that it returns early if a None/Result is encountered instead of just resolving to that None/Result . If that isn't what you want, then Option::map() is a fine substitute. [0]: https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

But there is still a function that panics.

Java has solved memory safety. Now the task is to make sure that code that can panic will not compile

Re: New Features in Java 14

#167

Post by pjmlp » Wed, Mar 04, 2020, 10:14 PM UTC

cxr wrote: post #161

pjmlp wrote: post #160

Earlier quoted context omitted.

Well, I let Gosling speak about Google's then https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...

How about a straightforward response, rather than trying to change the subject again? What's more, I've seen this interview multiple times. Listening to Gosling stutter and be coy is not illuminating in the least. He has no idea how to answer the question he was asked, much less what's being discussed here now. Can you substantiate your claim or not?

Sun as copyright holder had the right to constraint Java's usage as they wanted and embedded deployment wasn't covered.

Naturally it is hard for anyone to link to anything Sun, given what happened with their assets and Internet presence.

Is a substantiate argument? Maybe not, it doesn't change the fact that Google screwed Sun, didn't bothered to rescued it went it went down, and now we have Java and Android Java.

I guess FSF is happy with the outcome then, since it is allowed to tank companies.

Re: New Features in Java 14

#168

Post by aw1621107 » Wed, Mar 04, 2020, 10:38 PM UTC

benibela wrote: post #166

aw1621107 wrote: post #35

Earlier quoted context omitted.

Rust does in fact have a ? operator [0], but it works slightly differently than Kotlin's in that it returns early if a None/Result is encountered instead of just resolving to that None/Result . If that isn't what you want, then Option::map() is a fine substitute. [0]: https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

But there is still a function that panics. Java has solved memory safety. Now the task is to make sure that code that can panic will not compile

The function that can panic still exists, but the ? operator itself won't invoke a panic. Sort of like how you can still get NullPointerExceptions in Kotlin using !!, but standard practice is to use a safer option.

Exception/panic-free code is fairly straightforward; you just need to have APIs return Option/Result/other error code equivalents to indicate failure. The problem with that is that it introduces some amount of friction that will probably make some programmers unhappy.

If you want to avoid returning Option/Result/other error code equivalents, you need some way to prove your inputs cannot trigger an invalid result, and that is a very difficult problem.

Re: New Features in Java 14

#169

Post by cxr » Wed, Mar 04, 2020, 10:46 PM UTC

pjmlp wrote: post #167

cxr wrote: post #161

Earlier quoted context omitted.

How about a straightforward response, rather than trying to change the subject again? What's more, I've seen this interview multiple times. Listening to Gosling stutter and be coy is not illuminating in the least. He has no idea how to answer the question he was asked, much less what's being discussed here now. Can you substantiate your claim or not?

Sun as copyright holder had the right to constraint Java's usage as they wanted and embedded deployment wasn't covered. Naturally it is hard for anyone to link to anything Sun, given what happened with their assets and Internet presence. Is a substantiate argument? Maybe not, it doesn't change the fact that Google screwed Sun, didn't bothered to rescued it went it went down, and now we have Java and Android Java. I g…

> Sun as copyright holder had the right to constraint Java's usage

Sure. But what they don't have is domain over the GPL.

I won't respond to the rest of your comment, which has nothing to do with the claim you made to kick off this branch of discussion and is just another attempt to change the subject (with what is an opinion, not a "fact").

This will be my last comment here.

Re: New Features in Java 14

#170

Post by [deleted] » Thu, Mar 05, 2020, 12:15 AM UTC

strbean wrote: post #165

reificator wrote: post #41

Earlier quoted context omitted.

No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don…

Isn't unwrap(x) just match x { Some(v) => return v None => die painfully } ? If so, the None is still handled. Dying painfully is an escape hatch out of the type system in any language that lets you do it.

[deleted]