my understanding is not as much and not as consistently as more advanced filters

Helpful for a significant portion of readers in this case, but tough to make this a general rule without using some judgement. For example, it would probably be overkill to define "AI" in every submission.

Oh, yeah, that's a good point. There would need to be a list of common ones to skip.

Or use an acronym LLM to fill as an extension to Firefox! (Since everything "has" to be a model nowadays)

some are willing to bear the risk of bricking their phone. far fewer will accept the risk against the cost of their luxury car

I haven't seen "on crack" used in a positive light, but apparently it is sometimes? Usually I'd say "they must have a crack team on incident response", meaning a highly functional, smooth-running team.

I love when people say "like crack" when they've obviously never done crack. - Ryan, The office.

Huh, I swear I heard in a positive context before. But English in not my native language, so my feel on the nuance of this expression is probably a bit off.

There's a subtle distinction. "Like ... on crack/steroids" means a really good / fast version of something (I think steroids is probably the more common variation) e.g. "an e-bike is like a bicycle on crack". "They're on crack" means "They are crazy".

I’ve heard “on crack” used similarly to “on steroids,” as an American English speaker.

For example, it would not be out of the question to say something like “when the iPhone launched it was amazing. Like a palm pilot on crack.”

So, when used positively, “on crack” is generally a modifier(in my experience). When used alone it does seem to have negative connotations.

I think it's used like that for products rather than humans. "X is like Y on crack."

Yeah "on crack" usually means they're not right in the head.

In this context though, OP is referring to the drug where the Github engineers are being quick/energetic about fixing the issue because they're "boosted" by the drug's effects.

Yes, they obviously meant the more common, positive associations related to methamphetamines like, "great job on that quick PR, Kim. You must be on meth!" :)

Or “gee, Hunter Biden is a swell son, he sure got to Vegas really fast! He must be on crack!”

Its pretty unusual, I think it has to do with their local time coupled with a presumed enthusiastic and swift response on the part of github.

I'm more used to 'on crack' meaning like 'delirious, over confident'.

What leads you to focus on B2B? Is it hard to find a pricing model that works for both B2B and consumer scale, or is that just where you’ve found initial fit?

We actually started YC with a focus on consumer and mobile, but we found that willingness to pay was much lower than B2B.

There's a similar project under awslabs for using S3 as a FileSystem within the Java JVM: https://github.com/awslabs/aws-java-nio-spi-for-s3

Worth noting that's Barney Frank of the "Dodd–Frank Wall Street Reform and Consumer Protection Act" of 2010.

Also worth noting that it appears Barney Frank helped the effort to nerf Dodd-Frank in 2018 [0] (although I haven't dug deeply into that and from the fact that 3 of the articles supporting this were added today, the wikipedia editor might be injecting a biased view).

[0] https://en.wikipedia.org/wiki/Economic_Growth,_Regulatory_Re...

That was Rep. Barney Frank.

This is private citizen and board member Barney Frank.

But the objective fact of the matter is that crypto IS toxic.

While of course true for many reasons (including facilitating the existence of ransomware while providing literally no other offsetting value) that's not why the bank was shuttered. It was shuttered for the same reason SVB and Silvergate were closed. They had long-duration assets but needed capital now to facilitate withdrawals, which they had a lot of because of the crypto downturn. It was their lack of diversification and failure to adequately manage maturity risk. Which Barney is in part to blame. So of course the fingers are pointed in all directions, especially the gubmint.

> that's not why the bank was shuttered. It was shuttered for the same reason SVB and Silvergate were closed

Silvergate was significantly impaired by the crypto blow-ups [1]. That forced them to sell their short-duration, liquid holdings. It also started their stock-price slide [2]. The combination put them in a uniquely vulnerable and continuously degrading position. Signature wasn't as badly hit by the blow-up, but its stock started sliding with Silvergate. Perceptions matter, and when Silvergate folded, non-crypto depositors began pulling money from Signature.

Had Signature not banked crypto, or been publicly affiliated with it, they would have likely survived.

[1] https://www.bloomberg.com/news/newsletters/2023-03-09/silver...

[2] https://www.barrons.com/articles/crypto-silvergate-signature...

"Objective fact" lol please. Not an objective word in this sentence that you can back up with literally anything. Or we can just take your hyperbole and apply it to literally anything that has any negative sides to it.

Is that why more banks than crypto exchanges have collapsed in the past week?

Got any proof to back up that "fact" or is it really just an opinion?

Your sputtering rage and denial of the obvious is pretty illustrative of my point about crypto's toxicity and cultish obsessiveness.

Do you have any NFTs or ICOs or shitcoin rug pull scams you want to shill, or are you finally too embarrassed to do that in public under your own account because of the toxicity of crypto?

Why don't you prove it's not toxic by telling us how much and why you love and recommend crypto yourself, and explaining what it's actually good for?

You mean besides every day of the last fourteen-and-a-half years?

So the answer is no, got it.

Their philosophy is to "adopt" language features once they're well worn by other languages so they can learn from their mistakes / successes.

I'd choose Java over Kotlin in 2023, in fact I'd do so most years. I'll pretty much take conservative language design over developer comfort every day of the week.

But you do not have to choose Java over Kotlin - you can use them both in the same project without any side effects.

This was by design for Kotlin, and is probably their smartest/best feature. All existing Java code/libs just work in Kotlin. Conversely, most Kotlin code/libs just work in Java, although some care needs to be made there.

Kotlin is amazing to use and read. For most things, the Kotlin version is easier to read and comprehend than the Java version in my experience.

As Java adds language features, Kotlin either gets them for free or already had them (and now can use native features instead of their own custom features).

This is less and less true as Java evolves. For example Java streams expect you to use Optionals to represent absence, which means they interoperate awkwardly with Kotlin which expects you to use Kotlin nullable types to represent absence. Another example: Kotlin has gone through multiple rounds of different ways of doing async, none of which is compatible with Java's new fiber implementation, so they'll either have to go through yet another incompatible rewrite of how they do async or be more incompatible with future Java libraries.

Subjectively, a lot of Kotlin features are implemented in a kind of ad-hoc way because they're designed to be as easy to use up-front as possible, at the cost of consistency. So the language has a kind of "technical debt" - it's hard to evolve it in the future. Add in the fact that the language lacks the higher-level abstraction facilities that would let you work around these incompatibilities (e.g. Scala has its own Option that's different from Java Optional - but this isn't a big problem because you can write a generic function that works on both. But you can't write a function Kotlin that works on both Java Optionals and Kotlin nullable types), and I'm really skeptical about its future.

Personally, I find Java's Optional to be kludgy and annoying to use.

An extension value clears this up in my Kotlin code, something like:

    val <T> Optional<T>.value: T? get() = orElse(null)

Allows you to do:

    repository
        .findByFoo(bar)
        .value
        ?.doSomething()

Slightly ugly, but allows you to gracefully unwrap Java Optional's into something Kotlin understands.

Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.

> An extension value clears this up in my Kotlin code, something like:

You can convert at a boundary, which is fine if you have a line between Java and Kotlin parts of your codebase. But you can't seamlessly mix Java and Kotlin and use the same functions with both, which is what some Kotlin advocates try to claim.

> Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.

I would bet they'll need incompatible changes, because there are subtle differences in the models. (Or they could keep the same API but with subtly different thread safety guarantees - but that would be a whole lot worse, breaking existing code in nondeterministic ways).

In my case Kotlin was harder to read than Java, so it really depends on the person.

(Same thing with Groovy, but that one is even worse than Kotlin)

On the other hand Scala looks nice.

Kotlin adds Jetbrains only as IDE, additional build plugins, an ecosystem of Kotlin libraries for more idiomatic code, stack traces completly unrelated to Kotlin as JVM only understands Java, and it needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes.

Other than Android, there are no reasons for additional complexity in development tooling.

Most of your points are not really valid if you understand Kotlin. It's not different than understanding Java really...

> Kotlin adds Jetbrains only as IDE

Not true, you can use any IDE you want. Of course IntelliJ is the "blessed" IDE, but really, Kotlin is just a bunch of libs, any IDE will work.

> additional build plugins

I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins.

> an ecosystem of Kotlin libraries for more idiomatic code

Which are optional.

> stack traces completly unrelated to Kotlin as JVM only understands Java

I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical...

> needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes

You do not write the boilerplate though. That's the difference. Of course all higher level languages with High Order functions are going to suffer this same issue. It's abstractions all the way down..

You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.

> Not true, you can use any IDE you want. Of course IntelliJ is the "blessed" IDE, but really, Kotlin is just a bunch of libs, any IDE will work.

No I can't, because InteliJ is the only one that actually supports Kotlin.

Otherwise I would just be using Notepad++.

> I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins.

It shows you don't work as build engineer.

> I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical...

Try to debug a Kotlin stacktrace with free functions and co-routines, and then try to tell the world it looks like what the Java compiler would generate.

> You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.

No I don't, because at my level libraries are validated and only internal repos are allowed in the CI/CD pipeline.

Also I no longer do native Android for work, other than mobile Web.

If you do not understand an ecosystem, then you will believe the things you are saying. Nearly everything you claim is simply not true, and demonstrates a lack of understanding more than anything.

You can indeed use notepad++ to write Kotlin. Nothing is stopping you.

Kotlin is not limited to mobile development either.

Kotlin is not limited to mobile development, it only matters on Android thanks to Google's shenanigans, which is a different thing.

And even despite of it, they were forced to update Android Java to keep up with the JVM ecosystem.

> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. We’re working on a new language, but we do not plan to replace the entire ecosystem of libraries that have been built for the JVM. So you’re likely to keep using Spring and Hibernate, or other similar frameworks, in your projects built with Kotlin. And while the development tools for Kotlin itself are going to be free and open-source, the support for the enterprise development frameworks and tools will remain part of IntelliJ IDEA Ultimate, the commercial version of the IDE. And of course the framework support will be fully integrated with Kotlin.

-- https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...

personally i think kotlin is fine, but when compared to modern java, i feel like i need to really see a quantum leap before i'd go all-in if i was running a business (to say nothing of the labor pool for kotlin vs java)

> to say nothing of the labor pool for kotlin vs java

This is the biggest issue, in my opinion. Although, if you have a java developer that really likes the higher order features that are being added, Kotlin might be a very easy switch (after some basic syntax learning).

The nice part is everything you already know about JVM performance still applies within Kotlin. So you're not starting over from square-one like you might assume.

Programmers rarely have consensus on anything language-related, but their preferences are not always evenly distributed. Our decisions re Java aim to cater for the majority of professional teams, which may not necessarily be represented by the majority of commenters on HN. If you don't understand why many more teams prefer a language with choices that appeal to you less over languages with choices that appeal to you more, the answer may be that your preferences are not the same as those of the majority of teams.

This is the most infuriating kind of answer: There are concrete complaints and this comment addresses none of them. Claiming that there are people who prefer Java's syntax to be inconsistent isn't useful without saying why they do.

1. I don't agree the syntax is inconsistent at all. All Java type declarations are terminated with a `}`. Using a different terminator is inconsistent, and that's the thing that requires justification. For the time being, while records are still new, the justification of saving a single character was deemed insufficient. When it comes to inference, I also don't see an inconsistency. Inference infers types or type argument based on the available data. For example, in `var x = new ArrayList<>()` there is simply no information that can allow us to infer a type argument; on the other hand, if a method's return type is `List<String>`, `return new ArrayList<>()` can infer the argument.

2. Even if there were inconsistencies, and certainly when it comes the the concrete complaints, people not only disagree on what's a preferable feature (I, for one, strongly dislike extension methods -- and consider them an anti-feature with a negative overall contribution -- and much prefer default methods) but they also don't pick a language based on one feature or another but based on a gestalt of properties. The languages mentioned by the commenters make different tradeoffs that have significant downsides alongside their upsides (e.g. they don't match the evolution of the platform; they add implicitness that makes it harder for some to read code; they have a lot of features that need to be learned, each of which is pretty underpowered), and it seems that more people prefer the overall tradeoffs Java makes.

BTW, languages also have important meta-features. For example, every language needs to adapt over time, and the question is how it does so. The three languages that have managed to successfully support large programs that can evolve over time, maintained by changing teams -- C, Java, and to a lesser extent C++ -- have shown they take evolution seriously. They maintain compatibility and choose their features carefully (well, C++ maybe less so). Kotlin has lots of features, but it already has more outdated large features than Java because it adds features to address a certain problem and then the platform addresses them in an altogether different way (data classes, async functions), and as a result it's showing its age quicker, too. Java has proven that it evolves well, and many think it evolves better than most other languages.

> Some inconsistency of choices also kinda baffles me. First they added support for skipping necessity of mentioning generic type inside <> during instantiation, only to introduce local vars later that require you to mention generic types within the same <>.

I just came across this as a potential footgun the other day. I had a var list = new ArrayList<>(), then later added a bunch of Foo's into the list, and then when I called an overloaded method with the signatures log(Object obj) and log(List<Foo> fooList), it was calling the Object version. I would think some better type inference should be possible there, but if not, making programmers declare the type(s) at least once is a necessary constraint.

Why don’t just write var list = new ArrayList<Foo>()? The point of inference inside <> has always been to save you from repeating yourself from copying from the left to the right, which is a non-issue when you are saved from specifying it on the left.

Completely agree, but it did surprise me a bit and I didn't find much when I googled around for "don't mix var and the diamond operator."

In Diamond Age the book is being performed by a skilled actor who is voicing many characters using a script entirely generated by the AI.

Many services do some sort of “liveness check” to verify there’s a live human interacting with the webcam for the selfie.

Hm, do they stream user's camera feed to their server? Seems like a questionable practice if the user is not made aware of that.

I've seen cool computer vision demos that run client-side in the browser, so I hope they don't stream the feed. OTOH if they do stream, warning the user would go a long way.

If you send the result only it’s easy to spoof

Good point!