_ek94

For those of us who don’t like exceptions I think the concern is more that the exception might not be caught right there, so an exception may potentially transfer control to an arbitrary point above the current function in the stack.

That’s exactly how rust generates backtraces though. They just are not typically attached to errors.

It’s good to know there is hope of landing another such gig :)

Those presentations to the higher levels didn’t really happen because the corporate structure was very flat. Also, I would not expect those to take up all that much time.

You may have worked at a lot of places, but your experience is still only a tiny slice of the different shops out there. My experience is likewise limited, and I acknowledge that such light touch management is probably very rare, but it can and does work.

You said she was a team lead not a real manager, which does have some truth to it, but it’s not like there was someone doing the “real” management work to pick up the slack for her. In the right environment that stuff simply isn’t needed.

As someone who has been managed both through traditional management techniques and a manager who mostly coded, I could not disagree more.

As long as we are throwing out anecdotes, I've been doing this for 3 years and have seen successfully done it on several teams, though they were all at the same company. It absolutely can be done with the right culture.

> If you're legitimately a people manager (not a low grade 'team lead'), there is no way, no how, you could have 80% free time.

Just because you've never seen this dynamic work successfully doesn't mean that it doesn't. The best manager I've ever had operated like this. She spent most of her time coding and made sure to know what everyone on the team was up to. We were all competent professionals, so we did a perfectly fine job of prioritizing our work and working with others within the team and across teams to get things done. It helped that much of our work could easily be undertaken in parallel with strong ownership of different parts of the code by a single person, but when there were projects that required strong and frequent collaboration she just carved out a sub-team and designated a lead then trusted the lead in the same way she trusted us as individuals. Not only did this mean that we got the benefit of her very impressive technical contributions, but it also meant that we were all able to be more productive because we spent vastly less time in BS meetings.

Afterwards, I moved to a company with a more traditional structure. Ostensibly there were three people in charge of me: my engineering manager, my product manager, and my designer (since we are "design lead"). It was a pretty big culture shock. One difference is that there are a lot more junior people in my new company (the average age was around 50 in the first one), and I think younger engineers may need a firmer hand, but I'm not sure that that explains it all. I joined the first place right out of college and thrived in that environment.

I think most people don't understand just how effective a minimal management strategy can be because they've never experienced one that works well.

They need more than a simple majority to convict in the senate trial, so it seems unlikely to be successful. The best they can hope for is to force republicans to vote in favor of the insurrection and hope that is still an unpopular choice in 2022.

As a diagnosed dyslexic, this website feels nothing like what reading is like for me. It might be representative of some dyslexic experience, but certainly not mine.

Interpreting GP's comment using the Principle of Charity[1], I assume GP meant "older than C++ is now".

[1]: https://en.wikipedia.org/wiki/Principle_of_charity

> Go's standard library provides a regex library that provides certain O() guarantees, but has a significantly larger constant factor than PCRE-like regexs.

While that is true, Rust's regex library makes the same guarantees.

I'd also like to push back on the idea that perf comparisons are meaningless if one implementation has degenerate cases. Pathological behavior in a backtracking engine happens very rarely, and backtrackers typically come with features that are not supplied by O(n) engines. Someone in the PCRE camp might complain that the benchmark isn't fair because go's engine can't handle backreferences. The different approaches come with different features (backreferences vs garenteed O(n) running time), but they do have a place where their problem domains overlap. It is not useless to examine how they perform in that area.

If that was your first foray into Rust land, I hope you give it another shot. I definitly struggled with fitting into the Rust programming model at first, but a few adjustments to how I code have really helped me. Some particular points which helped me are:

1. It really helped me to stop trying to force my code to be as pretty as possible the first time around.

2. If you are getting errors about a lifetime not living long enough in a complex expression, it can help to pull some part of it out into a helper let binding.

3. Adding an artificial scope (a curly block in the middle of another block) can be a great way to control the lifetime of a borrow.

4. clone() all the things! This is a major advantage that Rust has over other ball-and-chain languages like Haskell. When you get into a type-tetris situation in Haskell, you just have to find a way out. In Rust you can often just clone() something that you would rather not have to clone() and move on. I love being able to tell the borrow checker to go away while I concentrate on my program logic. Later I can always go back and fix it.

I think the go team does deserve credit for making compilation speed a priority when other languages of the same generation have tended not to.