srer

> But fundamentally no one should ever be trying to merge code that hasn’t been unit tested. If they are, that is a huge problem because it shows arrogance, ignorance, willingness to kick-the-can-down-the-road, etc.

Here you are asserting that unit testing is fundamental, and that not believing this is arrogance and ignorance.

I'd suggest your view that your way is "the" way, is an ironic display of arrogance, and perhaps ignorance.

And this perhaps I think is the core of much of the anti-TDD sentiment. It's not that we don't think TDD and unit tests are without their positives, it's that we don't like being told this is the one true way to write software, and if we don't do it your way we are engaging in poor engineering.

Consider it is not an unheard of experience to join the workforce, use a preconfigured macbook with precisely 1 SSD, and spend one's career building on SaaS platforms like AWS Lambda.

In such a world, perhaps those who remember there's a world of flexibility and power within the OS could be seen as welding some supernatural power.

> The language has memory-safe concurrency (except for maps, which is weird)...

My understanding is you should operate the other way around. Things aren't safe for concurrent mutation unless it's explicitly documented as safe.

> So you can have parallelism without worrying too much about race conditions or leaks.

You might not worry, but I find these the two easiest classes of Go bug to find when entering new codebases ;).

Still, I agree Go is easier to get a web service up and running with.

I work somewhere going through a similar process for much the same reason.

And to be frank, I'm wondering if how it ends is in me looking for a new job.

I know there's good reasons for the business to go through this process, and maybe it is really important for the business future but as an individual it sucks, my main motivator of achieving good outcomes for users, has been derailed by a large amount of procedure instigated under the belief that some auditor I've never met will be impressed.

Now with all this new procedure piled on, all of which is very new and thus immature and untried, I feel my energy to innovate, build new things and just generally drive change sapping away.

So the cost of your company isn't just the direct hours and the auditors fees! There's also a harder to quantify cost, as everything and everyone bends to change every team to work in the way some external entity thinks it should. This loss of autonomy and the loss of spirit is I think potentially far far more expensive than the direct costs.

Of course, maybe we're just going about the whole process poorly. I like to think if you were to do it well maybe it's not so bad. But, to do that I think you'd need abnormally talented staff involved, who are well versed in the topic, enthusiastic and empathetic. Most people involved in these sorts of processes in my experience aren't like that, and I can't say I blame them.

10 hours isn't too bad when dealing with a giant organization. Often problems cut across teams and services, and troubleshooting then liaising and ultimately getting a remediation action through (which might involve producing, testing and releasing a patch) all takes up time. Sometimes things blow out to weeks!

Personally, my last AWS Support ticket was pertaining to Lambdas and I got a very good answer. I was impressed.

It's important I think to appreciate working in support is difficult work, every single day is a customer with their own urgent problem. When urgency is the norm, it's not urgent. And heart? It can be soul sucking work.

In my observation support takes the brunt of the rest of the orgs shortcomings, bad releases, deprecated features, etc, drive customers towards you in unfortunate circumstances. Sometimes there's a whole waterfall of shit raining down on you, and it ain't your fault, and there's nothing you can do or could have done.

And to add insult to injury, you're normally at the bottom of the org pecking order.

As I say, difficult work. I salute all those who do it!

I do the opposite. Across C, Python and Go, I was prepared and had a good understanding of the languages and stdlibs before joining through reading books and working through the exercises.

It worked very well for me, on joining my knowledge of the languages and their stdlibs was respectable, and I could hit the ground running and get patches accepted easily. I could also in each languages case fix weirdness they had in their code because their own knowledge had gaps. That impressed people and made a pretty good first impression.

It's probably not universally true, but in my observation learning on the job much more commonly ends up resulting in sizable gaps in language knowledge.

If you've got a role working in $LANG, I don't see how upskilling in $LANG before you join is a trap. It's commonly knowledge with lasting value that offers returns across jobs.

I've never worked with C++, I hear hints that it's too big to actually learn and instead one must learn a subset. Maybe that's true, and the article more applies there.

Leetcode is programming.

It's not sprint planning, 1 on 1s, backlog grooming, jira tickets, slack support, gathering requirements, making estimates, negotiating features with management, responding to alerts, or the million other things you get sucked into as a nominal "software engineer".

But it's definitely programming.

It's a specific style of working, not entirely unlike TDD, with a specific theme of problems which aligns well with the content of undergraduate algorithms and data structures courses.

Is there a degree of pattern matching and rote memorization? Most certainly!

And does pattern matching and rote memorization play a significant part in real world programming? Definitely! If there's not as much memorization happening it's because the art of copy and pasting from stackoverflow supplants the need.

And presented with wishing to learn the content of a university course, what's one rather effective technique to achieve it? To do exercises, a lot of them, and when you're stuck look at how other people solved them.

That's all leetcode is.

Perhaps others think that undergrad course in algorithms and data structures is useless material but I do not. I think it makes you a better programmer.

As a general rule for dev work, trying to make evidence based decisions is fairly difficult. There's just not that much evidence around yet that can make it obvious as to if in your particular situation what the best choice might be.

And at the end of the day you have to contend with being in a work environment where politics and personalities rule, not science (or engineering).

That said I do wish more devs would take an interest in the available quality literature. Unfortunately I'm far more likely at work to run into an Uncle Bob recommendation at work, than a recommendation of ACM's Digital Library.

I largely agree with you, that rather than introducing Rust into your workplace it's easier to change workplaces.

I currently work in a Go shop. Why Go? Did it win some business value delivering contest? I don't think so, it's just the initial team lead liked Go the most of the languages they knew and made everyone else learn it.

If you read my comment history you'll see I think Go is a mediocre choice. But, it's here to stay in this company and it doesn't matter what new language comes along it won't have the inertia or acceptance of the status quo language. The expected improvement has to be large enough to overcome the associated costs to sell the business case.

This idea of the status quo being somewhat arbitrary, and difficult to change, applies to more than just languages. It applies to everything else, your architecture, your work processes, your culture. A blueprint is set early on by some founding members, and perpetuated potentially forever.

In this world, rather than trying to change a company you change employers. Innovation is change, and to achieve that the individual changes, but leaves their company to remain the same.

Personally, I seek to improve in what I do, to innovate. And I think what we do can be done better and that the tools and systems in-place play a part in that. But will I introduce them at my workplace?

Perhaps not, I think I'll find a new job, and both my old and next company can pay the rather high costs of someone leaving and someone joining. This makes me a little sad, since I like my company and leaving would be a significant amount of institutional knowledge walking out the door.

Lets see what the Go doc example looks like:

  sort.Slice(people, func(i, j int) bool { return people[i].Name < people[j].Name })

In Python one might write:

  people.sort(key=lambda person: person.name)

Or in Rust:

  people.sort_by_key(|person| person.name); // sort_by is also an option...

I think it's worth calling out exactly what is happening in the Go example:

- We create a closure that captures the people slice

- We pass the people slice and the closure to the Slice function

- The Slice function mutates the people slice, and because the closure captured the slice it sees these mutations too

I get why the Go team wrote sort.Slice like that, and it was perhaps the best they could have done with the language features...But I think we're going to have to agree to disagree on how wonderful it is compared to other languages ;).

Pretty simple for me:

I like working with Free and Open software much more than proprietary software. I think it's important for society, and I have more fun that way too!

Also the payoff for me has been very good, I can learn emacs once and enjoy using it for the rest of my life for all significant written language tasks on a computer.

Perhaps I could be a little more efficient if I were using a jetbrains IDE, but then I wouldn't like what I was doing as much. Enjoying what I do, even if it may look slightly contrived to others, is important in me achieving results at work.

Reminds me of discussions I had in the early 00's! People would say "Linux is cool and I'd like to try it, but Windows is where all the jobs are".

It's a fine point, and quite reasonable. It is however I think important that we don't all take your approach.

There are significant pockets of non-git users in the developer community ;)

I find hg much more pleasant to use than git, and can generally still work in git based teams while using hg.

I find pijul's approach much more interesting than git's, and look forward to pijul (and others :) pushing forward how we do revision control.

I don't believe git to be the end of the evolution of revision control systems (which for me has looked like cp -> rcs -> cvs -> svn -> git|hg), and find git lacking enough that I look forward to what the next generation does.

Would I argue that you personally should branch outside of your git centric world? Of course not! Just as I've worked with many devs who live their lives gainfully employed only knowing Java, or sys admins who only know Microsoft, it is up to you as to if you wish to explore different approaches and styles to achieve your end goal.

Largely complaints of Rust seem to boil down to the programmer needing to describe object lifetime information in code.

We can, as the original post did, show approaches that are overwhelmingly difficult in Rust because of this but trivial in Go. Alternative approaches, as this post shows, can be relatively straightforward.

In a similar vein, a Python programmer might complain about having to explicitly describe object type information in Go code. One supposes they could show approaches that are overwhelmingly difficult in Go, but trivial in Python.

Python, Go and Rust programs all do have types and object lifetimes. It is just that mistakes in type are not found until runtime in Python, and likewise mistakes in lifetime are not found until runtime in Python and Go.

Personally, after years of Python I came to value describing types in code, and after years of Go I came to value describing lifetimes in code too.