491–500 of 534 posts
Earlier quoted context omitted.
> Just because the majority of them are commercial doesn't change the fact that they exist. No, but it does explain why Java is not a worthwhile option for OP.
Moving goal posts? The OP asserted they did not exist.
Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…
Just remember, they probably think the same thing.
Earlier quoted context omitted.
What a remarkably condescending philosophy! Do people really think that poorly of their coworkers? Of themselves?
Treating users like idiots is a common engineering practice, not only in programming. Assuming users only make intelligent choices is just unrealistic. It is not that you underestimate any particular person. You may argue if Go finds the right compromise between giving enough power to their users and not allowing them to shoot themselves in their feet, but the general premise seems to be a very sound one to me.
I believe the designers of Go are onto something.
It's not just the code, but how the code will evolve over time, after a few years of having dozens or perhaps hundreds of programmers modifying it.[1]
In a large shared code base the following dynamic plays out.
* A programmer is assigned to fix a bug, or add a feature.
* His reward for that task is limited to whether he succeeded in achieving that task.
* Even if he is rewarded for improving the codebase overall (refactoring), this introduces much more risk than simply making his changes and getting out.
Basically, everyone wants to get in, make their change, and get out. Now iterate this a few thousand times.
Really it's just the tragedy of the commons, and codebases rot because of it.
The problem is magnified if the language encourages lots of complicated abstractions and meta-programming, because abstractions are difficult to evolve incrementally.[2]
Honestly, I just see Go as a reaction against C++ in this regard.
I still believe however, that the Go team went too far in leaving out features, especially in the areas of generics and error handling. I mean both create more code, so what if it's simple code?
Then the problem becomes that you just have more lines of code to maintain and test.
[1] And for twenty years I was a freelance consultant brought in to untangle big pile of mud codebases for projects in crisis.
[2] See the concepts of assimilation vs. accommodation in psychology. Once your abstractions need to accommodate an inconvenient new fact, then it takes a lot of disruptive effort to fix the problem.
Earlier quoted context omitted.
This argument falls flat for me. Classes aren't supported natively by processors either, yet any number of OOP languages use them. It's generally nice when you can do simple things with the language's built-in standard library. I tend to prefer languages with more powerful standard libraries because it means that you can more easily move across codebases since they'll all be the same. If commonly used data types like…
Yes, standard library. I understood the poster above you to suggest they shouldn't be a part of language by that's used by default, for sure though it would be convenient to have centralized implementation.
As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…
Earlier quoted context omitted.
I don't know how many times I've been writing a program using int, then suddenly I have to do some math on the index of a range (for example), and the math.* functions require int64. I start casting to int64, but things get infected and it spreads. Eventually I refactor everything to use int64 and wonder why int can't just be an alias for one of the others. Personally I would make it int64, since that is what the sta…
Odd, I've rarely had this issue, and almost never need to do complicated math on the index of a range (maybe "multiply by two and add one" kind of stuff, but nothing from the "math" pkg). Also, note that the math.* functions all use float64, not in64.
As for the int vs int64, I definitely run into what I describe on Project Euler. Probably using a self referential map[int]int when I need to suddenly pull an int64 and everything gets infected.
I realize it's just a matter of convenience for me, but I personally have no downside to int == int64.
> Go 2 will be much more community-driven. Please no ...
There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind. I'm also worried about how being "community driven" will change the philosophy of the langua…
Earlier quoted context omitted.
> if this int or uint under or overflows, throw an exception Overflow flags are supported on some architectures, so it would really just be a matter of checking that flag.
Except in Go, types are defined using modular 2s complement. Overflow is not considered a problem, it's a feature that code depends on.
> For signed integers, the operations +, -, , /, and It does not go on to define the overflow values; that gets to be implementation defined.
This is in contrast to unsigned integers, which the spec does precisely define overflow for.
Earlier quoted context omitted.
Rather than writing multiple functions that take different types as args and return different types (say int8, int16, int32, etc.) but do the exact same thing, with generics, you can instead write one function that takes a number (which could be any int type) and return a number, and you only wrote one function. That is generics in a nutshell. The function is generic, not specific to one type. Generics allow for less…
Wouldn’t this make golang slow though? Isn’t that what people claim makes python slow?
This could be my naïveté, but I don’t see why generics in Go couldn’t work analogously to the way they do in TypeScript, just a way for the compiler to verify the correctness of code accessing an interface{}.