Obama thought the idea was intriguing and mentioned it multiple times to his advisors. It never went anywhere though.
Brain draining the rest of the world is one of the main reasons for America’s success. It is due to America being a nation of immigrants that we can do this.
Not sure its quality, but battling with postfix & dovecot's 20+ years of legacy cruft, I felt compelled many times to just throw them aside and build something like this on first principles - simple single binary mail server with modern protocol support, sans all the archaic UNIX-account timesharing-era sendmail bullshit that still lives on in the mainstays.
Going to have a look at this one, despite now having moderately deep postfix & dovecot knowledge.
Remote: preferably
Willing to relocate: no
Technologies: embedded development, C, Python, C++, embedded Linux, Buildroot, EV chargers, Network/socket programming, writing Unix daemons, a bit of web dev (react, typescript), MQTT, MODBUS, microcontroller/RTOS, desktop software, electronics.
Resume/CV: https://www.linkedin.com/in/juancarrano/ , PDF on request.
Email: juan@carrano.com.ar
10 years experience. Done very disparate things, but mostly focused on embedded and numeric-related software (image processing, robot path planning, electric power optimization). Quite heavy on Buildroot too. Right now I'm working with video and OpenGL as a side project while building a react-router site on cloudflare.
C++ has smart pointers. I personally haven't worked with them, but you can probably get very close to "safe C" by mostly working in C++ with smart pointers. Perhaps there is a way to annotate the code (with a .editorconfig) to warn/error when using a straight pointer, except within a #pragma?
> Just talk to the platform, almost all the platforms speak C. Nothing like Rust's PAL (platform-agnostic layer) is needed. 2) Just talk to other languages, C is the lingua franca
C# / .Net tried to do that. Unfortunately, the memory model needed to enable garbage collection makes it far too opinionated to work in cases where straight C shines. (IE, it's not practical to write a kernel in C# / .Net.) The memory model is also so opinionated about how garbage collection should work that C# in WASM can't use the proposed generalized garbage collector for WASM.
Vala is a language that's inspired by C#, but transpiles to C. It uses the gobject system under the hood. (I guess gobjects are used in some linux GUIs, but I have little experience with it.) Gobjects, and thus Vala, are also opinionated about how automatic memory management should work, (In this case, they use reference counting.), but from what I remember it might be easier to drop into C in a Vala project.
Objective C is a decent object-oriented language, and IMO, nicer than C++. It allows you to call C directly without needing to write bindings; and you can even write straight C functions mixed in with Objective C. But, like C# and Vala, Objective C's memory model is also opinionated about how memory management should work. You might even be able to mix Swift and Objective C, and merely use Objective C as a way to turn C code into objects.
---
The thing is, if you were to try to retrofit a "safe C" inside of C, you have to be opinionated about how memory management should work. The value of C is that it has no opinions about how your memory management should work; this allows C to interoperate with other languages that allow access to pointers.
ConfiguredThing Thing::configure(....) &&;
Where ConfiguredThing and Thing have the exact same members, so doing
auto y = std::move(x).configure(...);
would not copy any data around. It seemed to work with optimizations on, but then there are no guarantees that it will always be the case.
Ideally one would want RAII, but that is not always possible, in particular when wrapping C libraries that may have their own logic. Also, the object could be in different states, with different methods available in each state, and then it would be possible to prevent errors at compile time.
ConfiguredThing Thing::configure(....) &&;
Where ConfiguredThing and Thing have the exact same members, so doing
auto y = std::move(x).configure(...);
would not copy any data around. It seemed to work with optimizations on, but then there are no guarantees that it will always be the case.
Ideally one would want RAII, but that is not always possible, in particular when wrapping C libraries that may have their own logic. Also, the object could be in different states, with different methods available in each state, and then it would be possible to prevent errors at compile time.