kcomhnallmy assumption would be a video about the addition of lambdas
cheesernullability
Paravideo description mentions valhalla
dreamrealYeah, youtube title extraction is a PAIN
dreamrealI don't even know WHY. I mean, I know WHY they make it a pain from their end, but dang
ParaYoutube's API and account management in general is superbly stupid.
ParaIt's like 14 steps even when you know what you want to do.
dreamrealYeah, I don't think the bots want to use their API if that can be avoided: twitter's the same way
dreamrealtwitter's API is the only reliable way to get tweets programmatically, and it's $0.005/request, although they have aids for *repeated* requests
dreamrealI decided nevet'll get twitter support when it gets a sponsor who asks for it :D
dreamrealI am still working on youtube, though
dreamrealnitter still works but it does human verification; the other twitter things route to twitter itself now
sbalmosthe only thing more screwy than Youtube's API and account management is AWS IAM and its API authentication
ParaAWS IAM is good until policies.
ParaLike...I understand and agree why they're there, but its still bad.
NeXeNoh the nullability thing is huge but i mean it's survived thus far
cheeseri'm sad about nullable still being the default but i don't really see a way they can fix that without breaking almost every single line of code ever written.
NeXeNthere is always a way. use the force. if it doesn't work then make it work harder
jreicherNeXeN: What's "the nullability thing"? The only JEPs I can find about this are still in draft.
ParaNeXeN: If force doesn't work, you're not using enough.
Chronos"Just don't make mistakes"
dmlloydthe draft JEPs are generally a reflection of whatever the current state of experimentation is... but they don't always update the JEPs quickly especially if lots of things are being experimented with
dmlloydthere are some JDK trees that you can check out and mess around with if you're brave
cheeserbuilding openjdk is not exactly trivial or pleasant, though.
jreicherOh I'm just interested in knowing what the current thinking is. Is there a sincere effort to add nullability to the type system? Or do people just chat about it over cocktails?
NeXeNit's about whether or not something can be set to null. some ways you can get a promise or other ways to keep from ever getting a null
cheeserjreicher: it's a significant effort. it's been on brian's back burner for some time.
cheeserbut i think he considers it low hanging fruit compared to, say, value types.
cheeserum. is that what I meant to say? i got distracted midsentence. it's low *priority* compared to ...
NeXeNit can eliminate a performance concern
NeXeNnull checks are expensive, if one could eliminate null then it would be simpler to design things that don't null pointer error at runtime
cheeseryep. and now that he's thinking "carrier classes" to remove the disconnect between regular classes and records, i'd imagine he's feeling similarly about the gap between value types and regular classes
ParaIIRC most null checks gets eliminated by JIT anyway.
ParaI've never found the attractiveness of this particular topic. Maybe im dum.
cheeseri don't know that that's true... dmlloyd might know better. but that seems like a dangerous check to elide
dmlloydif the JIT can prove that a value coming in is always null, it'll drop the check
dmlloydthat kind of thing can be invalidated by deoptimization
NeXeNi do love value classes, and it's a good model for a personal project of mine
dmlloydnot at all, every instance method call or field access has a null check on it
dmlloydso you definitely want to eliminate as many as possible
cheeserthe field would have to be final, no?
NeXeNwell it's like a promise can return a value or not you gotta wait or decide to do something else, and null is really that situation in a nutshell
dmlloydno, the field value isn't null checked, the instance is
dmlloyd`foo.bar(); foo.baz()` <- foo is provably null if `foo.baz()` is reached
NeXeNnull just happens in the data a lot
dmlloydI mean if `foo` is itself a field then yeah it would be rechecked unless it was stable and final
dmlloydbut if it's like a local var then the second one doesn't get null checked
dmlloyd(if `foo` is a stable final field then its value is cached in a register so there's only one load)
dmlloydeven `this.foo()` has an implicit null check that has to get eliminated by *something* that knows `this` is never `null`
jreicherYeah elimination of runtime checks is one of the reasons I like type systems. I think Alexis King's "parse, don't validate" essay makes the same point. And the runtime checks include both those done by the language and those the programmer had to write.
NeXeNyou get some extra decorators, like ! to be able to specify something, i forget i read the jep and docs
NeXeNoh yeah it flattens the array as well, making it very performant