[Geminidog]

I just did the switch from 10 years of python to C++.

Low level programming is way harder with the C++ stack. I blame mostly the language rather then the level. C++ is just a pain in the ass. If you get a low level programming job that uses rust things might be better.

Basically at the higher level, when you hit an error it is (generally) much more trivial to solve... not so with C++. With C++ you can hit crashes and not know where it even came from, this is much more rare in higher level languages.

I know several people who vehemently hate C++ with a passion and if you're going into low level stuff, very likely you'll have to deal with C++.

[nicoburns]

> I blame mostly the language rather then the level. C++ is just a pain in the ass... With C++ you can hit crashes and not know where it even came from, this is much more rare in higher level languages.

Yep, it's definitely the language. You can do low-level programming with Rust and pretty much never have this problem (never say never, but it's certainly not a common issue).

[Geminidog]

Unfortunate that as of right now, most low level stuff is basically C++.

[microtherion]

> With C++ you can hit crashes and not know where it even came from

As somebody who writes more C++ than Python, I have pretty much the opposite perspective:

If I hit a reproducible crash in C++, I can drop into a debugger, and work out where it came from. If necessary, I can look at the disassembled code, because it's reasonably feasible to map assembly language to C++ constructs.

Python code generally doesn't crash that way, it's true (unless it interfaces with C modules). But when errors occur, I have to debug them on a Python level. Dropping down the stack is nearly hopeless because the Python interpreter is just too thick an abstraction layer between assembly language and the Python code.

And I find myself having similar problems with Swift, for all its elegance. The mapping into assembly language is just considerably more complex than in C++, so you lose a low level debugging tool.

[Geminidog]

>If I hit a reproducible crash in C++, I can drop into a debugger, and work out where it came from. If necessary, I can look at the disassembled code, because it's reasonably feasible to map assembly language to C++ constructs.

I currently write more C++ then python. I'm primarily a C++ programmer. This was not the case for most of my career it is now, so I have enough experience from both perspectives.

The python debugger can display the stack and you don't have to compile it in debug mode. The pycharm debugger is excellent, but even if you don't use that pdb libraries can drop the app itself straight into a debug console with one line of code...

   pdb.set_trace()

As for low level debugging of assembly, in general programmers on the web stack who work at a higher level of abstraction... demarcation is so solid that in my entire career I never had to even know what assembly language was to do my job. That's the point of an abstraction, if you find yourself digging into assembly that means it's a leaky abstraction. Which is basically what C++ is...

[microtherion]

> I currently write more C++ then python

You mention in the grandparent post that you "just" made that switch, so that's a relatively recent development?

> so I have enough experience from both perspectives

I don't mean to be snarky, but evidently you're not nearly as comfortable working in C++ as you are working in Python. Your interpretation of this is that you have gained sufficient experience with both languages to know that the problem is with the language and more experience won't help, but what makes you so confident about this?

> I never had to even know what assembly language was to do my job. That's the point of an abstraction, if you find yourself digging into assembly that means it's a leaky abstraction.

Yes, that's a perfectly valid view, and, in the larger context of this discussion (about whether a programmer should switch to low level programming), if you prefer your abstractions to be solid, you'll probably find yourself happier in higher level programming.

But where the high level programmer is concerned about leaky abstractions, the low level programmer is often concerned about intransparent abstractions — that in some languages, it's hard to develop a reliable intuition how much time and memory a particular line of code will take. That's an equally valid view, and if that's your primary perspective, you might be more comfortable in low level programming.

> [a leaky abstraction] is basically what C++ is...

It's possible to write perfectly sound code in C++, but admittedly, it's also possible to punch holes in abstractions, and that possibility is often exploited.

[Geminidog]

>I don't mean to be snarky, but evidently you're not nearly as comfortable working in C++ as you are working in Python. Your interpretation of this is that you have gained sufficient experience with both languages to know that the problem is with the language and more experience won't help, but what makes you so confident about this?

Give it a year of experience on the job with C++17 and 4 years of C++ at school with C++98. In school I mostly did programing under windows and the Visual Studio IDE, and now it's linux with cmake (another nightmare unique to C++).

This is versus 10 years of experience with python and JavaScript. I would say based off of this experience in general python is a better language in everyway if you discount implementation details. (Almost) Everyone would rather work with the current versions of (typed) python and C++ still only exists because of legacy code and performance critical applications like OS's and games.

That's not to deride C++, performance is very very important . However let's say by some black magic that python performance becomes on par with C++... You'd definitely see a huge paradigm shift in the industry. Huge Performance issues imo is the only thing keeping python from completely taking over.

>But where the high level programmer is concerned about leaky abstractions, the low level programmer is often concerned about intransparent abstractions — that in some languages, it's hard to develop a reliable intuition how much time and memory a particular line of code will take. That's an equally valid view, and if that's your primary perspective, you might be more comfortable in low level programming.

I'm finding that the former view is what most people in general share. It's like worrying about paint pigments vs. Brush strokes. In general most of the population are painters that worry about the brush strokes, but you still need specialists who make the pigments.

>It's possible to write perfectly sound code in C++, but admittedly, it's also possible to punch holes in abstractions, and that possibility is often exploited.

It's not about exploitation. The knowledge needed to write sound C++ code is quite enormous and when a mistake is made and code is unsound C++ makes it very hard to find out what you did to create that unsound code.