As someone who just picked through the Zig docs (take this with a mountain of salt), Zig has a few things going for it:

• spec is simple and closer to C in scope
• modern language design, toolchain, and overall ergonomics
• Go-like struct & interface system
• 1st-class C interoperability

Go foists co-routines on you and the runtime, and Rust has the borrow checker. Both of these things deeply impact language design, standard libraries, and the overall developer experience. So Zig might actually be a “more modern C” in many ways which makes it a contender. That said, it’s not a 1:1 comparsion since it lacks everything else that C++ does: you’d have to re-envision your software designs as something other than OOP if that’s what you’re used to.

Because that’s what people outside of a simulation would do.

A huge chunk of the country is demoralized by all this. As trite as it sounds we absolutely need a pep rally, and some basic direction to go on. Right now there is a monstrous information and leadership vacuum, so anything would be preferable to that.

Not just Mars, but yes. Biodegradability isn’t even a factor since there’s no biosphere to speak of, which also raises philosophical questions like: “what is pollution, exactly?”

What will really bake your noodle is to imagine a future where we settle the Moon and Mars. Do old space program artifacts become monuments and parks (debris and all), or are they trash to be removed from the environment?

Now that you mention it, that’s probably why.

What I’m curious about is the “engineering model.”

All NASA missions have duplicate probes, satellites, rovers, here on earth. They’re essential for testing various scenarios like training astronauts (in the case of the Hubble repair missions), or testing the limits of the systems in question. I wonder if the engineering model for Curiosity has one of its wheels cut away in the same pattern, to simulate difficulties in navigation and traction?

without any real mental analysis or realization of the manipulation that’s going on.

I see it as zero introspection. That might also explain the projection, hate, and bigotry that run in those circles; it’s hard to keep that up once you see where it’s coming from. An inability to introspect is also an aspect (among many) of narcissistic personality disorder, and helps keep that pain-train rolling.

Too bad.

…

Hello there!

Java itself is kind of blissful in how restricted and straightforward it is.

Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language’s simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. “dependency injection”). This presents a big learning challenge to people encountering Java projects on the job: there’s a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.

People tend to conflate these two learning tasks (language vs practice), lumping it all together as “Java is complicated.”

$0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.

Some articles showing the knock-on effects of this phenomenon:

• https://stackoverflow.com/questions/11865307/how-to-expand-size-of-java-stack-trace-to-see-bottom-of-stack-triggering-a-sta
• https://www.reddit.com/r/java/comments/16g30jx/can_java_errors_stack_traces_be_longer/
• https://www.quora.com/Why-does-the-Java-Spring-Framework-produce-gigantic-unreadable-stack-traces
• https://community.splunk.com/t5/Splunk-Dev/What-are-the-best-extraction-methods-for-Java-Stacktrace-Errors/m-p/380397
• https://stackoverflow.com/questions/65436457/springboot-stack-trace-logging-filter-only-from-my-packages

Yes, but “Proto Indo-European” doesn’t exactly roll off the tongue. /s

Honestly, this is why I tell developers that work with/for me to build in logging, day one. Not only will you always have clarity in every environment, but you won’t run into cases where adding logging later makes races/deadlocks “go away mysteriously.” A lot of the time, attaching a debugger to stuff in production isn’t going to fly, so “printf debugging” like this is truly your best bet.

To do this right, look into logging modules/libraries that support filtering, lazy evaluation, contexts, and JSON output for perfect SEIM compatibility (enterprise stuff like Splunk or ELK).

Heisenbugs are the worst. My condolences for being tasked with diagnosing one.

Last time I did anything on the job with C++ was about 8 years ago. Here’s what I learned. It may still be relevant.

• C++14 was alright, but still wasn’t everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
• C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. “RAII” is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there’s no other way to enforce them or check for their absence.
• I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn’t exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode¹. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
• A team style guide is a hard must with C++. The language spec is so mindbogglingly huge that no two “C++ programmers” possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
• Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates, const, constexpr, inline, volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages.
• At some point you will need valgrind or at least a really good IDE that’s dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team’s ability to fix serious problems.
• C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
• Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go’s book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
• Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).

1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it’s just more data, after all.

Yeah, I know that the super-flat planar look was the intent, but there’s a reason why you don’t see much in the real world that resembles the cybertruck. It turns out that the non-planar features of typical car panels are there to add rigidity. Flat sheet metal wants to bend, twist, wave, and even flap in the wind. So there are probably internal supports or struts welded to the panel backsides, in order to keep them flat. Problem is, that process tries to distort the panels due to heat from manufacturing.

And since they opted for stainless, this adds additional problems. In this case: you can’t hide imperfections with bondo and paint. The panels have to be perfect, every time. It requires tolerances that belong on a sports car, not a pickup.

Oh no, I have to press up 200+ times if we’re counting all the detritus and failure in my command history.

There is an advantage to this approach though: fewer errors. You’re plucking a known working command from a list instead of manually typing a (possibly) broken version of it. Worse yet is when it’s a command where typematic mistakes cause unintended side effects like data loss. So, mashing up 100 times can be pretty smart, especially if you’re not a great typist.

Upvoted for the dancing and singing emoticon. Nice art.

This man is a menace and must be stopped.

Eh, I’m used to it.