441–450 of 777 posts
Sad this gets to front page while a blog post which documents that .NET 8 has 200 A4 pages worth of performance improvements gets absolutely ignored. C# keeps being the language people are looking for but don't know about.
Earlier quoted context omitted.
No, there's a lot wrong with inheritance. It leads to all sorts of issues and while theoretically one can keep the tree 1 level deep, in practice it's too tempting to expand the hierarchy. This is one of Java's big issues. The other is reference equality as a default, pretty horrible. Records help but records are also limited in when they can be used.
> No, there's a lot wrong with inheritance. No, there is a lot wrong with bad code . No need to blame the language or any programming concept. Note that I say that for all programming languages, not just Java.
Earlier quoted context omitted.
> If there was any feature that would sway existing Golang developers to switch to Java, it would be this. Not sure about this, but a trajectory question: why does the Go community have so few concurrent containers but Java community does? I mean, even `sync.Map` is specialized for two specific use cases instead of like Java's ConcurrentMap that is of general purpose. And In Java there are concurrent sets, queues, ba…
Because the predominant patterns are to do concurrency with message passing, so having multiple goroutines trying to mutate the same container is the exceptional case (though as you say, mutexes are the answer when needed). Another reason is containers are embedded features not stdlib, which has huge implications to how willing someone is to go against the grain, for better and worse.
Earlier quoted context omitted.
The go example is missing the channels, select, wait group, context, cancellation Doesn’t sound like a fair comparison thou the Java version is missing things
> The go example is missing the channels, select, wait group, context, cancellation The Java version would require all of those in the exact same way though.
Earlier quoted context omitted.
Prefer composition over inheritance has been a common mantra for at least a decade, if not more. Maybe you should undergo the last decade of development and training. There will always be shitty devs, and since java is one of the biggest languages, it definitely has more than some ultra niche academic language no one uses. I don't think it is the fault of the language though, or if that somehow were a reason to choos…
> Prefer composition over inheritance has been a common mantra for at least a decade, if not more. Maybe you should undergo the last decade of development and training. What are some other well known mantras? The null reference is a billion dollar mistake? Minimise mutability? Maybe the language designers and library writers could catch up too.
Nulls are an error in that no language feature solves them (though third-party tooling does), so far at least.
Earlier quoted context omitted.
I don't think Golang devs are waiting to switch to Java if only making a lot of threads was easier. Honestly, its way too early. Virtual Threads will need a a "killer app" (in this case a killer framework) to pull in devs.
The great thing about virtual threads is they're basically a drop in replacement for threads.
Earlier quoted context omitted.
Inheritance provides "is a" relationships between classes. At a time when people would spend months designing their software upfront, building big diagrams of classes, etc, this was not so bad. You'd have a very clean system design that maps directly to your class design. The problem is when things change. A simple example - you build a classification of all life and it is built upon the idea that everything "is a" p…
> This is not a fun situation to deal with and inheritance makes it a lot harder because the "is a" relationship is driving a ton of your logic. Judicious OOP design allows others to change behavior based upon needs that perhaps the original coder never thought of. I would not call most Java OOP design judicious. The control in Java is owned by the library writers and the language devs -- not the people using it.
Earlier quoted context omitted.
As someone writing code on Java since v1.0 and making tech strategy decisions on the C-level, I consider myself sane and experienced enough to say that Java is something that will do the job well and can be the primary choice for startups and new projects. Kotlin as a platform is not mature enough to deserve the same qualification.
The job of software engineers is to translate a business domain into software. Different languages are better or worse at modeling different domains of problems. I have seen the same problem solved in different languages take 2-3x the amount of work and have a large difference in ongoing maintenance costs. Java's reliance on traditional OO means that only a small subset of business domains naturally map to the langua…
You don't have to stick to OO constructs. Java has functional programming support and pattern matching.
> best represented as thousands of threads going off to do independent work and then unifying results
Java has had executor support for a long time now. And if you're talking about IO bound tasks, Java has virtual threads now.
> parse a raw binary stream that had a lot of unsigned ints
Java has `Integer.parseUnsignedInt()` and other similar operations.
Earlier quoted context omitted.
"Prefer composition over inheritance" is actually a well-known mantra and appears in, for example, the Design Patterns book from 1994, which is basically the OOP bible. And this is within the OOP bubble, you won't even find inheritance outside of it. https://en.wikipedia.org/wiki/Design_Patterns Don't take undergraduate OOP courses seriously.
> a well-known mantra which isn't an explanation, but just the same as the OOP mantra that was taught in undergraduate courses.