Hacker News Reader

Comment by eloff | Hacker News Reader

I've always thought of C++ as the most complex programming language I know. With each revision it becomes more complex. I gave up and just moved on to Rust a year and a half ago. I have no regrets.

C++ has not quite joined Perl, PHP, and Java as languages I will not work with anymore, but it's the next logical candidate.

View on HN

This is what annoys me when people say C/C++. C++ is a mess that no one could ever learn. C is a happy little language that lets you move memory around in anything from a micro-controller to a GPU cluster. C is not getting replaced by Rust because Rust can't fit in most of the places C lives. C++ on the other hand can't die fast enough.

Don't overestimate how big Rust needs to be, for a lot of specialist micro controllers the inertia is with C because the vendor ships a C SDK. But those SDKs are often garbage, which means if one or two enthusiasts make a good Rust SDK for your preferred controller suddenly Rust has the upper hand.

For really tiny stuff Rust won't go there. If you program an 8051 clone, Rust isn't interested in your problem, ideas like "generic programming" and "pattern matching" don't make a whole lot of sense when only 128 bytes of RAM is accessible. But is C really the right tool for that environment either ?

Once you've got 64kB of RAM, that's definitely potential Rust territory.

No idea why you decided to lump Java together with these abonimations.

Java by itself is an extremely simple language.

For me, one of the biggest problems with Java is its simplicity. Because of the lack of "power tools", you end up with things like dynamically assemble class instances using either XML or magic (see Spring), and adding functions at compile time (see Lombok). The last time I worked on a Java project, it was practically impossible to predict how the system would actually behave at run-time; my joke was that a lot of these tools took issues that could have been detected at compile-time and instead converted them into run-time errors.

I've worked just about every day with Java for the past 22 years, and you've hit the nail on the head with the problems.

I really prefer environments where you could start with main() and figure out the behavior from there, and things like Spring make that impossible.

Really, if java only had lambdas and lisp-y macros from the beginning, we wouldn't have these problems.

> I really prefer environments where you could start with main() and figure out the behavior from there

This is one property of Go that I really like. Because of lack of constructors/destructors/magic functions and all that jazz, the only functions executed in a Go program are functions explicitly called through main().

Watch out for init() [1]. Apart from that, however, I agree about the general lack of magic in Go.

[1] https://go.dev/ref/spec#Package_initialization

IMHO, in retrospect, runtime access to annotations was a mistake. Possibly the level of reflection it offers, too. These two make all that code possible that cannot be understood statically.

And yes, lambdas and macros would probably have been a good replacement for that those two were originally meant to achieve.

It made a ton of software possible that wouldn't even exist otherwise. We don't have runtime access to annotations in c++ and it's a constant PITA as soon as someone wants to make something as basic as generating a GUI automatically from a data model, which is maybe 50% of what programmers do all day in the world

I first wanted to write: Generating a GUI can happen as a fully automated build stepü, without runtime reflection.

But then I realized that such build steps re-introduce the same problems as runtime reflection does: You cannot understand the code statically.

So, yeah, maybe reflection and annotations are simply an overused hammer that makes everything look like nails... It feels like every library goes out of its way to use annotations for everything, completely defeating type-safety and static analysis. When it should actually be like, "is there really no way we can solve this without annotations and reflection".

Note that what I'm talking about is perfectly doable without any runtime reflection at all, only through static compile-time reflection. E.g. attributes in c++ are a purely compile-time thing - if there was an API to do stuff with them it would also be a compile-time one. The code isn't meaningfully different though.

But yeah, "fully automated build step" generally looks like "let's parse enough of the language so that we can implement our own custom reflection system" which leads to every project having an incompatible one and in practice much more pain (and macros) for the developers than if it was a standard one, e.g. Qt, Unreal Engine and so many others have their custom homegrown reflection scheme and there are a thousand libs on GitHub trying to reimplement it: https://github.com/topics/reflection?l=c%2B%2B

It's exactly like type systems being Turing complete : if yours isn't, someone somewhere will be making a language that compiles down to yours with one because of how useful of a property it can be in some cases. All of this is not accidental complexity, the alternative to not having them is much, much, much less productive in practice. My personal experience writing code with reflection is that at the cost of one complicated base library, the app code is literally 10x faster and simpler to write, and the huge majority of the time is spent in app code, not library one.

I am sorry to hear that you have experienced such a sorry bunch of code-bases and frameworks but that doesn't define the language or even an ecosystem.

I've seen worse magic crap happening with Ruby and Python with their auto-magic method invocations.

> but that doesn't define the language or even an ecosystem

I want to agree, but at least locally (as in geographically), these technologies seem to be heralded as fantastic. Maybe there's some kind of Spring Bubble around here, but on the main Maven site, Lombok shows up as the #16 most popular package (with primarily logging and language packages above it), and Spring isn't too far behind.

> Ruby and Python with their auto-magic method invocations

It's probably worth separating those two... as far as the functionality goes, Ruby and Python both have the capability of similar magic, but in my experience with popular frameworks, Ruby takes it to a whole other level while in Python it's generally discouraged.

I realize it's all anecdata here, but in my experience working with various companies and platforms, the Ruby magic generally just lives behind the scenes and Just Works. The Java magic would often turn into runtime exceptions, and the people who tried to do Ruby-like magic in Python would have similar difficulties. All of that revolved, primarily, around the ecosystems around the languages.

In theory Java is not so bad. I just have never enjoyed working with it or with the code Java developers end up creating. Kotlin is reasonably pleasant. I've sometimes used it when the JVM was a hard requirement.

Java is like one of those ice berg memes with a lot of byzantine JVM shit lurking at the depths.

I used C++ full-time for more than a decade before finally abandoning it in disgust.

Now I use Go for most purposes, and C or CUDA when appropriate.

Good riddance.

I've not worked with PHP for over 8 years now, but I hear it's gotten much better recently.

It still has issues that are commonly associated with hosting provider configuration/control over the runtime, apparently.

(sources are anecdotal; two friends who've had the mental fortitude to stick with the language for so long)

PHP 7 & 8 introduce lots of improvements. I used PHP 5 when I got into web dev and remember moving to Python as soon as I could. At work I've had to use PHP 7 and have been very pleasantly surprised at how solid it is. Now that I have more experience than my PHP 5 days, it's become apparent that PHP is very clearly suited for web work and the built-in functions offer many conveniences for such work that simply aren't available in other languages (granted other languages weren't built for web like PHP was). I've been surprised by my speed in PHP and I chalk most of that up to many helpful standard library functions. Even though PHP has a lot of old/compat functions still present I'm always surprised by how little that actually ends up effecting my productivity. So it's not my choice for greenfield projects but I'm not nearly as adverse to it now after working with modern day PHP for a bit.

Agreed - I've worked on a few PHP 5 era projects with hand-rolled frameworks and more recently I've worked on a few PHP 7/PHP 8 projects using proper frameworks and it's night and day.

Reply on news.ycombinator.com