srer

I presume as a method of manually constructing backtrace, as the same error may occur in multiple places it's helpful to understand the context.

I too would label it a preference.

To get out of the error handling tedium in our platform I largely opt to panic instead whenever viable, which gives a nice trace for free. (I am but human, and the error handling particularly grates once you have gotten used to just typing `?`.)

It's not from a founder, but I like this paragraph from the preface of The Go Programming Language:

Go has enough of a type system to avoid most of the careless mistakes that plague programmers in dynamic languages, but it has a simpler type system than comparable typed languages. This approach can sometimes lead to isolated pockets of "untyped" programming within a broader framework of types, and Go programmers do not go to the lengths that C++ or Haskell programmers do to express safety properties as type-based proofs. But in practice Go gives programmers much of the safety and run-time performance benefits of a relatively strong type system without the burden of a complex one.

I happen to like this idea of gaining safety through the type system. Sometime's when Go's frustrating me I have to remember - it's that I'm be expecting and achieve something it just isn't intended for.

I would say yes.

And I would go a step further, I owe my career to the Free Software and Open Source movements.

It's not that I couldn't have made my way in a world of proprietary software, but that world of money, license restrictions, vendor lock in, black boxes and deferring control to some megacorp's product managers, neither appealed nor was very accessible.

I'm not a purist to the extent RMS is, but I consider the 4 freedoms the FSF promotes to be very important practical features. Most of the gripes I have at home and work with software ultimately pertain to missing one of those features.

It certainly does for me. It ties into this quote:

> Why not use the syntax F<T> like C++ and Java?

A great number of us are used to seeing <> rather than [] for generics.

It would seem limitations in Go's parser outrank a popular norm.

Spent about a decade on-call...It is an interesting and perhaps even worthwhile experience to do it for a little bit.

IMHO there are two angles to achieve higher reliability:

1. Build systems which go down less on their own (which is quite difficult)

2. Get good at fixing them fast when they go down (which is much easier)

A trivial example of 1 might be moving from no RAID to RAID1, an example of 2 might be getting on-call proficient at quickly responding to a dead disk and restoring from backups.

(But I did say 1. was hard, even in this simple example maybe you used hardware raid, and are finding out just how crappy HW raid can be ;)

Companies attempt both angle 1 & 2 to differing degrees. I worked a lot in 2, and it sucked. We were a proficient fire department in a city of straw houses and gas stoves.

Aside from the general suckage of on-call (24 hour days, many, many nights lost sleep), the work is by it's nature high risk, high urgency, high impact, high risk - but is rarely rewarded sufficiently in pay or promotion opportunities.

Having spent so much time on angle 2, I've decided it is largely shallow work, and to grow intellectually I needed harder more interesting problems, which meant trying angle 1.

Consequently now my title is SWE and I don't do out of hours on-call, and it is glorious. I do notice I see the world differently to my less scarred fellow SWE. It definitely changed how I write software, and view the product priorities.

At heart I still consider myself an SRE. It's just I had to place myself in the most impactful place to achieve it, as a regular product/feature dev.

I work as a programmer. I'm not very good. But then hardly anyone is.

There are certainly exceptions, but I think as a whole we're still working everything out. And that's why it's so fast moving, we can easily find better ways of working each decade because last decade's status quo left so much to be desired.

If you find avoiding unemployment as a programmer easy, then I would suggest that you are what people want. Maybe you don't write the fastest code, maybe there are bugs, but it seems our customers (employers) are quite happy with that, and perhaps don't want the tradeoffs that would come if we were to ever seriously attempt to produce a zero bug project.

(I speak to/of the vast majority of programmers, there are areas where one can not compromise on program correctness but they are rare.)

We largely had similar experiences, but formed different conclusions.

Like you, with Go I was up and running rather quickly. I didn't have to think very hard. It was easy because I didn't have to pick up new concepts, only new syntax.

With Rust I had to learn some new concepts and internalize them, new concepts I generally find much harder than new syntax, but I believe I became a much better programmer (including when writing Go) as a consequence.

Now the journey is majority complete in both languages, and my conclusion isn't that Rust or Go made a pile of bad design choices, rather that the languages made different trade offs that appeal to different people in different circumstances.

Go pushes a lot of expectations of behavior during runtime onto the author while writing (don't share mutable state between threads without appropriate care, always remember to manually free your (not memory) resources, don't deref a null pointer, don't use a returned value if err != nil, etc).

Rust pushes a lot of expectations of knowledge onto the author while writing just to get the project to compile (ownership, lifetimes, sum types, address all the above mentioned Go expectations).

It's been years since I started using both languages, and I've spent months dealing with bugs in Go. I believe a lot of those bugs could have happened in any language, but also a lot wouldn't have made it past rustc.

Which is the winner for specific type of situation? I don't think we can know for a long time, studying such things is very difficult and takes a lot of time.

In the mean time, we gravitate towards our personal preferences, believing them to be superior for $reasons.

One supposes horrifically slow might be a bit subjective.

I notice in a VM on my laptop establishing the initial connection to postgres seems to take 2-3ms, and running a trivial query takes 300-1000us.

I routinely involve the database in unit tests, it is certainly slower but my primary concern is the correct behavior of production code which uses real databases.

There's a statement that Rust is a systems programming language, but that in most cases one doesn't need this, and that Go or Kotlin are thus in most cases better alternatives.

This image of Rust as lower level than Go isn't one I agree with, but I can certainly see how people end up there. Go has it's garbage collector and userspace threading model, one gives up a lot of control to a runtime that you don't have to in Rust.

But as the author mentions if we're after good enough speed these details aren't important. So I don't most of the time care if there's a GC or not.

What I care about is the code I have to write, and Rust IMHO offers me nicer abstractions and more features.

The Go world in their desire for simplicity, use a for loop for everything, but in Rust we have the excellent iterator trait. The Go world offers me product types, the Rust world offers product and sum types. The Go world offers some mechanisms for codegen, but it is a far cry from Rust's macros.

Go I consider a modernized C, that is notable more for what you can't do than what you can, and how fast it can be learned - owing to a minimal and already familiar feature set.

I confess that I have a bit of a chip on my shoulder, I have for the last few years been working as a Go developer and in the last few months it's started really started to grate me how much work things are. I really miss things like '#[derive(...)]'.

> ...edit your gnupg config file to exclude all the crypto from the 90s...

Personally, I would suggest leaving Rijndael (AES winner) in ;).

I use pass, and have no desire to move away from gpg.

I think gpg still provides "pretty good" privacy, I don't see any benefit that age would afford me with pass.

(There are sore points to the OpenPGP user experience, integration with mail clients among others, along with the WoT, have in practice been not great. But these are not things you would encounter with pass.)

I had wonderful teachers, I've spent countless hours with K&R, Friedman, Abelson & Sussman and many others.

Of course it was a distinctly one way street of communication, but fortunately my questions could almost always be answered by a closer examination of the previous pages.

In no way comparable in sophistication, but I did find making an n-body simulation to be unexpectedly profound.

My universe started as a uniform random distribution of small stationary objects, the only rules that existed were gravity (F=gm1m2/r^2) and inertia (F=ma).

Mass started clumping together, orbiting each other, eventually forming a relatively stable arrangement of what we recognize as stars orbited by planets orbited by moons.

With two simple rules to govern my universe, an emergent order had occurred that mirrored my reality.

A large concern in civil design loads is rain, wind and earthquakes.

These are all probabilistic in nature, you do not generally seek to build something to be flood proof. You instead design it to survive perhaps a 1 in 100 year flood, or perhaps 1 in 1000 if it's important.

There is a trade-off being constantly made, between the price of a project and the (estimated - of course) chance of it still being standing in a year.

I can't speak for your computing experience, but for mine:

There are significant differences in performance, admittedly SSDs temper these differences but there are plenty of systems with large HDDs. This isn't an abstract performance benchmark thing, I feel it when doing operations on large numbers of small files.

There are significant differences in features that impact how you use the system. For instance, sometimes I like to backup a directory I'm working in (typically before some funky git operation), normally that can be done with cp or tar, but that's slow. Much faster is a manual filesystem(/volume manager) snapshot. But I have to remember to do that. Much more convenient would be if I didn't have to explicitly create a snapshot, which HAMMER would offer me.

All non-temporary HAMMER filesystems in DragonFly by default automatically maintain 60 days worth of 1-day snapshots and 1-day worth of fine-grained (30-second) snapshots. - https://www.dragonflybsd.org/features/#index3h2

We could build such libraries, and people have built some.

However the task at it's heart is a vast duplication of work, and while Go has a lot of things going for it, it doesn't seem enough to sway many data scientists into reinventing their wheels in Go.

I don't blame them. Rewrites being difficult to justify or motivate when you already have a compelling implementation is part of the reason why we have significant amounts of FORTRAN77 code still kicking around today. It is also why for many things we opt to just write wrappers around existing C libraries to call them from other languages.

It has many shortcomings, but overall I prefer the sharing of a library across languages, each with it's own bindings that can attempt to make it more idiomatic to that specific language. The Go culture/community doesn't favor this approach, the Python community embraces it.

Years ago (linux-kernel 2.6 days) I found Red Hat was somewhat at odds with FSF values.

Red Hat does abide by the letter by the GPL by releasing source as legally required, but in a form that's inconvenient to work with: https://lwn.net/Articles/430098/

Apparently you could access the individual patches through your Red Hat subscription, but the conditions of the subscription prohibited you from sharing them. https://lwn.net/Articles/430132/ (see pzb's comment).

Red Hat/IBM is (presumably) doing what they believe will lead to continued commercial success in our current environment, I'm OK with that. But I don't really consider their condemnation of the FSF as anything of note beyond the loss of a donation.

Wonderful news!

I recall https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-pr... happening at the same time as the FSF incident, which fortunately didn't pan out.

It felt to me that we were attempting to purge a man from his life work, for...What? I'm still not sure, a vague allegation of alienation of a hypothetical future user base.

I found the whole thing distasteful, and moved away from guix as a consequence. I do in earnest hope they rescind their statement - if nothing else the timing of it was terrible, like they were jumping on a bandwagon.