This, however, is about diagnostics, i. e. annotating delete with a reason (message) to express developer intent when deleting a function, not about memory management.

Side note: please don’t abuse the word “toxic” until it becomes absolutely meaningless. Let’s keep that to a more fitting context, having a

I was expressing an obviously personal opinion about the language itself, which is objectively a dull, barren wasteland that sucks out your soul while you walk it. That is precisely the reason why it’s so widespread and loved by business entities and managers - there is no excitement, no surprises, just an everlasting monotony of keys clicking produced by a horde of clones wearing button-down shirts while sitting in absolute identical cubicles, creating yet another instance of FactoryProducer. It’s very easy to plan and schedule for, while at the same time being unnecessarily verbose and mildly unproductive (compared to other languages).

Look, the JVM is fine, just pick another language. There is plenty of work doing Kotlin. But yes, if you’re doing this only for the money, go ahead. I’ve always been unable to separate my job fromy personal life and my other interests, I couldn’t imagine being cursed by Java again.

If you can sit somewhere for 8 to 10 hours each day, doing something that isn’t fun and separate yourself from it, not going insane, all the power to you. I also get that not everyone has the luxury of picking their favorite toy and making it their job, but I firmly believe there are options that are not Java.

Now, if you’re one of the rare types that actually enjoys Java, meet me in the closest Denny’s parking lot, I need your cranial measurements.

Please note: this post contains hyperbole and humor. I don’t hate any of you, I just hate Java

My personal recommendation:

• Pick up Python, it’s easy to learn and highly productive. If you also learn fastAPI, you can benefit from highly validated, declarative models to build REST APIs in the backend, well fast. It will yield quick results, you won’t become demotivated and you can pick up a paid project soon.

• Pick up Rust. It’s “in” right now and I get requests from marketing people that know nothing about programming, asking if their project could be implemented in Rust

• Go with memorizing the shell commands first, try to understand git later. Get productive, try to get where you were with e. g. svn or cvs. If you are comfortable, look at something in depth if you have a problem that you can’t solve with the knowledge you have.

• Fuck Java, seriously.

• You have commercial interests, so it is probably wise to look into becoming a fullstack dev to maximize the kind of projects you can do. Look into React, vue.js, svelte. React is probably still the most widely used framework, you’ll quickly do a project with vue.js and svelte is a super interesting look into things to come.

With type annotations, this problem is mostly alleviated in practice, while still keeping the productivity gains of duck typing.

Based on this comment*, I’ll migrate a large project to bazel now. I’ll report how it goes.

• disclaimer: the comment just pushed me over the edge

This comment would be much better if it featured an explanation of your concerns with that particular opt setting.

It’s actually a lot worse than ASM, there are far more ambiguities in C++. And yet here I am, still developing with it some 30+ years later.

Don’t worry, I’m using Rust were it makes sense.

I am aware of what you are saying, however, I do not agree with your conclusions. Just for the sake of providing context for our discussion, I wrote plenty of code in statically typed languages, starting in a professional capacity some 33 years ago when switching from pure TASM to AT&T C++ 2, so there is no need to convince me of the benefits :)

That being said, I think we’re talking about different use cases here. When I’m talking configuration, I’m talking runtime settings provided by a customer, or service tech in the field - that hardly maps to a compiler error as you mentioned. It’s also better (more flexible / higher abstraction) than simply checking a JSON schema, and I’m personally encountering multiple new, custom JSON documents every week where it has proven to be a real timesaver.

I also do not believe that all data validation can be boiled down to simple type checking - libraries like pydantic handle complex validation cases with interdependencies between attributes, initialization order, and fields that need to be checked by a finite automaton, regex or even custom code. Sure, you can graft that on after the fact, but what the library does is provide a standardized way of handling these cases with (IMHO) minimal clutter. I know you basically made that point, but the example you gave is oversimplified - at least in what I do, I rarely encounter data that can be properly validated by simple type checking. If business logic and domain knowledge has to be part of the validation, I can save a ton of boilerplate code by writing my validations using pydantic.

Type annotations are a completely orthogonal case and I’ll be the first to admit that Python’s type situation is not ideal.

I’m not talking about type checking, I’m talking about data validation using pydantic. I just consider mypy / pyright etc. another linting step, that’s not even remotely interesting.

In an environment where a lot of data is being exchanged by various sources, it really has become quite valuable. Give it a try if you haven’t.

I wholeheartedly agree. The ability to describe (in code) and validate all data, from config files to each and every message being exchanged is invaluable.

I’m actively looking for alternatives in other languages now.

Is anyone in this reality content to be alive? Happy even?

I also currently use it for a new project since all needed 3rd party libraries are from a very specific domain and the project has a deadline, so writing and testing wrappers for Rust that would provide me with any meaningful advantages down the road are too costly to budget for before the deadline.

That could become part of a future refactoring, though.

I started working with CUDA at version 3 (so maybe around 2010?) and it was definitely more than rough around the edges at that time. Nah, honestly, it was a nightmare - I discovered bugs and deviations from the documented behavior on a daily basis. That kept up for a few releases, although I’ll mention that NVIDIA was/is really motivated to push CUDA for general purpose computing and thus the support was top notch - still was in no way pleasant to work with.

That being said, our previous implementation was using OpenGL and did in fact produce computational results as a byproduct of rendering noise on a lab screen, so there’s that.