Rob Pike

I roo am trying to curate my RSS feed to be doom-scrolling free. These largely achieve that for me. You'll find a smattering of political posts in them, but that's an inevitable side effect of living in abnormal political times.

https://scrollprize.org/ - The Vesuvius Challenge: Using high intensity X-ray scans and computation to attempt to retrieve lost scrolls from Pompei; real uplifting Sci-Fi stuff! Possibly the most heartwarming thing I know of on the internet; snatching ancient knowledge from the flames of history! What could be more poetic?

https://www.science.org/blogs/pipeline - In the Pipeline: The blog of Derek Lowe (pharmaceutical chemist), (in)famous for articles like "Sand Won't Save You This Time" Always interesting, though a lot of the chemistry goes way way over my head. Some political stuff lately, unavoidably given the current secretary of health.

https://blog.dshr.org/ - David Rostenthal: Digital preservationist.

https://www.jeffgeerling.com - Jeff Geerling: Raspberry Pi, Arm, digital radio, and other nerdery. I enjoy his videos, but I love that he does a plaintext version (first?) that's not just a transcript.

https://commandcenter.blogspot.com/ - Rob Pike: Programming luminary (Go, UTF-8, Unix, etc.)

https://fasterthanli.me - Faster than Lime: Amos's blog leaning heavily towards Rust. I'm a beginner in Rust, but I love this guy's style of writing even when the stuff he's writing about is beyond my current skill level.

Anyway, those are my go-tos…

Higher level languages are based on lower level languages.
aka Have to manually do more things in lower level language to get the 'built-in' features of the higher level language.

C is a system/software engineering language, not a data science/"I don't do/use low level OS/HARDWARE stuff"/someone else needs to write the higher level stuff I want to use" language. So, using C as a scripting language, implies implimenting a scripting language in C first.
(vs. https://hackernoon.com/javascript-compilation-epoch-ebfb7b5bb664 )

C is basically assembler language macros.

Thre are many types of binary encodings.
Binary format consists of sequence of 0's & 1's, any order,
usualy arranged in groups of 8 0/1's.

Standards are used to define how a binary format encoding is interpreted/used/defined. UTF-8, UTF-16, UTF-32, ASCII, etc.

notes on https://hikari.noyu.me/blog/2022-04-01-javascript-is-a-safer-language-for-integer-programming-than-c.html

"... JavaScript has exactly one integer size supported by its integer operations: 32bits"
Umm... on a 64bit machine, wouldn't this rehash the x86/dos/windows 80's/90's 8/16/32 etc issues?
number is 64 bits & bigint goes beyond 64bits.
JavaScript can no longer safely represent integers.

Bit operations are implemented as a cast to an integral type followed by a cast back to a double representation. It is therefore not a good idea to use bit-level operations in Javascript.

C language is not the same a C math library!
Can check for NaN via…

> My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on.

That's by design. Rob Pike fostered that "we know best" opinionated style in the community from the very first Go announcements and tutorials. I encourage you to read the design documents if you haven't: they throw light on the majority of decisions behind the language.

It's not really for me, but I understand and generally respect where they're coming from.

----

> If you want to know how to handle some new layout situation, run gofmt; if the answer doesn't seem right, fix the program (or file a bug), don't work around it.

http://web.archive.org/web/20091113154825/http://golang.org/doc/effective_go.html

> If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X.

> More directly, the program gofmt is a pretty-printer whose purpose is to enforce layout rules; it replaces the usual compendium of do's and don'ts that allows interpretation.

> Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting

http://web.archive.org/web/20091114043443/http://golang.org/doc/go_faq.html

> Orthogonality makes it easier to understand what happens…

Most school Internet domain-blocks Wikipedia, libraries are not in walking distance for substantial amounts of people (and that's leaving out how library fees are prohibitive for low-income families), and entry-level smartphones are locked down to the point of making curiosity irrelevant.

When you look at who in this industry succeeds, you very rarely see people from low-income populations. There isn't substantial reason to believe that distribution of opportunity isn't the handicap for a significant amount of people.

YC: founded by the son of a nuclear physicist, and the son of one of the UNIX authors.

Microsoft: founded by the son of a lawyer whose firm is currently making a billion a year in revenue and was similarly doing great at the time.

Facebook: founded by the son of a shrink and a dentist operating in one of the richest areas of New York, rich enough to be sent to private school.

Apple: founded by the son of an engineer at Lockheed.

Amazon: founded by the son of an engineer at Exxon.

Netflix: founded by someone whose family was rich enough to extravagantly donate during the Great Depression.

Google: founded by son of someone with a PhD in Computer Science (one who had multiple thousand-dollar personal computers filling their house since said son was born at that), and the son of someone with a PhD in Computer Science and a researcher at NASA.

C: written by the son of someone...who worked at Bell Labs.

Rob Pike gave a great example once of how Computer…

Most of that could apply to Kotlin also (familiar from Java, etc). Go's relative lack of features seems more to do with their idiosyncratic programming philosophy [1]. The tone is a bit condescending, but they clearly consider it good enough for themselves and it's usually become their primary tool of choice when Go team members work on new projects.

Personally I can see some appeal of fewer features. When trying to solve some medium-sized problem in Go, I often end up working through in my head 5-10 ways to structure it with Go's existing features (and almost always one of them ends up being satisfactory). If I had a lot more features, I could work through 20+ ways, but what good would that do?

Of course, I'm looking forward to user-defined generics (although their absence hasn't been critical for me). I used them in C#, but I would run into limitations [2]. Although it's taken a long time to arrive, I'd prefer to work with the system that the Go team has designed (and now accepted). To me this doesn't make them look bad?

People complain about nullability etc, but I just don't spend a lot of time on those bugs...

Let's say I just don't understand other languages. What language should I use then? I need memory control (value types), reasonable perf, if GC < 2ms pauses, also cross platform. That seems to mostly leave Rust and C++... are the extra features really worth giving up GC over?

That isn't a rhetorical question by the way, that's how I ended up with…

I definitely agree with you that Go codebases has a high level of consistency. It's certainly one of the many good things Go offers and something I hope other languages look at to see if they can replicate.

But, that doesn't really have anything to do with it being a chore. We can just agree to disagree on that.

However, I think you misunderstood my point about errors (or maybe you're just working with very different types of systems). Empirically, looking at Java codebases, the C# team found that most errors weren't "handled" beyond an outer exception handler. Anecdotally, this has been my experience as well. I admit that this is a very 'web' point of view, where requests are isolated and most exceptional situations are best handled with logging + showing the user a friendly error message.

At this point, they should adopt the Elixir approach and consistently provide a ! alternative across the stdlib (Must* is inconsistently available and verbose). They thought Go would be used by C++ programmers, instead it's being used by Ruby programmers (1). The language paradigm doesn't fit how people are using it as well as it could.

I'm not sure what other languages you've been exposed to, but your last line is hard for me to believe. If you look at other languages, you'll find a lot of techniques aimed at quality and resilience that are nowhere in Go. Again, that doesn't make Go bad, but "resilient" ? Go has mutable, shared memory, nils, no thread isolation, no generics (so…