Combined with C23's auto (see vec_for) you can technically backport the entirety of C++'s STL (of course with skeeto's limitation in his last paragraph in mind). gcc -std=c23. It is a _very_ useful feature for even the mundane, like resizable arrays:

  #include <stdlib.h>
  #include <stdio.h>
  
  #define vec(T) struct { T* val; int size; int cap; }
  
  #define vec_push(self, x) {                                                 \
      if((self).size == (self).cap) {                                         \
          (self).cap = (self).cap == 0 ? 1 : 2 * (self).cap;                  \
          (self).val = realloc((self).val, sizeof(*(self).val) * (self).cap); \
      }                                                                       \
      (self).val[(self).size++] = x;                                          \
  }
  
  #define vec_for(self, at, ...)             \
      for(int i = 0; i < (self).size; i++) { \
          auto at = &(self).val[i];          \
          __VA_ARGS__                        \
      }
  
  typedef vec(char) string;
  
  void string_push(string* self, char* chars)
  {
      if(self->size > 0)
      {
          self->size -= 1;
      }
      while(*chars)
      {
          vec_push(*self, *chars++);
      }
      vec_push(*self, '\0');
  }
  
  int main()
  {
      vec(int) a = {};
      vec_push(a, 1);
      vec_push(a, 2);
      vec_push(a, 3);
      vec_for(a, at, {
          printf("%d\n", *at);
      });
      vec(double) b = {};
      vec_push(b, 1.0);
      vec_push(b, 2.0);
      vec_push(b, 3.0);
      vec_for(b, at, {
          printf("%f\n", *at);
      });
      string c = {};
      string_push(&c, "this is a test");
      string_push(&c, " ");
      string_push(&c, "for c23");
      printf("%s\n", c.val);
  }

What I don't quite get is why they didn't go all the way in and basically enabled full fledged structural typing for anonymous structs.

That way my plan, but the committee had concerns about type safety.

This would probably need some special rules around stuff like:

   typedef struct { ... } foo_t;
   typedef struct { ... } bar_t;
   foo_t foo = (bar_t){ ... };

i.e. these are meant to be named types and thus should remain nominal even though it's technically a typedef. And ditto for similarly defined pointer types etc. But this is a pattern regular enough that it can just be special-cased while still allowing proper structural typing for cases where that's obviously what is intended (i.e. basically everywhere else).

I agree, that is also the solution I suggested. I will try to bring this back for C2y.

I’d triple the estimates, really. For example a game boy emulator is not trivial; there are far too many edge cases with a zilog. Chip8 would better fit for that time frame.

Being in Vancouver everyone's made the "It was filmed on East Hastings" line

Fortunately we still have the YouTube urls. A quick google has for me led me to Reddit / older forums to find the context I needed to search for a re-upload

In all honesty I’d try and model a 2d 3-link arm in software with forward and inverse kinematics. Then I’d model the inertia of the bars, and model DC motors to apply a torque to the bar interconnects. I’d then model PID controllers for each motor to smoothly move the arm. I’d then move to 3D. Once the physics is modelled you’ll find speccing the motors, solidworks, motor drivers, and MCUs relatively straightforward if you have some basics in electronics.

The fundamentals of robotics is in the math; think control theory. Don’t over emphasize the surface level like ROS, arduinos, and Lego kits. Those are implementation details

Snoozefest for anyone looking to get hands-on. Arduino kits can be had for $50 and then 50 lines of c++ will have basic forward kinematics on a ~10 inch arm you can play with in the real world.

Really? I’d have thought 50 lines of arduino would’ve been a snooze fest for hackernews

The only real answer. AI is the current scapegoat for any self-inflicted short sightedness, like the 0% interest rate over-hiring times of 2020-2021. Why blame yourself as a company when you can blame the loudest current news and market hype wave?

And not just blame but make your stock price go up saying you'll replace all your developers (even though that won't happen for another 20 years, if ever).

The engine is the fun part. Assets and game design are near impossible as a solo dev

I somewhat agree. Good game design requires a great idea, but more than that a lot of iteration. If you are working solo you need to hold the implementation and design in your head, which is incredibly difficult. Iteration is slow. You need someone to bounce ideas off of.

The best indie combo is a programmer plus a designer/artist in my opinion.

Alternatively, you can spend a very long time iterating solo. Most don’t have the runway for this.

This is also why big studios produce technically impressive games with mechanics seen thousands of times before. The production risk is much lower for “make spectacular assets” than for “come up with a novel game mechanic”.

Impossible but necessary. It's the big difference between an engine programmer and an indie dev. The latter needs to wear multiple hats to get something out while the former can specialize and work within a team of other specialists.

I’ve seen similar, and the engineer not only had thousands of GitHub stars and forked projects, but they were an excellent team player, natural leader, and terrific developer. What I did see, even then, was sentiment similar to yours, coming from managerial levels above them. Where does the insecurity start, and where does it end?

There are multiple parts of the job.

Can you work with your team? Can you get management what they need to do their job effectively? Can you get what other teams need from you effectively? Can you do the technical work?

All of them are part of the job. If you're great at working with your team but management hates working with you, that means you're only doing part of the job.

(And sometimes, that's management's fault too, don't get me wrong!)

Funny enough, the runtime switch, for all practical reasons, is probably just as fast

Considering vibe coding is the current state of the art I don’t think you have anything to worry about