I feel like this article was written by an llm? The way it skips around and makes unnecessary comparisons to JavaScript, the jump from the very beginning to very recent changes, it's all just weird. It feels like it's saying nothing but talking a lot
this post was submitted on 14 Mar 2025
47 points (85.1% liked)
Programming
18971 readers
130 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
That's why it should be made compulsory to indicate when something was produced, even partially, by an AI. This time of your life you spent reading some low-effort no-value bullshit you will never get back, and neither will the hundreds/thousands others who read it. This is a net loss for humanity.
Even if it was, there’s no way to know, people can just lie. It’s not like it will be obvious, some people might have a feeling it is (based on their experience playing with LLMs) but won’t be able to point exactly why.
That is exactly the point, and I wouldn't be surprised if soon there is more money to be made "certifying works made without AI" than there is selling API tokens for LLMs, i.e. the OpenAI business model (although I have no idea of what the technical implementation would look like, perhaps a mix of secure enclave computing offering only a predefined set of capabilities barred from AI, combined with a blockchain to persist and distribute the reference and hash of the works done? More to the tally of GenAI being a net loss for humanity).
Completely agree. It does feel odd.
Knowing Microsoft's AI obsession, I wouldn't be surprised if it is.
Moving to Kotlin taught me to appreciate the underlying fundamentals in the JVM and the patterns present in Java.
I'd rather not use Java today, though. Kotlin is basically Java but with the best practices enabled by default and the bad parts made impossible at a language level.
I need to know more. What are the bad parts that are disabled? Which best parties are enabled at the language level?
Yeah, they're probably talking about nulls. In Java, object references (simplified pointers, really) can be null, pointing nowhere and throwing an exception if you try to access them, which is fine when you don't have a value for that reference (for example, you asked for a thing that doesn't exist, or you haven't made the thing yet), but it means that every time you interact with an object, if it turns out to have been null, a null pointer exception is getting thrown and likely crashing your program. You can check first if you think a value might be null, but if you miss one, it explodes.
Kotlin has nulls too, but the type system helps track where they could be. If a variable can be null, it'll have a type like String?, and if not, the type is String. With that distinction, a function can explicitly say "I need a non-null value here" and if your value could be null, the type system will make you check first before you can use it.
Kotlin also has some nice quality of life improvements over Java; it's less verbose (not a hard task), doesn't force everything to belong to a class, supports data classes which are automatically immutable and behave more like primitive values than objects, and other improvements.
I used to think C# was like Java but with fresh ideas. I still do, but Kotlin gives it a run for its money. The type system is pretty great. For example, you can use the Elvis operator to return early if something is null, allowing you to use a non-null type afterwards. In C#, nullable annotations feel more "grafted on", and there are some weird quirks and footguns that Kotlin avoids by being a little smarter about it.
Besides what other people said, one example is classes being closed by default (you need to explicitly set a keyword to make them open to extension). That was done to prevent inheriting from classes that weren’t designed to be inherited, and forcing you to use composition instead.
null safety, to my understanding
For one thing, the file and class name must be the same. While it is good practice, making it mandatory requirement limits flexibility.