> You can also change your password without confirmation - you don't need to either enter the previous password or double-enter the new password.
This seems to be mostly people who don't know what they are doing? I'd any model would default to requiring this since it's pretty much the default everywhere.
My experience with Opus 5.5 is that, it wouldn't, unless there is a framework that guides them to do it. Most of the times if I don't instruct him to do something more complex, it usually avoids it.
That is very different, because the netcafe own those games. This would be like needing to rent the computer at the cafe, bringing your own purchased game, but then the netcafe also needs a license to allow you to play your own games at the computer.
It's literally what a LLM is, and it's not even a word it's a token which is about 2/3'rds of a word. It has nothing to do with speed of producing tokens. Others are not responsible for correcting your bad understanding of a true statement.
Kotlin has always had smart-casting in if and when (sort of switch) expressions, which are strictly more powerful than the current version of Java "pattern matching". Both don't do de-structuring which I would consider a basic requirement for pattern matching, but at least Kotlin didn't call it pattern matching.
> not to mention that we have yet to adopt a single Kotlin feature; our features usually take a different form, even though Kotlin, Java, and many other languages often rely on the same inspiration, which is usually the ML language
This seems disingenuous at best, or it's a symptom that I've noticed as a user more often that your JDK team seems to have blinders on and dismisses/ignores most other languages even if feature have proven themselves 10 times over.
There's several features Java added or is trying to add, usually 5-10+ years later than Kotlin, and that's ignoring Scala:
* Local type inference
* Switch expressions
* Records, although I found them barely usable because there is no copy() method or with-ers
* String templates unsuccessfully
* A very stripped down version of smart-casting with switch pattern matching
I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard, but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
Local type inference, records, and switch expressions (alongside lambdas and generics) are all ML features, as every language designer will tell you (and Java did them quite differently from Kotlin). All of them, by the way, were well known to Java's original designer in the nineties, it's just that they thought it will be a while until mainstream programmers are ready for them, so their adoption in Java is best postponed.
BTW, even if you're not aware of ML's extraordinary influence on most programming languages, surely you're aware there are competitors to Java with analogous features that are far bigger than Kotlin.
As for string templates, our intent is not to have a feature simiar to what Kotlin offers. We obviously look at all languages regardless of popularity, but in that case, as we did in the case of virtual threads or records, we'll probably say, no, that's not what we want, to Kotlin's approach (even the Preview that we pulled was nothing like Kotlin's approach).
> I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard
Backward compatibility is rarely a hindrance at all. People just talk about it a lot because most organisations consistently say that backward compatibility is much more important to them than any language feature, but it's not all that hard to maintain.
> but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
I find that statement hard to reconcile with the fact that the only languages as popular as Java or more are JS/TS and Python, while all the languages that are not "weaksauce" from "a developer's perspective" are doing far, far worse than Java. There has never, ever, been any sort of consensus among developers on the right set of features, and there have always been developers who prefer more features and those who prefer less. It's perfectly fine to be on one side or the other or even to say, "yes, I'm in the minority, but I still think I'm right", but I find it strange to claim to represent "the developer's perspective" when your preferences are mostly associated with languages that are doing worse rather than better.
> even if you're not aware of ML's extraordinary influence on most programming languages
There are definitely many programmers who have a very parochial understanding of programming. They know one or two languages well, they've never been interested in what else might be possible - maybe they never took a language survey course or they barely paid attention in that class - and so they genuinely do not know what else is possible or what might be normal in other languages. This happens to spoken languages too, in English "singular they" was already right there ready to be used for cases where we do not want to specify gender, in some languages there was never an issue here, gender was only ever an optional adjunct so just don't specify if you don't want to, while in others a default gender is so engrained into the language that you're basically fighting the assumption just to say a simple sentence. But if you only know English there's no reason you'd realise that varies.
I get your point, but Kotlin is still what made many of these specific features widely known to java developers, and accelerated the push from devs to get similar things into java.
Mind you, I like that java has taken its time to get the features right. Of course, java has had the advantage of enhancing the jvm while adding the features, where Kotlin had to work around the jvm in some cases (like green threads vs coroutines).
So I prefer javas version of many of the of the more modern things (but do miss Kotlin's lambdas and vast library of extension functions when writing java). But I feel it's wrong to downplay Kotlin's role in modernizing things on the jvm. Heck, if it weren't for kotlin as a temporary stopgap, I'd probably would've left the jvm while the features were still lacking in java.
> I get your point, but Kotlin is still what made many of these specific features widely known to java developers, and accelerated the push from devs to get similar things into java.
I disagree for an obvious reason: only a small minority of Java developers know Kotlin. When we want to see if the median developer is ready for some ML feature, we certainly look at other languages, but Kotlin doesn't matter beyond its size (which is not inconsiderable, but is also nowhere near the largest Java competitor that's quick to adopt features).
> Of course, java has had the advantage of enhancing the jvm while adding the features, where Kotlin had to work around the jvm in some cases (like green threads vs coroutines).
And C# could have done the same as Java but instead did what Kotlin did (or, rather, Kotlin did what C# had done), and we looked at both and said: we don't want that. That's why I'm saying that the "catching up" narrative doesn't hold up to any scrutiny.
Obviously, Java has been a huge innovator in optimising compilers, garbage collection, and low-overhead telemetry — areas where it's ahead of virtually everyone else — and focusing innovation on the runtime rather than the language has been one of James Gosling's stated goals since the beginning. So catching up is also silly when talking about a technological leader.
> But I feel it's wrong to downplay Kotlin's role in modernizing things on the jvm.
I'm neither downplaying nor overplaying it. As one of the Java architects, I'm telling you what it is. And "modernising things" on the Java Platform ecosystem is quite a different thing from influencing Java language features.
When we discuss other languages, and we discuss all of them, the ones that are discussed more are either the bigger ones or the more novel ones. Kotlin has shown some novelty, especially around its design of generics and of nullability types, but these happen to be two areas where we have actually not (yet?) made changes.
> Heck, if it weren't for kotlin as a temporary stopgap, I'd probably would've left the jvm while the features were still lacking in java.
That may be true, but it's irrelevant to what we're discussing. If anything, if Kotlin had served as a significant enough stopgap for those developers who prefer richer languages, it would have helped us not to adopt certain features or to adopt them more slowly.
I'm not saying Kotlin hasn't had a positive influence on the platform and, indeed, it may have helped especially in those years when Java stagnated, but it didn't push Java toward adopting more ML features.
> only a small minority of Java developers know Kotlin.
This is just so wrong. I don't know a single Java developer who does not know Kotlin. In fact, almost everyone is using Kotlin for most code, with Java being mostly used in legacy projects.
I know you'll answer that I am in a bubble or whatever, but it's frustrating how you think that's a valid argument you can make against me, but not me against you :D seriously. You have no idea what my experience is. I've worked in several countries so I can tell you my experience is not just local. I still like Java (and with Java 28 I am becoming hesitant to continue using only Kotlin for new projects) but anyone who cares about new features like pattern matching was already on Kotlin a long time ago.
I didn't base my statement on personal perception but on industry reports (which report numbers similar to job numbers like these: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...). It's possible that your perspective industry-wide is more accurate than that of the business analysts, but I have no reason to assume that's the case.
> but anyone who cares about new features like pattern matching was already on Kotlin a long time ago.
First, that doesn't mean it's not a minority of people. And by the way, we don't base our decision on which language feature to include on the number of people who are already asking for a feature (which is always a small minority) but on the number of people we believe will be significantly helped by a feature once they learn about it. I.e. it is perfectly possible that 100% of the people who wanted pattern matching before we added it had left for Kotlin or Scala and at the same time that number amounts to only 10% of the people who enjoy the feature and benefit from it in Java. That many mainstream languages add a feature is only a signal to us that the median developer is ready for it if we decide it's a good feature to add. I've been using pattern matching since the late nineties when I first learnt ML and a bit of Haskell (Haskell was the language of the future back then), but if I were a language designer back then, I'm not sure I would have thought that it's a feature a mainstream language should have prioritised in 1998.
Second, we don't have usage telemetry in the JDK so we don't get a full picture, and instead we rely on the usual sources for this kind of information: meeting with large customers and analyst reports. If you have access to more comprehensive statistical data, then I would be interested in seeing it, but it's a well-known phenomenon that people are usually only directly exposed to information about their own circles and don't have industry-wide data. The Java ecosystem is huge, and like the situation with the software industry in general and enterprise software in particular, most Java software isn't even written by software companies.
While I'm sure I'm also in a bubble, the numbers you present are far far off for instance Jetbrains' state of developer ecosystem reports. Where kotlin is roughly at 1/4th of javas usage, but for android quite high, and for backend up at 49 %
Which matches what I've seen. Every single huge company or government function in Norway have the last years written most of the new code in their applications in kotlin. Basically all java conference talks I've seen has kotlin as the backdrop.
Kotlin's impact in preparing java devs for more functional code has been tremendous.
Of course it is quite high for Android, without Google making Kotlin a required language for Android development, and stagnating Java support on purpose, Kotlin would never have taken off.
Also JetBrains is the creator of Kotlin, naturally they want to show their baby is being adopted.
I see you drank the kool-aid. Add this dot to your chart: I know Kotlin and _much_ prefer Java.
Also, rest assured that there is still plenty of corporate drones that don't know Kotlin and couldn't care less because Java puts food on the table while providing a stable consensual development environment. Kotlin opens many doors, most of which should have better be left closed.
If anything you sound bitter and threatened, which is weird to do over someone liking a programming language. Dismissing everything as them having drank cool-aid is not befitting of this discussion or forum.
I agree I have an attitude problem, Kotlin triggers me like nothing else. I'm scared that a semi proprietary kludge will replace my still totally adequate main language for superficial reasons of syntax sugar and hype when I can see the pitfalls from a mile away and taste them everyday from our overeager architect.
And it pisses me off even more that my tooling provider is the party actually building and promoting this substandard replacement and that I can't boycott them because the other IDEs are either legacy clusterfucks (eclipse) or glorified local websites (vscode).
As much as I try to keep my composure on HN and stay constructive in my contributions, I don't know how to help derail this particular train.
Yeah you really are triggered, describing Kotlin as a substandard language is pretty wild. It’s a mostly loved language by everyone using it, even Android developers who are forced into it. I can just say, maybe try it and forget whatever grudge you have with it, it will just make your life better.
>I'm sure there's tech-debt and esoteric compatibility concerns which make evolving Java hard, but from a developer's perspective it's just glacial to evolve and the result is weaksauce.
This used to be the case a few years ago. But not anymore. Java is evolving very rapidly compared to those years.
> I heard the reason was that NL doesn't know if SUSE will be sold off again and might end up in the hands of some US PE, but here's the thing, you're the government, you can just block the sale of companies
The Dutch government can famously prevent sales of German and Luxembourgish companies yes.
I meant the EU, at EU level, not the Dutch government. Also it's not like the Dutch government can't cooperate with the other EU members like Germany and Luxembourg on such vital topics. Unless of course trust inside the EU is so lackluster that the Dutch government can't be sure where Germany and Luxembourg will stand, in which case it's already over for the EU.
Does the EU have the power to block sales of companies on national security grounds? Or to get member states to standardise on software?
Its probably a good thing they do not have a standard, or at this point it would be Windows and pushing change through at the EU level would not be fast.
>Does the EU have the power to block sales of companies on national security grounds?
Not on defense and national security, that's up to individual EU member states, but the EU does veto corporate mergers and acquisitions on Competition Law (Antitrust). So just find a loophole in that and use it to prevent SUSE be taken over by non-EU nations.
The governments "just" doing this or that, are typically the tyrannical or unhinged variety you don't want to live under. If your law is written decently and you have a functioning judiciary, chances of a loopholes surviving scrutiny will be very low.
The European Commission could definitely ask governments (the European Council) to agree a new treaty or protocol that grants them veto powers on "federal security grounds", for sure. The European Parliament would likely rubber-stamp it too. Considering the current (and increasing) right-wing majorities across the continent, though, I find such scenario very unlikely.
>The governments "just" doing this or that, are typically the tyrannical or unhinged variety you don't want to live under.
You can always "just do things" whenever you want by interpreting or changing the laws first to fit your desired goal. And so there, now it's legal, because I just changed the rules to make it so.
Same how the "we'll now have to accept all those migrants illegally crossing our border without asking our voters if its what they want" was done, they decided overnight that its legal. Or how they can just block the right wing from winning elections in order to "just protect democracy".
We're already under tyrannical rule, except the system abuse just acts on the wrong topics.
As an American, EU politics is such a fascinating bizarro world. Imagine the right wingers being a bulwark against unhinged expansion of executive authority on grounds of national security! It would be like statehouse Republicans blocking the Patriot Act. Unthinkable.
Well, the same in the other direction: imagine the free marketeers by definition, installing an autocrat big on isolationist policies, the dismantling of judiciary separation, and on picking winners in the market... Absurd! And still, here we are. Humans are funny and inconsistent like that.
Right back at you: Imagine being a European getting fined/arrested for memes(UK), or that you called a politician a dick on facebook(Germany).
How are those rape gangs in the UK this time of year? Did the UK government ever get in trouble for covering that up that scandal and calling the whistleblowers pointing it out "racist white supremacists"?
Those are all historical offences, dude. For all the disproportionate attention it gets, it's not really been a problem for some time.
And anyway, this has nothing to do with the item being discussed, which was about the mismatch between declared party orthodoxies and actual everyday practice.
Yes, they are neoliberals, which are hardly left by international standards. European social-democratic parties, which are the traditional Euro center-left, are generally on the back foot right now.
TBH this whole left-right thing is pretty new in the US. The political science term is "ideological alignment" (we didn't really have it for a long time due to our weird party system) if you want to read about it. This is changing now to an extent, but there was also a taboo for a long time against identifying as being a leftist, what with McCarthyism, COINTELPRO, etc.
For context, the US once prevented that a German company AIXTRON was sold to a Chinese investor in 2016 (perhaps for good reasons). To me it would sound like a good deal for the Netherlands and Luxembourg/Germany if Netherlands would uses SUSE and the Luxembourg/Germany would step in to keep in in the EU.
Isn't it odd how Germany needed the US to stop them from committing a(nother) suicidal mistake regarding their industry sovereignty?
I wonder, is anyone left in the German government now (that isn't a paid lobbyist) that is even remotely interested on covering their industry sovereignty?
Every so often I hear about new footguns Germany used on itself.
Yeah GPT 5.6 models did it a lot and Opus is absolutely awful on this. It's clearly encoding it's thinking/context into the comments. GPT-6 models seem to be better about it.
Are we talking, like, a ton of verbose comments? Because “what were you thinking here?” is kinda-sorta what I want in comments. As opposed to the old “telling me what I can already see.”
The data is stored in ~/.cache which has the contract that it user-wide cached data, which also means it can be deleted without severely impacting programs.
It seems the author has too high expectations of this feature, or vim is using an incorrect path to store this is they want to make it available more reliably
The feature that was broken is called persistent undo. The feature was inherited from Vim. In case it's not obvious from the name, nowhere does it state in the docs for persistent undo that data may be deleted at any time.
This reads to me like a case of blame on both sides. Putting data you don't want to lose in ~/.cache is PEBKAC, but if that fact is incidental and NeoVim would have removed the undo history regardless of its filesystem path, then the point remains valid that NeoVim is deleting user data that isn't its place to delete.
A lot of the comments here are getting caught up in legal arguments which may or may not be valid. Those are irrelevant. No one is taking the NeoVim developers to court; the post is merely warning that they knowingly accepted behavior which can cause harm. The question is whether or not that choice was responsible, not whether it's legally actionable.
What a weird straw-man. The comparison here is a program breaking compatibility with a file in ~/.cache/... and deleting it instead of providing compatibility. I'd do that without thinking about it twice.
I don't see it as a strawman. The comparison here is a program breaking compatibility with a file _used by another program_. If vim and neovim undo files are incompatible, why does neovim delete vim's file instead of using its own file name/extension and not caring about vim's undo? And why do they use the same subdirectory even? To me it is a case of a program deleting cached files of another program, which, as a user, I see as deleting user data that said program should have touched.
This seems to be mostly people who don't know what they are doing? I'd any model would default to requiring this since it's pretty much the default everywhere.
reply