professional-programming VS go

Professional Programming by Charles-Axel Dein

The inclusion of the perspective section: https://github.com/charlax/professional-programming?tab=read... I think is really smart. Same for personal productivity. Two things that can dramatically change how and what you end up studying and doing with your time / life.

I did a coding bootcamp and yeah the frontend knowledge they taught was useful, but I could have learned that online for free. Looking back, the far more valuable thing I learned was how to discipline myself and my time - that was the first time in my life I was truly disciplined and mindful in how I spent my time. I also got perspective I'd never seen before: there was some folks in my cohort that were in their 30s and 40s and undergoing career change, and I learned two things from them: First, don't stress too much, your life has much more flexibility than you might expect (this truth is borne out, they all have perfectly successful careers in their new lives as engineers), and second, make a great use of the time you have.

Bog-standard advice we all know, but to witness it firsthand from people living it and sharing it is different. The shared article in the github is incredible: https://www.theguardian.com/commentisfree/2020/sep/07/termin...

I often wonder why I don't see more of these sorts of articles. From watching a family member slowly die of cancer, and from reading books like "When Breath Becomes Air," I'm guessing it's some combination of exhaustion, disability, and a new set of priorities that doesn't really involve death blogging. Still, I find these kinds of writings more poignant than most things I read.

Also this repo helps https://github.com/charlax/professional-programming

1. Professional Programming

Professional Programming. As reported, The goal of this page is to make you a more proficient developer. If you have excellent resources, you can try to open a PR and include them here. But in any csae, I wanted to include this because it seems super interesting.

“The language is simple on purpose. If you want cleverness, write LISP.” Go issue tracker discussion

> To convert the Stream.Reader to an std.Io.Reader, we need to call its interface() method. To get a std.io.Writer from an Stream.Writer, we need the address of its &interface field. This doesn't seem particularly consistent.

That made me think of how that change would be received in Go (probably would be discarded). They way they approach changes in extremely deep analysis and taking as much time as it needs to avoid mistakes and reach a consistent solution (or as close as possible).

This has been my favorite for a while: https://github.com/golang/go/issues/45624

4 years to decide on something relatively minor, that right now can be done with a bit of a one-liner extra work. But things need to be well thoguth out. Inconsistencies are pointed out. Design concerns are raised. Actual code usage in the real world are taken into account... too slow for some people, but I think it's just as slow as it needs* to be. The final decision is shaping out to be very nice.

It is rare to encounter this in practice, and it does get picked up by the race detector. But the language designers chose not to address it, so I think it's a valid criticism. [1]

Once you know about it, though, it's easy to avoid. I do think, especially given that the CSP features of Go are downplayed nowadays, this should be addressed more prominently in the docs, with the more realistic solutions presented (atomics, mutexes).

I also think Go should add 128-bit atomic operations, which could cover strings and interfaces at least (unfortunately, slices are three words in size). It's on their radar at least [2] and there exists an external package [3].

[1]: https://research.swtch.com/gorace

[2]: https://github.com/golang/go/issues/61236

[3]: https://pkg.go.dev/github.com/CAFxX/atomic128

Sorry. Was at dinner. It's Russ Cox. Being hungry and in a hurry doesn't help with remembering names.

The GitHub discussion is there: https://github.com/golang/go/discussions/58409

but the words I of Russ I cited is here: https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p...

Copying verbatim:

It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence.

A few more links that I collected recently on the topic

https://github.com/golang/go/issues/73626

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

https://web.dev/articles/fetch-metadata

https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/

So now there is at least a workaround to preserve the order when processing JSON. Great!

[1] https://github.com/golang/go/issues/27179#issuecomment-22899...

Anonymous functions aren't the same as lambda functions. People in the Go community keep asking for lambda functions and never get them. There should be no need for func/fn and explicit return. Because the arrow would break stuff is one of the reasons.

See

https://github.com/golang/go/issues/59122

https://github.com/golang/go/issues/21498

I'd say it's fair to call this a footgun, though not a bug. The context is really only intended to apply to the goroutines. And Wait has to cancel the context to prevent a resource leak.

I suggest in general using function scoping to drive the lifetime of contexts, etc. This works also for defers and tracing spans in addition to the canonically shadowed `ctx` variable.

There is an old issue in the tracker proposing changes to alleviate this: https://github.com/golang/go/issues/34510. The original author (bcmills) of the errgroup package shared insight into the design choices/tradeoffs he made.

You can check the language out here!