No. Why would it? While a lot of things there are universal the purpose is to support Arch Linux. If you can use it for another distro - use it. There are more important things to spend energy on then just renaming stuf pointlessly.
Go is a programming language. It’s not exactly pushing google’s ad agenda.
Your criticism of using github and discord are somewhat valid, but asking people to re-invent the wheel while they re-invent the bicycle seems like arbitrarily making up rules so everyone fails. Is there some influence you expect to leak into their platform thru github or discord?
They are standing on the shoulders of giants. There's nothing wrong with the ideals and the motivation, but it begs the question: Could Mu exist without go? could go exist without google? Could Mu exist without google?
And all of that culminates with: Could the level of technology and the internet reach the state it is today without big tech? And if not, was the price we paid to get here worth it?
> but it begs the question: Could Mu exist without go? could go exist without google? Could Mu exist without google?
No, it doesn't.
Obviously Mu could exist without Go, if Google stopped development on the language, its current state could be forked (Go 2). Lots of programming languages exist without Google's support, there are even programming languages older than Google.
go does push silly things. besides being overhyped, they block anonimizing tech when accessing package repos for example.
you dont want anything to do with google or anything they make or host. they will only do it to extract shit from you. they dont give nything dont be naive.
C is also a programming language. Unlike go it foes not depend on a big tech company for it to live.
No need to reinvent the wheel. Just use wheel that does not come with a big techh bagagge.
Maybe not their ad agenda, but certainly one of their agendas. Specifically, the agenda they have to get young, inexperienced developers prepared for specifically the software development practices they employ internally.
It was directly stated that "Go is not for clever developers" and that their target is recent graduates with limited experience. It punishes you for trying to think about what you're building and to design sophisticated software, relying more on brute force. It doesn't encourage you to reach higher.
I don’t know where you are on your career journey, but having worked with countless clients, business domains, and projects as a freelancer I value readability over everything else.
If you’re working on a greenfield project in a team of one then I suppose it’s great to get in an expressive mood and emit your code poetry from those fingertips.
It’s very different to inherit a quirky puzzle and reverse engineer a mental model from there.
What “clever” code is required to write a BBS-over-IP? 99.99% of code isn’t clever and shouldn’t be clever.
> It punishes you for trying to think about what you're building and to design sophisticated software, relying more on brute force.
Can you give an example of this? I have not written much go, so i am unable to think of a case where golang encourages brute force over sophistication?
FOSS projects have their constraints on time and usually not talent, like for-profit teams often are, so they should want the code they write to go farther.
They've explicitly stated that they wanted to discourage building abstractions, since "abstractions are hard to learn".
Concretely, this is evident in how channels and goroutines both poorly compose together, in part a result of the unsophisticated type system. It's difficult to build very generic libraries that can be leveraged as force multipliers, like the tokio-tower ecosystem does. You can do it, but it comes at performance costs or involves relying on codegen.
Google's Bazel build systems are designed around reasoning about and checking-in generated code, but the standard go tooling doesn't do this well and git workflows also don't really grapple with it well. This aspect of the design is very clearly an example of internal Google processes leaking out.
I've been writing software with Go for over a decade now so it's just down to ease of use and what I know. It's performant, straightforward, compiled. It's a no nonsense language and does what it says. I'm not the type to get into language wars. I have a tool, I use it, that's it. Thanks for the question.
Love it. What could be a good addition IMHO is to add approximate costs of the placed systems, and cost of the ammunition used during the simulation ( for both attack and defense ).
I find that hard to reconcile given what I was responding to:
"Love it. What could be a good addition IMHO is to add approximate costs of the placed systems, and cost of the ammunition used during the simulation ( for both attack and defense )."
I just unsubscribed using web form. There are some dark patterns involved but not too dark. E.g. first option is the chat with representative, second is the call by phone and third option is the web form.
After I have navigated 3 pages using "default button" for canceling the unsubscription process - it is done.
It's not the best experience, but not the nightmare the OP described.
FYI, using the NYTimes mobile app should follow the same flow described in the parent comment. I'm in NY state. Just choose the "web form" option to cancel, click through two or three confirmations to cancel. And you're done. Took all of 20 seconds.
