The last paragraph captures the essence that all the PL theory arguments do not.
"Zig has a fun, subversive feel to it".
It gives you a better tool than C to apply your amazing human skills, freely, whereas both Rust and Go are fundamentally sceptical about you.
Self-aware people are mindful about what "future them" might do in various scenarios, and they plan ahead to tamp down their worse tendencies. I don't keep a raspberry cheesecake in my fridge, even though that would maximize a certain kind of freedom (the ability to eat cheesecake whenever I want). I much prefer the freedom that comes with not being tempted, as it leads to better outcomes on things I really care about.
In a sense, it is a powerful kind of freedom to choose a language that protects us from the statistically likely blunders. I prefer a higher-level kind of freedom -- one that provides peace of mind from various safety properties.
This comment is philosophical -- interpret and apply it as you see fit -- it is not intended be interpreted as saying my personal failure modes are the same as yours. (e.g. Maybe you don't mind null pointer exceptions in the grand scheme of things.)
Random anecdote: I still have a fond memory of a glorious realization in Haskell after a colleague told me "if you design your data types right, the program just falls into place".
> Random anecdote: I still have a fond memory of a glorious realization in Haskell after a colleague told me "if you design your data types right, the program just falls into place".
There's a similar quote from The Mythical Man Month [0, page 102]:
> Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they’ll be obvious.
And a somewhat related one from Linus [1]:
> I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
I would rather live in a world where I can put a raspberry cheesecake in my fridge occasionally. Because I know how to enjoy cheesecake without having to buy it every week. Not a world where when I pick the cheesecake off the shelf in the store someone says "Raspberry cheesecake! You may be one of these people who is lacking in self awareness so let me guide you. Did you know that it might be unsafe! Are you sure it's going to lead to a better outcome?"
A programming language forces a culture on everybody in the project - it's not just a personal decision like your example.
I think I see it slightly differently. Culture is complex: I would not generally use the word “force” to describe it; I would say culture influences and shapes. When I think of force I think of coercion such as law and punishment.
When looking at various programming languages, we see a combination of constraints, tradeoffs, surrounding cultures, and nudges.
For example in Rust, the unsafe capabilities are culturally discouraged unless needed. Syntax-wise it requires extra ceremony.
When it comes to our ability to write bug-free code, I feel like humans are not actually not that good at writing bug-free code. We just don't have any better way of producing software than that, and software is useful. This doesn't mean we're particularly good at it though, just that it's hard to motivate people to spend effort up front to avoid bugs when the cost of them is easy to ignore in the short term when they're not obvious. I feel like the mindset that languages that try to make them more apparent up front (which I honestly would not include Go as one of) are somehow getting in the way of us is pretty much exactly the opposite of what's needed, especially in the systems programming space (which also does not really include Go in my mind).
I for one welcome the use of type systems and PL research to guide me in expressing my programs in correct ways and telling me when I'm wrong based on solid principals. If you want to segfault for fun, there's a time and a place for that, but it's not in my production code.
And yet all that PL research couldn't stop rust from bringing cloudflare down.
And the compiler had nothing to say about it. "Carry on, thisi is perfectly fine rust code that might crash your app with a panic if left unchecked, no biggie. LGTM" - rust compiler
I'm so sick of hearing about how "Rust brought cloudflare down". No it did not. Unhandled error cases are possible in any language, and calling `unwrap` is literally the developer telling the compiler, trust me, it's not an error.
At the very least, something that brings the application down when the dev assumption fails should be called a much more dangerous word than "unwrap".
So yes, the language has failed there.
"You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.
> "You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.
The thing is that Rust's promises are more tightly scoped to very specific types of (mis)behavior. I don't believe it has ever claimed to prevent any and all types of stupidity, let alone ones that have non-stupid uses.
