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.
My example is we want to skip the div if empty or undefined. We can't throw on assignment so we leave it as as string|undefined.
When we go to display, we have to check if the string is empty anyway, right? What if it's empty in the DB or API response?
No matter what the display-component is doing something to prevent showing the empty string.
`
if(fooBarDisplayName.length) { show div }
`
or
`
if(fooBarDisplayName?.length) { show div }
`
I'm not sure what we gain by leaving it as `string|undefined`
---
If there was a "NonEmptyString" type maybe I could see where you're coming from.
I guess you could argue treating `string` like a `NonEmptyString` type seems error prone. The compiler can't verify you've done the check. At some point someone will set a string when it's empty or not do the necessary check.
You'd want a separate non-string type to make sure it's actually been parsed
Sure, that seems like a reasonable observation. But the answer to that is to ask the other nations to step up - not to step back and let people die hoping someone else will catch them
You give them too much credit if you even suspect them of doing the right thing. You can't expect them to just give up an avenue to such an unfair advantage, no matter how illegal it is. Their wealth and power is incompatible with ethics and legality. I mean, what else do you expect from a guy who so insensitivity mocked and laughed on TV at the misery and suffering that he inflicted on the ordinary people? Besides, who is gatekeping their access to the federal systems now? They fired everybody who tried to resist.
Let me get into a conspiratorial territory now. I have a feeling that the access to those systems are not limited to just this wannabe-Nazi and his minions. I suspect that some very hostile and clandestine elements like Palantir might have integrated into it. I don't have serious evidences to back up any of these. But a lot of people are discussing this now. These aren't even secret plots. These tech bro billionaires have been publicly expressing their contempt and disdain for ordinary people and democracy for nearly two decades now. They had been publicly endorsing and promiting tech authoritarianism. Much like the Project 2025, they had been outlining their plans too (though less publicized), that they're following to the dot now. Crimes come with a user manual these days, it seems! They salivate over a tech dystopia like in the Dredd comics. What lends credibility to this is their publicly conspicuous cooperation, that's less likely under normal circumstances.
All these are why I always say that 'I have nothing to hide' is a terrible argument against personal privacy. Anyways, just assume that your past and future confidential information is entirely compromised by some very nefarious elements that are openly hostile at you.
For a function setVelocity() that can accept 1..<200. You call it with numbers that you enter directly and types tell you something that would otherwise be a comment on the function, or you do runtime checks elsewhere, and the type becomes proof that you checked them before handing it into the function.
Btw, using “autism” to mean “pedantry” leaves a bit of a bad taste in my mouth. Maybe you could reconsider using it that way in the future.
Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data. You could just clamp velocity to 200 in the callee and save all that hassle.
> Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data.
TypeScript does not perform any kind of casting at all. What TypeScript supports is structural typing, which boils down to allowing developers to specify type hints in a way that allows the TypeScript compiler to determine which properties or invariants are met in specific code paths.
Literal types address a very common and very mundane use case: assert what can and cannot be done with an object depending on what value one of it's fields have.
Take for example authorization headers. When they are set, their prefix tells you which authorization scheme is being used by clients. With typescript you can express those strings as a prefix constrained string type, and use them to have the TypeScript compiler prevent you from accidentally pass bearer tokens to the function that handles basic authentication.
Literal types shine when you are using them to specify discriminant fields in different types. Say for example you have a JSON object that has a `version` field. With literal types you can define different types discriminated by what string value features in it's `version` field, and based on that alone you can implement fully type-safe code paths.
If you have some `ConstrainedNumber` type, you will need to cast between it and `number`, either with a type assertion or with a type guard. In either case, when you use bespoke types everywhere you kill code reuse.
Casting? Not really - i think you’d only need a couple type checks.
Imo this is mostly useful for situations where you want to handle input validation (and errors) in the UI code and this function lives far away from ui code.
Your point about clamping makes sense, and it’s probably worth doing that anyway, but without it being encoded in the type you have to communicate how the function is intended to be used some other way.
Ah, yeah you’re right. I somehow thought typescript could do type narrowing based on checks - like say:
If (i >= 1) {
// i’s type now includes >= 1
}
But that is not the case, so you’d need a single cast to make it work (from number to ClampedNumber<1,200>) or however exactly you’d want to express this.
Tbf having looked more closely into how typescript handles number range types, I don’t think I would ever use them. Not very expressive or clear. I think I hallucinated something closer to what is in this proposal: https://github.com/microsoft/TypeScript/issues/43505
I still think that the general idea of communicating what acceptable input is via the type system is a good one. But the specifics of doing that with numbers isn’t great in typescript yet.
How would you implement it in other languages that support it better? Can you literally just do a range check and the compiler infers its range for types? If so thats actually pretty neat.
Yeah, that’s probably the best possible implementation outside of the type system. The issue with docstrings is that they aren’t checked. So you’ve communicated the api to the coder, and maybe even to the ide, but not to the compiler.
Have you ever `ls -al ~/` on a heavily used unix system? Absolute rot and chaos. I have like 100 hidden directories+files in the root of my home directory. Some of them are caches, some are configs.
reply