Location: New York
    Remote: OKAY (but still looking for competitive pay)
    Willing to relocate: No
    Technologies: Modern C++ (Open to Rust), high-performance systems, distributed systems, Python, Shell script
    Email: dzd0qttdh@mozmail.com

-- Senior engineer (Entry level +2) with 5 YOE. Extensive experience in performance engineering and optimization. Hands-on experience on HFT. Please only contact me if your are/represent an employer. No headhunter please

    Location: New York
    Remote: OKAY (but still looking for competitive pay)
    Willing to relocate: No
    Technologies: Modern C++ (Open to Rust), high-performance systems, distributed systems, Python, Shell script
    Email: dzd0qttdh@mozmail.com

--

Senior engineer (Entry level +2) with 5 YOE. Extensive experience in performance engineering and optimization. Hands-on experience on HFT. Please only contact me if your are/represent an employer. No headhunter please

    Location: New York
    Remote: OKAY (but still looking for competitive pay)
    Willing to relocate: No
    Technologies: Modern C++ (Open to Rust), high-performance systems, distributed systems, Python, Shell script
    Email: dzd0qttdh@mozmail.com

-- Senior engineer (Entry level +2) with 5 YOE. Extensive experience in performance engineering and optimization. Hands-on experience on HFT.

Please only contact me if your are/represent an employer. No headhunter please

    Location: New York
    Remote: Yes (but still looking for competitive pay)
    Willing to relocate: No
    Technologies: Modern C++ (Open to Rust), high-performance systems, distributed systems, Python, Shell script
    Email: dzd0qttdh@mozmail.com

--

Senior engineer (Entry level +2) with 5 YOE. Extensive experience in performance engineering and optimization.

Please only contact me if your are/represent an employer. No headhunter please.

Interesting article. I investigated a few mentioned cases and here're my thoughts:

1. Pretty much all libgcc builtins (especially those manipulating integers/i128/bits) are known to be not super optimized and probably not well maintained to latest architecture. All places I worked use libdivide and other hand-rolled implementations rather than __addvti3

2. Many 32-bit inefficient compilations work correctly on amd64 platforms. Perhaps it's the lack of maintenance on 32-bit platforms?

3. When using two intrinsic in the same function, it's almost always slower than a hand-crafted snippet implementing the same semantic. Compilers aren't smart enough in this case.

It enables users to process string at compile time. You can implement a constexpr getRFC3339DateString(int year, int month, int day) -> string and then construct a constexpr string list.

But what can you do with that string list afterwards? You can't store it anywhere to be accessed at run time, can you?

The important part is that all the intermediate strings used during the computation are constexpr, to guarantee that the work happens during compilation.

Also, constexpr symbols can be demoted to regular const as needed by the compiler if necessary, such as when getting a pointer to one. constexpr doesn't mean "compile-time only", it means "compile-time compatible"

Right - you can use the std::string at compile time but since it allocates dynamically you need to copy to a fixed size char[]/std::array to use at runtime.

Congrats on the release. May I ask if the company is still hiring C++ engineer? I work full time in system programming, and the job post says 'post something you built with bun along with resume' which really confused me as I don't typically build things ON Bun.

Glad to see this. I don't want GNU to be rebranded into a mediocre open source project from radical free software symbols, and only someone who bites his fingers after scratching toes like Tux has the least possibility to appease corporations with those sugar-coated pills named "open source".

To be honest I don't know what attitude should I hold towards this news. On the one hand Richard's initial words didn't sound proper in that context, on the other hand as mentioned in the report this is a dangerous precedence that is against my belief of absolute freedom, which also reminds me of those protests against Linus Torvalds.

The whole thing only makes me recall good 'n' old 80s when everything is simple.

Friend, the only reason things seemed simple in the 80s is because the people on the receiving end of the "absolute freedom" stick, regardless of whether or not the people swinging it were aware of their swings, didn't have means to be heard by hundreds of thousands of people easily.

For computing specifically, you can add in that you basically had to be an economically privileged person who was likely on the spectrum to get really into it -- in an era where ASD and related disorders were not as well understood or diagnosed. You can also add it just being a smaller community.

Both RMS and linus had years and years of people expressing that they were acting in a problematic ways. Linus owned up to it eventually, even though there are arguments to be made for the utility of brashness.

RMS is mostly getting stuck in hyperfocused linguistic semantics, and probably doesn't really get how to not do that. Whether or not people making such a screech about this particular instance is appropriate is it's own question, but to me it is very much a "throwing up of hands" for a lot of people involved with the FSF.

Yeah the Internet changed everything. I just hope Linus could stick to his style without being stuck in these things, but if that really becomes the case I would seriously consider retiring from my job on kernel.

I am, no lie, quite concerned about the future of linux without someone really willing to be very stern (even cuss up a storm sometimes) about issues like pushing patches that break userspace or just quite bad code in general once linus is gone.

I'm fine with people telling him to stop being super harsh on the semi-reg, but there are actually gates that need kept in kernelland and one of the jobs of a gatekeeper is to tell people "no", sternly sometimes, and with explanation sometimes.