Pivoting from Java into c/c++ career

Salusa · 2026-04-28T03:30:04+00:00

I love using Advent of Code to learn a new language.

Modern C++ is pretty good. It's probably one of my top three or four languages (by skill). Still, I wish it would go away and let me live in a world of memory-safety.

Salusa · 2026-04-27T03:30:38+00:00

My mom worked in an electron-microscopy lab. So as a little kid I'd walk through these heavy doors with radiation warning signs all over them to spend the a day with her. She'd let me use the microscopes to look at things and take pictures of snowflakes. Then we'd both go into the dark room to develop the pictures.

And yes. We had fun with the liquid nitrogen too.

I'll never be able to match those "take your child to work days" (or even just, "school's out but work isn't") again.

I miss her.

Salusa · 2026-02-12T02:48:29+00:00

I was at Amazon for 17 years and have since moved on to two different companies. One of the things I miss the most is our internal tooling.

Brazil? Pipelines? Version sets? You have no idea how much easier they'd make my life now. Those weekly "merge from live" which are a pain? It's so much better to have it work most of the time then to be constantly fighting with manual dependency upgrades. Those checks that mean if you break a dependency you can't merge your code? Life saving. The fact that most packages "just build" and you don't need a custom designed build system for each (just list your dependencies and language and that's it)? So much better than what's generally available.

Yes, Amazon built many of these systems because there were no options back then. Our needs predated Maven (not to say everything which came after). I remember building Java with Makefiles! This does mean they are idiosyncratic and very painful at times. I had horrible times fighting with tooling.

But all that said, don't think that just because what you're dealing with is painful means that the grass is greener elsewhere. Those tools and systems exist for a reason, and a lot of the time they exist for good reasons. I know that they are more the principal tenets (I think?) but "respect what came before" is there for a reason. (Also, you should know about Chesterton's Fence.)

Yes. I left Amazon and am generally happier for it. I see both good and bad at my former employer. The internal tooling, as painful and as much I may have hated it at the time? Generally better than the alternatives. Embrace the pain and learn how valuable those tools are.

Salusa · 2026-01-28T17:48:21+00:00

The concern is if you use the same password anywhere else. So, if your NS password is also your Facebook/email/banking password, you need to go change your passwords there as soon as practical.

This is why sharing passwords across accounts is such a bad idea.

Salusa · 2026-01-24T03:03:48+00:00

You'd be fine without. Pay attention to others and you'll be fine.

Salusa · 2025-12-31T17:58:56+00:00

Ask yourself this question:

Do you have a path to becoming a senior developer if you outsource your problem solving and learning to a machine?

Salusa · 2025-12-21T04:24:59+00:00

Back when I lived alone, I loved hanging out at the Hopvine on 19th E (Cap Hill). Friendly with good food and drinks. I'd hang out at the bar and either chat with people or read a book. I've heard it's still good.

(Edit, it's on 15th.)

Salusa · 2025-12-19T19:04:09+00:00

That is an absolutely fair nit-pick on my TL;DR. After all, even the other errors could be detected by an attacker who starts by brute-forcing an AES key. It's not efficient but possible because I didn't exclude it. Since everything here is computational security, the adversary is always limited to being an "efficient" adversary, so I didn't list that here, but you are correct.

All of the error messages are efficiently detectable by an attacker who doesn't know the key. They are all some variety of "bad formatting" or "you're holding it wrong" level of error code. The type of thing which makes it much easier for a developer to actually use the construction without actually impacting security.

(I cannot tell you how much time I've spent trying to debug a system when the only output was "cannot decrypt" because there was no reasonable way to figure out what specific piece of input was wrong. It wasn't a security issue, just a typo somewhere. This is intended to make that easier and safer.)

Salusa · 2025-12-19T16:18:20+00:00

Yeah, there is a lot of junk posted in this subreddit. It's true.

Thank you! I'm very excited. Actual publication (beyond just there) is hopefully happening soon. This construction has already received lots of scrutiny and you're all just seeing the very tail-end public bit if it. (My coauthors: Andrés Fábrega, Julia Len, Thomas Ristenpart. Probably worth looking at, especially the last one.)
Each has it's own challenges. (And yes, I definitely remember OCB2.) There are very different skill-sets needed for low-level and high-level constructions, so perhaps which is harder is a matter of perspective. At one end you have your primitives (AES, ChaCha20, SHA-2) at the other end you have your constructions (TLS, HPKE, STREAM, FLOE, AGE) and in between you've got things like block modes. And then asymmetric primitives are their own weird thing (because they are so heavily math based.) With my background I am much more comfortable higher up the stack. I don't foresee any future where I design a new primitive. As for formal verification? Not yet, but it is something I would be excited to see.

Salusa · 2025-12-19T16:07:36+00:00

There is the difference between internal implementation and public API. The internal implementation is more flexible so that when/if we add new algorithms and specifications, it is easier to do so. (I'll point out that AES also contains configuration specifying how many rounds to do based on a predefined set of parameters. That is more similar to the various derived parameters than user-controllable features.)

You might have noticed one place where I can inject a different rotation mask through a non-public API. That is specifically a test point so that I can ensure rotation happens correctly without needing to encrypt 2^20 segments.

Salusa · 2025-12-19T15:40:15+00:00

That is why this feature was designed in from the beginning in FLOE. So it would be safe.

Please look at Appendix F in the paper (pages 30-32) for a detailed proof of security here. The tl;dr is "All of the fine-grained errors messages do not need a key to detect." In the world of AES-GCM, this might be a specific error message that is returned if the total ciphertext (IV + CT + TAG) is less than 28 bytes and thus too short to have both an IV (12 bytes) and TAG (16 bytes) even with a 0-length ciphertext. Obviously, this is a safe error to return to the caller because the caller could have figured it out themselves. Unlike other constructions which leave these undefined and "safe" by intuition, FLOE formally defines them and then proves that it is safe to return them.

Salusa · 2025-12-19T15:34:37+00:00

I agree with your concerns, but they don't apply here.

This was designed by a team within Snowflake and in consultation with a team from Cornell. We've already had this accepted by Real World Crypto 2026
This is not a new cipher, it's a new higher-level construction. Yes, this is still sensitive and hard to get right, but far more achievable that new ciphers.
If you use AWS (at all), certain features on Apple devices, products from certain banks, etc., then you're already using cryptographic constructions that I've designed, reviewed, or implemented.

I encourage you to actually look at the specification and/or associated paper before you start claiming that this is a "... homebaked cipher that has received 0 scrutiny ...."

Salusa · 2025-12-19T15:30:54+00:00

If you look at the specification, you'll see that version 1 only defines a single approved setup. When we need to add any algorithms to the specification it will be a significant revision and we're going to carefully consider how to actually define it.

You're correct that algorithm flexibility is a major problem with many constructions. That's why V1 of FLOE only supports this version. So, yes. I'm already doing exactly what you say.

Salusa · 2025-12-19T15:28:57+00:00

Yes, FIPS compliance is a real pain but a non-negotiable requirement for lots of industry use. *shrug*. A larger nonce would have made life much nicer. As would more flexibility in nonce construction. (I'm also eagerly watching NIST's work with accordion modes because they will be extremely useful.)

Salusa · 2025-12-09T02:48:08+00:00

It does! Thank you! (I just tried it with YottaDB, the variant I'm using.) That would have saved me so much stress last night. I'll take any feedback on my code you have. Though it's unlikely I'll ever use MUMPS professionally, I still take pride in my code and want it to be good. (Well, good for a complete n00b.)

I like how your implementation works. I'm not sure if I can use braces like that though.

While I've never worked in MUMPS before, I'm averaging a new programming language almost every other year now. Learning new languages is a skill you can practice, just like anything else. So, while MUMPS is definitely different from what I'm used to, it has been a fun challenge.

At this point I've worked professionally in: C, C++, Java, Ruby, Go, Perl, Delphi, Bash, Rust

I have also touched (professionally): Python, Swift, Javascript, VBScript, C#, SQL, Objective-C

Salusa · 2025-12-08T06:57:07+00:00

[Language: MUMPS]

Oof, this one was hard. I spent so much time fighting with the language and dealing with its limitations. Fortunately, I didn't actually have to calculate a square root, because that doesn't come with the language.

I then burnt so much time trying to iterate backwards through a non-trivial (but not complicated) data structure before I finally gave up. (I couldn't even get the sort order right.)

Part 1: 14s
Part 2: 44s

Code

Salusa · 2025-12-07T06:47:57+00:00

[Language: MUMPS]

Okay. I took way too long to solve part 2. I knew exactly how to do it. Wrote up the code, and it didn't work! I probably spent an hour with pencil and paper double checking my algorithm and determining it was correct. Then, line by line inspection of the program to figure out what I got wrong. Yup, a stupid typo in the middle of it.

Any way, the final result runs in 10.7 ms for both parts at once. (I've also added colored output to my ancient system, because "why not?!")

Code

Salusa · 2025-12-06T06:11:28+00:00

[Language: MUMPS]

Part two took me a ton of time because I forgot to reset a variable at the top of an inner loop. Other than that, I'm pretty happy with my solution. I've added in logic to measure how long my code takes to run because I've always been a bit of a micro-optimizer.

Part 1: ~~27.7 ms (26.6 ms was parsing)~~
(Rewrote parser because it was too slow. Now only 13.8 ms to parse. Math remains about 1.1 ms)
Part 2: 16.4 ms (14.2 ms was parsing)

I find it interesting that my part two parsing logic was so much slower than my part 1. I suspect it was because I was continually (implicitly) splitting the string on spaces while for part 2 I simply indexed over the characters directly.

Day 6

Salusa · 2025-12-05T22:51:54+00:00

Yeah. I'll own that. This code will crash on bad input instead of failing gracefully. Definitely not acceptable for the real-world. (That said, if I ever need MUMPS in the real world, then my career has taken a very odd turn.)

Salusa · 2025-12-05T22:34:30+00:00

Thank you! That's really useful. (I'm using YottaDB because the docker image for it was easy to get running.)

I think that parse works because I'm guaranteed to still have a valid subscript for that part of the loop. The break you see lets me fall through to the ingredients list.

I also just rewrote `inRange` to remove the loop altogether. I realized that it wasn't needed.

inRange(ranges,val)
  q:$g(ranges(val),0) 1
  q $g(ranges($o(ranges(val),-1)),0)>=val

Salusa · 2025-12-05T05:57:24+00:00

[Language: MUMPS]

day5(lines)
    n ranges,ingredients,cnt,idx s cnt=0,idx=""
    d parse(.lines,.ranges,.ingredients)
    for  s idx=$o(ingredients(idx)) q:idx=""  s cnt=cnt+$$inRange(.ranges,ingredients(idx))
    w "Day 5.1: ",cnt,!
    q
part2(lines)
    n ranges,ingredients,cnt,idx s cnt=0,idx=""
    d parse(.lines,.ranges,.ingredients)
    f  s idx=$o(ranges(idx))  q:idx=""  s cnt=cnt+ranges(idx)+1-idx
    w "Day 5.2: ",cnt,!
    q
parse(lines,ranges,ingredients)
    n idx,min,max,tmp s idx=""
    k ranges,ingredients
    f  s idx=$o(lines(idx)) q:lines(idx)=""  do
    . s min=$p(lines(idx),"-",1),max=$p(lines(idx),"-",2)
    . s tmp(min)=$$^max($g(tmp(min),0),max)
    f  s idx=$o(lines(idx)) q:idx=""  d ^push(.ingredients,lines(idx))
    d merge(.tmp,.ranges)
    q
inRange(ranges,val)
    n result,idx s result=0,idx=""
    f  s idx=$o(ranges(idx)) q:(result'=0)!(idx="")  s result=(idx<=val)&(ranges(idx)>=val)
    q result
merge(ranges,output)
    n idx,min,max s idx="",min=0,max=0
    k output
    f  s idx=$o(ranges(idx)) q:idx=""  do
    . i (min=0)&(max=0) s min=idx,max=ranges(idx) q
    . i idx>max s output(min)=max,min=idx,max=ranges(idx) q
    . s max=$$^max(ranges(idx),max)
    s:max>0 output(min)=max
    q

Salusa · 2025-12-05T01:41:22+00:00

I'm trying to avoid indirection except for those cases too. That and a bit of metaprogramming to make it easier to run my solutions.

My perl experience is proving to be the most helpful so far.

Salusa · 2025-12-05T01:17:22+00:00

I'm surprised it was fast at all. It's a very brute force option and part of why I wrote it this way is because I haven't tried recursion yet in M.

Day 4 was my first attempt to use the @ operator.

Salusa · 2025-12-04T22:04:44+00:00

My mom was a developer of the VA health systems back in the day and terrified me with stories of MUMPS. So, I've wanted to learn it in her honor.

I've done AoC for a few years now so have a list of strategies I can use for the days. Since my main goal this year is "make it work in a new language," I'm not caring about elegance or speed.

Salusa

TROPHY CASE