Meta keyword tags have always sucked even without malice. Because they're invisible, authors frequently forget to update them, copying <head> boilerplate between documents.
When designing a standard like this you need to apply systems thinking.
The poor data quality is a problem for anyone who wants to use the tags, which has seen everyone almost universally reaching for other solutions. Search engines have preferred anchor tags, bookmarking solutions have applied user tagging.
With keyword tags it's been a vicious circle of poor data quality and neglect since day one. Even in documents from the early 1990s when people were really trying, the data quality is inconsistent at best.
Language that runs on the explicit design philosophy of letting other languages experiment first and then incorporating their lessons learned once the dust has settled is late to implement a feature.
It's stable to the point of boring, and there's no shortage of people who know the language and can work with it, it's got best in class tooling, decades worth of libraries almost all very mature. Most of the language's issues are from legacy code bases coded in a style that isn't really relevant to a greenfield project.
The ecosystem has (at long last) standardized on JSpecify (https://jspecify.dev) for nullability annotations. JSpecify allows you to annotate a package or module with `@NullMarked` and your IDE and build (via ErrorProne+NullAway, typically) will check for null safety.
If you develop a library in Java and use it from Kotlin, the built-in Kotlin null-safety will recognize the JSpecify annotations on the library.
Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.
I get it why this seems like a less drastic change, but this saddens me. Kotlin solves more issues with the type system (smart casts, reified types, immutability by default), without sacrificing readability. Unless I can see a solution in Java that makes dealing with NPEs as easier for lazy developers as ignoring them, I don't consider it a solved issue.
I don't really think about it too much, it works fine. We don't use Optionals, I'm not sure why you brought that up. I'm not a dogmatic person in this respect, rather pragmatic. I'm sure Kotlin is great, and I'd enjoy writing it, but for now, the vast majority of the finance world runs on Java, so it's what we use. I find it easy to work with, which counts for a lot.
> Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.
You deserve the strawman award of the year.
NullAway and JSpecify encourage making as many types non-nullable as possible, thus they can actually also advice about removing redundant null checks. Nullable types become the painful exception that visibly spreads through the codebase, which discourages writing code that relies on null.
Optional doesn't enter the picture at all. NullAway kills their usecase within ones own code. They are anyway only recommend as return types to force others to check for an emoty case, but I think Optional will become fully optional when the Java platform gets nullable types on its own.
Google Error Prone is a code linting tool that's very useful in its own right, and NullAway is just another plugin.
Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic.
I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of day compared to Project Valhalla, as things currently stand, Go is in the same position as Java: They are both extremely prone to NEPs out-of-the-box and they both have external tooling that can help you avoid them.
Java null checkers have more comprehensive coverage potential compared to Go, but Go is the more ergonomic one here. You don't need a single extra annotation on your code.
It's a panic in Go, not an exception. In practice that's usually a whole process crash. You can catch panics and kinda use them like exceptions, but it's not conventional.
Oh, net/http recovers from a panic inside a handler and sends error 500. I don't know if that was always the default. Where I worked before, our own Go servers didn't recover, and it did cause outages.
This is kinda bad practice. Go and Rust panics are similar, they aren't exceptions that you can safely recover from. Say there's a panic in the middle of modifying some global state like a database connection. Hence complaints about the net/http recover like https://github.com/golang/go/issues/25245 . But I guess they decided it's worse to let servers crash from trivial mistakes.
Can I trust code I’ve written myself with no guarantees from the language? Maybe. Can I trust code written by dozens of other developers (and/or agents) working on the same project over multiple years? Definitely not.
Can you explain what the issue is with nullability here? Is the concern that someone's code returns null in normal circumstances but doesn't document that well, so you don't check if null? Cause if it's an error situation, one way or another some exception has to be thrown.
Most engineers do not have the ability to impose rules by fiat on all of their coworkers. It seems like you're misunderstanding the nature of working on a codebase as an IC when other developers contribute to it. If all of my coworkers don't want a lint rule I propose, I don't get to add it. If all of my other coworkers want to write code in a certain way and approve each other's MRs with code written in that way, I don't get to veto it.
Most engineers don't get to decide to use a language either. Usually someone with the clout to pick a language has the clout to set style requirements too.
They do get to decide which jobs they take. And the languages involved are one of the easiest filters. A lot easier than checking whether the code a company actually writes is any good.
Theoretically you don’t need to write AbstractFactoryProvider in Java, but looking at languages mentioned in job offers, I have a pretty good idea of which of them have a high probability of working with such code and which do not, even if all of them say they have the best code ever.
There are plenty of reasons why someone might not have a wide range of job options available and need to prioritize based on other factors than the language they have to use.
For concrete example, it took me a long time to find a job last year due to only fully remote being viable since my wife's autoimmune condition means I'd be risking her health by commuting, and nowadays most places seem to either expect hybrid if you live near an office (I'm within the geographic limits of NYC despite being nowhere near Manhattan), restrict by time zone (there were quite a few jobs I was interested in where they only would accept remote with Pacific or Mountain Time), or have onerous travel requirements (multiple opportunities I interviewed for didn't work out because they expected me to fly to the west coast every couple of months, which between the time there and jet lag would mean I'm not productive close to a quarter of the time).
I was in a fortunate position to be able to hold out for a while and ended up finding a fully job with my preferred language after around eight months, but I had already come up with a timeline for when I should start relaxing certain constraints if it went on longer. Programming language was literally the first constraint that I was going to drop if it lasted a few more months because prioritizing my wife's health is non-negotiable, and I'd rather work in a language I don't like as much on something that I don't feel is actively making the world a worse place than work in my favorite language on adtech or at some cryptocurrency startup. It's not clear to me why it would be a problem for me to care about using my non-favorite programming language well if I happened to be employed to write it.
I don't disagree, but that sounds more like a response to the person asking "what's the argument for picking Java?" than one to the someone who finds "Have you tried not returning null or constructing incomplete objects?" and "Why don't you have any coding standards?" to be poor takes.
If someone's asking "why Java" or is saying nulls make it a hard no, then you'd assume that they have a choice in the first place, which generally means they also have some ability to set coding standards at the same time that they're choosing a language.
Scala technically allows you to use nulls or throw exceptions pretty much wherever (necessary for Java compatibility), but it's not an issue because people simply don't outside of super niche situations (generally some low-level thing, or a shim). Similar to `unsafe` in Rust. Or casts in all sorts of languages.
Just for reference, Scala actually has proper null safety. You can turn it on with a compiler flag and then use union types to denote nullable types, like String | Null
> If someone's asking "why Java" or is saying nulls make it a hard no, then you'd assume that they have a choice in the first place, which generally means they also have some ability to set coding standards at the same time that they're choosing a language.
I don't understand that logic. I sometimes ask people to explain why they think a certain policy should be implemented by the government after they state their support for it, but I don't have the ability to set government policy. I have trouble imagining you genuinely assume that any time someone asks you why something should be the way you say that you think they have the ability to change it if you convince them.
Of course you assume that; if you're talking about what a policy should be, then you work in a hypothetical world where the policy can be chosen. You don't say "but what about some other minor detail! That would require an additional policy choice, and we can't change related policies."
Like if I think my business should open an hour earlier, and you say "but the employees won't be there yet so who will open the doors!" obviously the solution is to also change the work schedule. When you have closely related policies, generally the same person/people are empowered to make both changes.
Yes, a hypothetical world, not necessarily the real one. The first comment you responded to from me was me responding to someone who said "Why don't you have any coding standards?". It sounds like the answer to it that you're proposing is "I do, but they're just all hypothetical", which I guess isn't technically wrong but it's entirely irrelevant to the real-world circumstances that you still haven't addressed in any way from what I can tell.
Precise wording aside, the essential content of the back-and-forth here is:
> When should one use Java on projects?
> One shouldn't consider Java because it lets you use null.
> That's easily solvable by just not using null.
> But you can't just do that. People will use it.
> You can just do that. Tell them not to.
Like I'm not seeing the issue. This is like saying you can't use Rust because people will use `unsafe` because it lets them do C programmer things, and then claiming it is simply impossible to tell them not to do that (and set tool policies to flag anyone attempting to).
In the real world, if you're in a position to even ask "why use Java for a new project?" then you are presumably also in a position to have "don't use nulls" be a satisfying answer to "what about nulls?" If someone is asked what technology to use for a project in the first place, they are almost certainly also asked about how it will be used. The hypothetical here is not "do you have coding standards" but "are you a decision maker," and when the original question is "when should one decide to do X," you have to accept as a premise that you are placing yourself in the role of a decision maker in the first place.
> Like I'm not seeing the issue. This is like saying you can't use Rust because people will use `unsafe` because it lets them do C programmer things, and then claiming it is simply impossible to tell them not to do that (and set tool policies to flag anyone attempting to).
I'm not seeing how you can seriously claim that the amount of unsafe used in Rust over the past 11 years is anywhere close to the amount of null used in Java for the past three decades. The vast majority of Rust projects don't have any unsafe used directly in them. I have trouble believing that the fraction of Java projects that don't ever touch null is anywhere close to as high.
> In the real world, if you're in a position to even ask "why use Java for a new project?" then you are presumably also in a position to have "don't use nulls" be a satisfying answer to "what about nulls?
You keep framing questions as something people only ever ask if they happen to have the power to make decisions, and that still makes no sense to me.
> The hypothetical here is not "do you have coding standards"
That's almost the exact question I responded to initially! You responded to me responding to the question "Why don't you have any coding standards?". I feel like you're trying to argue against me as if I commented several levels above in the thread than I actually did, and then getting confused by me not accepting that premise.
The question was about greenfield projects, not all projects in existence. In a greenfield project, you can set your own standards, be judicious about what libraries you use, etc.
I'm not framing it as a question one only asks if they happen to have the power to actually decide to use it; obviously a curious student might want to know why large successful companies continue to use the JVM even for new projects. I'm saying that the answer can be given from the perspective of someone who does have that power, and that the question is really "if I can choose a language, why would I choose Java." That doesn't imply that the person asking actually has that power, but it prevents silly answers that are addressed by "don't do that."
Everyone has to deal with other code that might not even be from the same org. The "check it in CI" answer isn't an excuse either. You're bolting on so much extra crap that way.
I just don't see why nullability is a problem in the first place.
I don't think I've encountered an external library that returned partially constructed objects returned nulls (at least not without a @Nullable). There are probably cases of this existing, but those types of libraries don't tend to see a lot of users.
I admit I haven't worked in Java for years, but no project I've seen at my current company (the only one I've worked at since agents have been a useful thing) is anywhere close to removing all dependencies. From what I've seen, people want to spend tokens on new things, not things that are already known to exist. Even if you can reinvent the wheel, it's not something that an employer is going to be particularly happy to subsidize.
I’m not sure how long it will take, but please - can we stop saying that annotations like @IHopeThisWontBeNull is a toy for kids and, having so many years of incidents caused by those and having LLMs to write and fix the code, we can rely on language and compiler already?
You're drawing a distinction that doesn't matter in practice. If you encounter a NullPointerException incident then you either didn't annotate your code or you didn't run the tooling. (In fact before even running your CI suite, any serious IDE will tell you immediately that you've mishandled null somewhere.)
I get that some people feel like it ought to be built-in to the language rather than a separate tool... but people's personal feelings are irrelevant to the lived experience of my day-to-day work, where worrying about null is truly a thing of the past.
It is really not a big deal nowadays, the problem of the same scale as having index out of bounds error (no language has good defence against this, yet it is not a catastrophe).
That's expected (the index out of bound). You have an array, and maybe it grows, you read a number from input, you don't check it against the size of the array because you want to torture the language, use it to get the element at that index and... I'm sure that there is a surprisingly number of different designs of what it should happen and a number of designed ways to ensure that it doesn't happen. But a runtime error is expected.
yes, so are the NPEs - both are runtime errors indicating a bug in the code. NPE was a major source of irritation 20 years ago, but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source. And the culture has evolved.
> but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source
Unfortunately, no, they don't. Not after your application has been running for a while; newer JVMs arbitrarily decide you don't need the stack trace anymore, and all you see in your logs is "NullPointerException" (unless you still have the logs from several weeks ago, just after the last JVM restart, which might still have the full stack trace). Older JVMs were better, since they always had the full stack trace; debugging NPEs was easier with them.
The problem with array out of bounds is that you'd need to reason about arithmetic expressions over natural numbers. However, in general that's a very thorny problem since one runs squarely into [Gödel's incompleteness theorems](https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_...). Working around it requires painful restrictions or cause uncertainty over whether the compiler will apply certain optimizations.
Unlike C it is trivial to catch a NullPointerException and confine the crash to the unit of work. And unlike C you are not talking about insanely dangerous pointers, you're just talking about an NPE.
I'll admit it's a hassle when something wasn't initialized properly and then you get a null pointer exception at some unrelated code much later. It's not always easy to debug. Catastrophic? No!
There are a lot of third party tools that can check for null safety and a lot of work is being done to make Java's initialization safer but also a little more flexible, there is
and there are all sorts of practical answers. Nulls in Java are low on my list of annoyances, way behind front end programmers who pepper my CSS files with "!important" because they don't know about precedence (though maybe they think my .clazz.clazz.clazz selector is brain dead!)
I was alluding to how people who fall out of favor with Putin have a tendency to have mysterious fatal accidents, more than 10 of them falling out of windows.
So what I'm saying by saying that he fell out a window is that Putin and/or the FSB arranged his death. It's not a statement of the means of his death, but who arranged it.
Embedding the image would have ruined the comedic timing and made it less funny. Comedy is mostly about subverting expectations. If your eyes are drawn to the punchline before you read the set up it doesn't work.
I hope that this is temporally and spatially far away enough. In order to fully appreciate the joke, one should have read https://openai.com/index/navier-stokes-solution/ (I didn't beforehand).
The current valuations are only inflated until they're not. Especially if the big American labs can convince the US government to work out a joint "AI non-proliferation" agreement with China which will allow both countries to essentially carve up and techno-colonize the rest of the world without any other competition except between themselves.
We're already seeing signs of this strategy from Open AI and Anthropic warning about the dangers of AI and the need for safety regulations. None of that stuff matters if China is not also on board with it.
> The current valuations are only inflated until they're not
You could say that about any historically inflated valuation all the way back to the tulip mania. Either the expected profit materializes or it doesn't.
> We're already seeing signs of this strategy from Open AI and Anthropic warning about the dangers of AI and the need for safety regulations
I would read this as a desire to pause training to be able to present a profit in anticipation of the IPO. The major AI labs mad scramble to IPO is if anything a sign that they aren't at all confident in the valuation. If they were they would be no hurry to cash out.
Big pivotal moment is probably the DMCA and the DRM it's enabled, it's really eroded the concept of ownership in both software and hardware (via firmware), to the point where we've completely lost all control over the devices we buy.
These days devices do what we ask when it benefits their real owners, and refuse to do what we ask of them when it doesn't.
It wasn't an overnight thing, but the temperature in the pot has been increasing for well over a two decades and it's getting more than a bit sweaty.
It's not like Doctorow, the EFF, and a bunch of others didn't warn us. They told us this would happen. Like exactly this.
I don't think "jailbreak and install your own software on your TV" would be common even without the DMCA...and it would still be necessary, nothing would be stopping the companies from writing these stock software systems.
I brought this up all the time I argued with co-workers I advocated for Open Source because I knew where this was headed and every time it played out the exact way this comic did.
Now I just post a link to this comic in discussion about these kind of things.
https://xkcd.com/743/
Open source caused this, as much as anything else did. When you demand that software is free, you kill the market for paid software, leaving only enshittified software to fill the void. This has the dual effect of being worse for both developers and consumers: significantly fewer developers can make a living outside of working for $EvilEnterprise, which have an easier time centralizing and monopolizing the market, and consumers are paying the developers working at $EvilEnterprise with their data and lack of ownership. This is the business model of free software. There was never going to be a world where all software developers worked for free as a hobby, never received compensation, and all software was truly free.
I don't know how you can simultaneously believe that open source is prevalent enough to kill paid software but also non-existent enough that it doesn't itself fill the void it supposedly created.
Because that void is filled by open-source software that, even if it is not itself enshittified, is controlled and funded by big tech. Take languages and compilers, for instance. It is almost[1] impossible to make a living developing languages and compiler software independently or as a small business. So how do compiler developers get paid? By receiving funding from Microsoft, Google, et al. C, C++, Rust, Go, JS, TS, C#, Java, Python are all owned by big tech, who fund them with their revenues from doing exactly the evil big tech things being decried here. Linux funding is the same story. Browser funding is the same story. So too for most open source 'success stories'. There are exceptions, like SQLite, but they are rare. To the extent exceptions exist, it's mostly due to B2B consulting and enterprise contracts, which is not a business model that works for consumer-facing software of any kind.
[1] Zig is, I think, the only living counterexample.
Open Source never meant having to give your software away for free, it was always free as in speech. In that you could see the crap you got and change it if you wanted to.
But you're right I'm sure that if there hadn't been the GCC there wouldn've been a ton of competing compilers. I'm sure that it was the existence of Apache that ruined computing and brought about the enshittification of the web not MS trying to force everyone to cater to IE and then Google doing the same with Chrome, it's all just because of that evil Open Source.
> Open Source never meant having to give your software away for free, it was always free as in speech.
Sure, sure. And how exactly is software not also free-as-in-beer when any consumer can just download it themselves?
> if there hadn't been the GCC there wouldn've been a ton of competing compilers.
As I already noted in reply to your sibling comment, which you conveniently chose to ignore, every single one of those competing compilers bar one is funded by big tech. You can count the number of compiler developers who make a living without being funded by big tech, in the entire world, on your hands. GCC development is itself supported by big tech.
> Google doing the same with Chrome, it's all just because of that evil Open Source.
Do you need to be reminded that Chromium is open-source software? There is no market for competition to Chrome because no browser developer could compete with "free". Firefox is open-source and also propped up by billions in Google funding. There are zero consumer-viable browsers that are not just a Chromium or Firefox reskin.
You even brought up IE, which is an example of the exact principle I'm talking about. It wasn't open-source, but, same as open-source software, it was free, and this big tech-funded free software killed its paid competitor (Netscape). This was a huge deal at the time, enough for the US government to get involved in antitrust. Then MS got let off with a gentle warning, everybody shrugged their shoulders, developed amnesia, and decided actually it's great if we let 5 or so tech monopolies undercut all of their competitors with 'free' software and solidify complete control of the market.
Netscape died because we all hated it. Back when Apache didn't exist yet, we were forced to run Netscape's server. (Even if Apache did exist, we didn't have the $20K per-seat license fee for DEC's C compiler so we wouldn't have been able to compile it anyway). Netscape's license terms were such that we had to open our books to them. They would read through all of our transactions and decide how much we would have to pay them that term. If they saw transactions to a party they didn't like, they would charge us more. They had no competition in our space, so they could name their terms. There was no competition and they liked it that way. When Apache became available we switched to it out of spite.
The freedoms that the GPL gives to users in effect means giving your software away for free (because any single one of them is allowed to republish it openly). I do think there is a possible alternative model which gives most of the user freedom Stallman cared about but which doesn't produce this (something along the lines of being able to view the source code of software you buy, as well as modify it, but only being allowed to share the modifications with others who have bought the software, or only being allowed to distribute the patches as opposed to republishing the full software), but this hasn't really been tried as far as I know.
I guess back when software only came in disks that sounded good business wise. Today if I can get your source I’ll compile it, price a bit lower and publish it in a few hours.
Eh, areas where there was and is still plenty of scope to just charge for a product have also been heavily enshittified, so I don't think you can lay much blame at open source for this.
Regardless who is suing the cost falls on the spammer. General consensus among these agent bros seem to be that these laws don't concern them, when what they are doing is exactly the sort of things these laws are targeting. Wheels of justice may grind slowly and this is the sort of stuff that doesn't hit you 5 minutes after you start spamming, but they do still grind.
Yes[1]. Most people within the CAN-SPAM jurisdiction have their shit together well enough not get fined, but this does not seem to include many of the new wave of agentic spammers. Could be they're out of jurisdiction, or that they simply aren't aware or too naive and think this law isn't in effect.
Yeah I think almost anyone will agree that these matrix formulations are more confusing than helpful. The subject itself isn't really that complicated, but the jargon and notation makes it a lot less approachable than it is. Unwrapping the operations with explicit summation makes it a heck of a lot clearer what is happening.
There are places where matrix expressions are informative and helpful, but at least in the context of teaching machine learning, this isn't one of them.
Hard disagree, to the point where I'm not sure there's not some confusion at play here.
I find using indices and summations generally confusing and hard to read/follow/understand. To me, it's so much simpler to draw out the computational graph, derive the gradient with a single element (so I'm in agreement with you guys here?), see how that applies the same to every element the same, then scale up to the vectorized/matrix version.
> and you need to memorize a bunch of new rules to apply it
There's nothing to memorize though..?
Is there something called "matrix calculus" that's different than just drawing the computational graph and deriving the gradient in the way I described..?
Now that einsum syntax is supported in languages like Python and Julia this is more true.
Before einsum syntax, it helped if the result could be written in terms of matrix operation because then one could utilise the primitives offered by matrix libraries. The alternative was to write the raw low level index loops, tedious and errorprone.
For some cases though the matrix result is just more compact. For example the derivative of log determinant of matrix wrt the matrix.
Most larger businesses are kinda resistant to building stuff in house since it means that stuff has to be owned and maintained for as long as its needed (possibly decades) and you can't just rely on a SLA and the legal team to ensure things are working in perpetuity.
The danger of vibe coded SaaS:es isn't the customer building the thing themselves, but that the increased competition drives down the profit margin.
reply