gzapp

  Location: USA - San Antonio
  Remote: Yes | Hybrid
  Willing to relocate: No
  Technologies: Azure, AWS, Linux, TypeScript, NodeJS, Python, Ruby, C#, MySQL, Java, Groovy, Postgres, React, VueJS, Twilio, LLM
  Résumé/CV: https://www.linkedin.com/in/gregzapp/
  Email: [email protected]

Product engineer with extensive experience in cloud engineering, SRE, and full-stack product development including at Rackspace, Rundeck, and PagerDuty. Seeking high impact and ownership roles.

My most recent role was Principal Engineer at HungerRush where I led a number of major initiatives, including designing and implementing their next-generation conversational voice AI ordering platform (OrderAI).

That part about the threading was a huge source of issues back in the early days. Goroutines could hop threads and it's the threads namespace/cgroup configuration that gets inherited when forking..

One of the gnarliest issues I recall was where network namespaces could occasionally not be cleaned up correctly. So "randomly" (but more likely under certain loads) the networking of a reused thread would get jacked and Docker could no longer pull images.

Yeah, that definitely seems like the case.

The benefit of those enhancements being wrapped into the reference implementation is it's "easier" for humans and LLMs to reconcile and keep things in sync.

I'm going to do a taboo and comment on my own comment.

I didn't push performance in a way that would cause big deviations from the Golang project's algorithms and data structures; similar to how the TS team didn't want to deviate too far from the JavaScript source till now. Aggressive unmanaged arenas and object pooling was the direction I would have pursued..

The GC in DotNet is a source of major frustration for a tool like this. Without tuning lots of gen 0/1 work occurs to determine if objects should be promoted. The tuning is still not an ideal solution IMHO. Fully unmanaged arenas and aggressive object pooling could help here, but an alternative GC may be part of an ideal, comprehensive solution.. I have have a play with ZeroGC.

There is a warning on the repo that it's not maintained, but I've been curious about the process of updating it to sync "upstream" changes. And it sounds like the TypeScript team are going to start incorporating some of the performance techniques identified in the Rust port in the 7.1 release so... I'll probably at least sync it to up to 7.1 and keep it as an active experiment and case study on LLM porting and DotNet AOT performance.

It's just good fun.

Analogue hole is how I did a more efficient smart garage door hack than what people were talking about here at the time. Soldered zigbee switch into the physical button; worked great :D

The Rust port struck a cord with me. I had always been curious how a C# implementation would stack up against the Golang project in performance. And I was curious how cheaply the port could be done..

I know C# is a more direct port than Rust, but I'm still impressed how cleanly and cheaply it was possible to execute on.. And I learned some stuff :)

I'm doing this right now with Codex. It's currently working on porting the Binder.

7-11 phases to go and so far it looks like it might only cost $100. I'm focusing on efficient execution strategy minimizing token in/out, turns, and rework.

Will prob post up something interesting when it's done.

  Location: USA - San Antonio
  Remote: Yes | Hybrid
  Willing to relocate: No
  Technologies: Azure, AWS, Linux, TypeScript, NodeJS, Python, Ruby, C#, MySQL, Java, Groovy, Postgres, React, VueJS, Twilio, LLM
  Résumé/CV: https://www.linkedin.com/in/gregzapp/
  Email: [email protected]

Product engineer with 15 years of experience including Rackspace, Rundeck, and PagerDuty. As a full-stack, kitchen-sink product engineer I'm as comfortable running with unsafe pointers as working on React front ends. I'm seekign IC leadership roles with high impact and ownership.

My most recent role was Principal Engineer at HungerRush where I led a number of major initiatives, including designing and implementing their next-generation conversational voice AI ordering platform (OrderAI).

  Location: USA - San Antonio
  Remote: Yes | Hybrid
  Willing to relocate: No
  Technologies: Azure, AWS, Linux, TypeScript, NodeJS, Python, Ruby, C#, MySQL, Java, Groovy, Postgres, React, VueJS, etc.
  Résumé/CV: https://www.linkedin.com/in/gregzapp/
  Email: [email protected]

Seasoned software engineer with heavy startup experience and a focus on lean process, velocity, and business outcomes. 15yoe including Rackspace, Rundeck, and PagerDuty. As a full-stack, kitchen-sink product engineer I'm as comfortable running with unsafe pointers as working on React front ends. I look for high impact, ownership, and autonomy roles.

My most recent role was Principal Engineer at HungerRush where I delivered a number of high impact projects, including most recently their next-gen conversational voice AI ordering platform (OrderAI).

  Location: USA - San Antonio
  Remote: Yes | Hybrid
  Willing to relocate: No
  Technologies: Azure, AWS, Linux, TypeScript, NodeJS, Python, Ruby, C#, MySQL, Java, Groovy, Postgres, React, VueJS, etc.
  Résumé/CV: https://www.linkedin.com/in/gregzapp/
  Email: greg (dot) zapp (at) gmail

I'm a serial startup engineer with 15yoe including Rackspace, Rundeck, and PagerDuty. As a full-stack, kitchen-sink product engineer I'm as comfortable running with unsafe pointers as working on React front ends. I look for high impact, ownership, and autonomy roles.

My most recent role was Principal Engineer at HungerRush where I delivered a number of high impact projects, including most recently their next-gen conversational voice AI ordering platform (OrderAI).