It's not about hard drive space, it's about start up time.
The 10x LOC (despite being a huge exaggeration) is also the fixed cost, not the marginal cost. You're only forging main loop and includes, not any fundamental complexity.
This is also a funny argument coming from a Go programmer considering that Go trades off conciseness and expressivity for simplicity. Show me some of your favorite Go and I'm sure we can replace it with some concise C++.
But if everything was written in Go it might be 1 megabyte * the number of users of coreutils. Might be worth using a few more lines of code to save a little bit of space on a lot of machines.
with Go you have ONE go.mod file, at the module root. you may have 100 sub packages or sub sub sub packages, but still only ONE go.mod file. then any time you need to add a new import at ANY level, you just go "go mod tidy", and DONE. please dont try to compares apple and orange and say they are both apples.
There really isn't a huge difference, both have workspaces, and both allows you to add arbitrary go.mod or Cargo files where you want. The biggest difference is that go defines a module as a folder, where rust does it pr file. That said I don't know how that plays into how it is compiled.
Any of these subpackages, if they don't have a go.mod file, would require defining their dependencies top level as well, and when you go get the package you would need to pull everything, even if you only need a subpackage. Which usually isn't a problem, because golang is super fast to compile.
I get that they aren't identical, but tbh they are pretty close
Additionally Go requires search and replace all over the place, if a module ever changes it SCM location, and having internal build caches for the company, not even bother.
> I make no claims about use of generics making your code being absolutely good or bad, but I do make claims that use of generics can make your code less error-prone and safe.
Right. this is the issue right here. people only see that Go didn't have generics, and they never stop for a second to think WHY Go didn't have them. Generics have an implementation cost for the Go project, and maintenance cost for the Go project, and end user negative impacts in regards to time and memory. but advocates often dont know or care about these drawback, and only howl that GENERICS ARE MISSING until they are added, consequences be damned.
I'm just saying that while generics are useful in some cases, they are not always the right answer, and it shouldn't just be assumed that every language needs them, nor that any non-generic language "sucks".
> stop for a second to think WHY Go didn't have them
I have thought about this. I concluded that Go doesn't have generics because it's a poorly designed language whose designers elected to ignore decades of progress in programming language design for... reasons. Hence why you have to do the moral equivalent of passing around void pointers and checking return codes in $current_year
> I'm just saying that while generics are useful in some cases, they are not always the right answer, and it shouldn't just be assumed that every language needs them, nor that any non-generic language "sucks".
It's funny to me, because this comment chain exists because I said I got tired of rewriting the same functions with minute changes, the exact problem generics is intended to solve. I didn't say anything sucked, or even that I didn't like Go, just that this one aspect got tiring.
And yet, this small comment lead into a person feeling their language was being attacked.
If you like Go, that’s great. But stop pretending people don’t know what they’re talking about when they talk about generics or haven’t thought about it.
well, he could have done nothing, and where would we be? if you say "exactly where we are now", I think you are being dishonest with how the situation played out.
No, he didn't write the code or make the schedule, but he stood up and said "this is not right", and took steps to protect his and other small sites.
Here is Go version. works exactly as expected, no surprises. People just need to grow up and use a modern language, not a 50 year old out of date language:
package main
import "fmt"
func main() {
var i, iterations, meters float64
for iterations = 100_000_000; i < iterations; i++ {
meters += 0.01
}
// Expected: 1000.000000 km
fmt.Printf("Expected: %f km\n", 0.01 * iterations / 1000)
// Got: 1000.000001 km
fmt.Printf("Got: %f km \n", meters / 1000)
}
> the user must be able to clear it when clearing site data and this what makes it currently an unviable solution
What are you suggesting here? That extensions should have some special storage, that can't be (easily) deleted? Noooooooo thank you. Firefox has "forget about this site" and similar tools, which I use near daily. Don't fuck with my ability to do housekeeping.
I am fine with this. I personally have no interest in Copilot, but my understanding is its not small feat to offer a service like this. I think it would be understandable if the "free tier" was severely rate limited. GitHub has plenty of crappy business practices, this seems pretty tame. The honeymoon is over. If people want this technology, they can pay up.
Not sure if this is still the case, but last time I checked Microsoft Office had student discount, but was not generally free. This seems like a similar situation.
