I see it as taking the copyright holder's control over their material, not taking the material itself.
In other words, if someone publishes your works for free that you would otherwise charge for access, they haven't taken your work, they've taken your control over the access to it.
If you're using Terraform, why are you having problems with the interconnectedness? That's exactly the benefit of Terraform. Parameterizing all the configuration dependencies is its brilliance. Nothing I've come across is as simple and easy to use and understand while still being able to fully managing an entire infrastructure.
I was _only_ pointing out, through _one_ simple example, the flaw in your conclusion of Go errors being tedious. I was not discussing other languages nor how to incorporate extensive and fluid error handling in Go to be as capable as any in other language. And since you've raised several points that weren't pertinent, it seems you simply want to disagree with me, so i'll end my side of this discussion. Have fun.
> I think would try to use its panic/recover mechanism as much as possible
And that's exactly the reason you should avoid Go. Every error is not exceptional. Most errors are not exception. Hence, most errors should not panic.
> to avoid the tedious multi-level error handling.
It only looks tedious to the uninitiated based on code snippets you've probably seen. Or if you're stuck in an imperative paradigm, i can imagine Go will feel tedious. But since Go has first class functions, it's quite easy to write high-order functions that work better than try/catch and make error handling flow quite nicely. It also provides better error handling than cumbersome, coarse-grained, and verbose try-catch clauses where the catch clause is not directly related to the call that produced the exception (which probably isn't really an exceptional case but rather just a simple error.)
Yea, Python can do the same but because Exceptions exist, everyone considers simple errors to be exceptional. Go allows errors to just be errors and error handling becomes related directly to the call that caused the error.
If the authors are opposing advertising, why are they advertising their opinions here? These naive opinions are more intrusive to me than many targeted advertisements. To be clear, i'm not opposed to ad blockers. I'm also not opposed to some advertising. I am averse to hypocrisy.
Just silly! Pioneers are more important than bringing the pioneering to the masses. We don't pioneer for perfection, we pioneer for discovery. Completely different purposes but without discovery, there is nothing to perfect.
Additionally, light on dark is horrible for readability. That theme is great for imagery but it's doesn't provide valuable contrast for clearly rendering fonts. Programming docs are typically mostly text so should provide the best colors that support readability.
Actors/messaging doesn't imply a remote-backend architecture. It only implies messaging and mutually-exclusive _writable_ state.
GUIs is a poor example as they are inherently single-threaded frontends so performing simultaneous actions is already often implemented utilizing message-passing to backend threads which report back to a single-threaded event-loop. That architecture can be local, backend "threads" or remote processes, as it doesn't much matter to the GUI.
With regard to in-memory persistence, again, you almost certainly would not copy data per thread. For a situation like you're describing, a Redis-like architecture is all you need with a few atomic primitives. But, again, incredibly easy to implement in Go and is certainly _not_ rocket science.
Of course, someone is going to still be using locks, but it's a diminishing number of developers that need to code at that level since there are better higher-level techniques that serve many purposes and protect against many types of errors.
Agreed. Now days, you should not even think about threads. If you are, you're doing it wrong. You should only be concerning yourself with immutability or not sharing state. Hardly rocket science. Here's how easy it is in Go: https://github.com/Spatially/go-workgroup just write a function and send it data. Done. Granted, to do that distributed requires some thought for the remoting but still not a concern for the developer.
Just because _you_ are locked into a mentality about a meaning for // does not mean we all are. Explain to me why formatted/structured text can not appear after a // in a file. If your editor parsed the text and formatted it to look meaningful, like code, would that help?
In other words, if someone publishes your works for free that you would otherwise charge for access, they haven't taken your work, they've taken your control over the access to it.