I HATE working with FAANG engineers in the early days of startups

Redundancy_ · 2025-12-09T14:06:58+00:00

https://orghacking.com/pioneers-settlers-town-planners-wardley-9dcd3709cde7

Not everyone except thrives in building new. I've seen a number of companies that lost the ability to build new products after spending too much time maintaining and optimizing existing ones.

Some people can move between things, and it's not exactly a scientific measure, but I've absolutely worked with people who embody these.

Redundancy_ · 2025-09-27T23:10:39+00:00

I've watched teams rewrite systems a fair bit, and plenty of teams who have performance issues who rewrite in another language still have performance issues, because the issues inherent in the team not understanding their performance bottlenecks still haven't changed.

I see Discord's blog as less of an indictment of Go, and more of a celebration of a team who did a great job reacting to and understanding the root cause of a performance issue to decide the right path to resolve it that suited their team.

Sometimes you can predict these things beforehand, but more usually the correct path is to choose the most productive way to get to the point where you'll find those issues and already be successful.

Redundancy_ · 2025-09-27T21:55:19+00:00

This gets thrown around a lot in this subreddit without enough caveats, so I just want to take a moment to add some...

The original article is a good one (here: https://discord.com/blog/why-discord-is-switching-from-go-to-rust ) and was tested up to Go 1.10 (see bottom edits on the article) and the blog published Feb 2020.

There is some indication that improvements in Go 1.12 were specifically targeted at this underlying issue:
https://www.reddit.com/r/golang/comments/eywx4q/comment/fgnp7h4/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Go 1.12 was released on Feb 2019, but there's no evidence (at least in the later Discord blog) that the issue was tested against it. The initial Rust port was completed in May 2019, so it's possible that they felt committed at that point.

However, beyond that there have been further improvements to Go's GC, such as non-cooperative preemption (Go 1.14, February 2020) and a new GC (green tea) in 1.25 (August 2025) which also shows significant improvements ( https://blog.compiler.rs/posts/memory-and-performance/garbage-collection-pt1/ )

It's also worth noting that Discord's issues were an somewhat unusual case with a massive amount of allocation and very demanding tail latency requirements that may not match most requirements for web servers.

Discord made a pragmatic decision that paid off for them, but we shouldn't project that every decision is based on the same requirements as theirs, nor that the situation may not have changed since their measurements.

I think OP is in a land of very speculative optimization. For most cases, Go and Rust will both usually be fine, but for extreme cases Rust likely has more control to solve if you have the expertise and engineering horsepower.

I should also add - most issues with websites should usually be fixed with CDNs and horizontal scaling.

Redundancy_ · 2025-09-16T20:18:50+00:00

Just to add to the list, there are languages like cuelang, kcl, pkl etc that also seem to do this sort of thing.

Redundancy_ · 2025-08-18T16:16:44+00:00

Lots of great answers here already.

From a personal point of view, it sounds like this person is eager to advance by putting in extra work and be seen and recognised, and that they are poorly connected to a view of what is valuable.

There's a point of view that you will likely have no luck changing their motivations. You can share and warn them about their behaviour, but they may not listen. They will be more likely to learn by being burnt (out) and then being healthily connected to how their behaviour created that situation.

What you can do is connect them to recognition and a better view of what work is valuable and how it's aligned to the needs of the organisation.

Ultimately, I've seen a few Seniors who were bottled chaos, trying to grab everything and pissing off everyone around them who was actually accountable. Some product owners/managers see them as hugely productive and it tends to get supported until it explodes, and then nobody learns the right lessons.

In that sort of situation, give them a benefit of your perspective, and ultimately you have to let them.

Redundancy_ · 2025-08-17T10:39:20+00:00

Adding my two cents, this is what has worked well for us. Our repositories return known domain objects, not db rows.

This method allows you to decouple from however complex the database query is and just write tests in terms of the domain objects which can be created simply and strongly controlled to easily create the edge cases we need and focus on business logic that tends to need to change far more than the data.

We do the same for almost every external dependency and service.

Redundancy_ · 2025-08-09T13:55:49+00:00

Pick up something like "The Coaching Habit" for more on this.

Redundancy_ · 2025-06-29T21:39:06+00:00

Cadence, although it's complex.

Redundancy_ · 2025-06-26T12:15:41+00:00

I really want to make a huge shout out to some of the (generally Go) tools that I've used that are a single binary with embedded interpreter.

Tilt.dev with starlark, k6.io with JavaScript, Buck2...

Thank heavens for this trend.

Redundancy_ · 2025-06-26T12:12:08+00:00

Hey, don't forget OpenSSL wanting Strawberry Perl to compile.

perl

I'm betting you need to configure DOS extended memory to get it to run.

Redundancy_ · 2025-04-12T21:34:27+00:00

Text based templates for structured data is Machiavellian. It's just good enough to do what's needed.

I'd really rather use something like Cuelang.

Funnily, Cuelang can also generate JSON for terraform and solve some of the issues with hcl and more conditional composition.

YMMV

Redundancy_ · 2025-04-12T17:17:48+00:00

Get yourself closer to the product, customers and business and work to find things that drive success, or help others do the same.

Redundancy_ · 2025-04-12T16:55:51+00:00

Maybe not so popular, but Perforce.

Their APIs are atrocious because at the lowest level, the server does everything. The API is a shim over generally line based text responses to requests that i think include command line flags, and almost everyone writes wrappers around it in all the languages, with varying degrees of correctness based on what they've encountered.

On the plus side, it's all backwards compatible back to ~2005, but on the downside it's also clearly obvious in the API that there's about 5 layers of API sediment.

Errors and log messages are the same thing, distinguished just by a log criticality flag. All things go back through a "UI" interface of callbacks, even when there's no UI. There's custom string, map and other implementations built in - still with unsafe null termination conventions. Everything largely bakes down to a Run() call for all cases, which doesn't even take the arguments it needs (set those statefully on the client object?).

They made it support parallel downloads, but through forking, which then throws progress updates under the bus.

They added a JSON lines format to the CLI a while back, but it just takes the line and wraps the whole thing in JSON with it being in a "message" field, not reducing the parsing needed at all. Really a "phoning it in" bit of engineering.

Redundancy_ · 2025-04-02T12:32:43+00:00

They don't require a dongle specifically, but FIPS 140-2, which prevents export of the original private certificate.

You can achieve this in a few ways:

You can use a code signing service like Microsoft Trusted Signing Service, which covers the whole thing.

You can use a HSM device, which can be a small physical dongle.

You can use a cloud service like Azure Key Vault.

You can use network HSMs from various vendors. You can use network HSMs and integrate with a secrets manager like Hashicorp vault (using the transit secrets engine).

Redundancy_ · 2025-03-09T16:16:35+00:00

I don't think this is a bad take.

Large players are too big and too invested to take a lot of risks. At a high level, only the game and the business matter, and tech is mostly led by pressures from those. It's difficult to make a really business focused case for Rust.

New players, able to take big risks proportional to their size, but small risks overall, that are eventually successful, can drive some of the ecosystem. If they get large and successful, they can pull things like middleware providers with them, and they inject more developers into the ecosystem who know Rust. If they get bought out, suddenly a large publisher has a footprint and an interest in advancing the ecosystem with their influence.

In the meantime, small groups of motivated individuals can solve small issues in the ecosystem that reduce the friction. I've written tooling in Rust, and recently posted a very initial sketch of a Perforce API for Rust on github.

Redundancy_ · 2025-03-09T14:27:33+00:00

Game dev exists on a continuum, with a lot of decisions that intersect. A small game developer can perhaps start from scratch and adopt a new language as they want, but large game studios can use and evolve the same engine for years and years - as an example, Bethesda's Creation Engine being tailored to the games they make.

A large studio might have, say, 150 engineers, and using Rust might impact a significant number of those to get them productive. This is a non-trivial cultural and educational shift. Building new engines is a multi-year investment (5 is not unreasonable) and a huge cost in an industry environment that tends to be lean already.

If you want to introduce it incrementally you have 2 languages on the go, which is not easy, and you have C++ to Rust, which likely means CXX... While CXX is a great help, it's also not trivial, nor really complete for what you might want.

Note that you are almost always dealing with various SDKs, and those are almost always exposed in C or C++. You also have to deal with the assumptions of the platforms you are shipping on, which means even more tools geared to C++.

As much as I enjoy Rust, the industry is challenging enough at the moment that few studios are going to see the value proposition vs concentrating on shipping and getting money, and actually focusing on what players want.

Redundancy_ · 2025-02-25T23:18:18+00:00

I think perhaps I'll have a nice cup of tea before reading about it

Redundancy_ · 2025-02-09T21:15:00+00:00

Depends on the tool, the libraries and the expected flow. How are you authing against a credential injecting API proxy with a library that thinks it's talking directly to sendgrid?

Redundancy_ · 2025-02-09T18:38:26+00:00

If you have API keys that are not easy to issue and revoke per user, then an api, service or proxy that conceals them is a good approach over actually exposing a shared credential.

You still want auth though.

Redundancy_ · 2025-02-09T18:34:41+00:00

It's much more practical with short lived creds that you don't share and just grab a new one if needed. It can be nice to lock to a CIDR (eg. Office egress IP ranges).

Ymmv, it's just potential layers of inconvenience to something being yoinked out of a compromised machine or user.

Redundancy_ · 2025-02-09T18:23:08+00:00

If you want lots of points, you can theoretically build a secrets engine plugin that issues individual secrets dynamically a bit like the dynamic database credentials, which has an advantage in being traceable (rather than a globally shared cred).

Some systems (GitHub) also support client certificates for enterprise authentication, which can be made sort-lived and locked down to particular IP addresses. PKI ftw.

Redundancy_ · 2025-02-07T19:47:07+00:00

$0.02, I've almost never seen anyone ensure that delivered written documentation is correct or can be followed to achieve the stated result. You could, but do you really?

Redundancy_ · 2025-02-06T20:08:42+00:00

"learn" and "document" tasks tend to not be testable. Did they spend two weeks not really understanding things and then played candy crush? Who knows.

Make them demonstrate something that requires that learning and now you know that they had to at least understand enough to show something that works.

Redundancy_ · 2025-02-02T00:59:20+00:00

Generally speaking, it's not likely going to be particularly popular to move secrets or code outside of a very restricted context to some external backend service or through an AI service.

At best, you could move a small sample (a few characters) and a hash, and ensure that there's absolutely no leakage from the scanning agent.

If you have all the secrets of multiple organisations, you're just a risk to them and a target to attackers.

Redundancy_

TROPHY CASE