Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory.
If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring.
Better one hour writing "if err" than two hours looking at logs at ohshit.30am.
there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that.
there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.
No, it was adopted quickly because it's a simple, script-like language producing static binaries that didn't require any runtime, highly portable with built-in cross-compilation, requires very little resources, is able to perform pretty damn good and has an extensive standard library (although not perfect) supporting many modern technologies.
That are a lot of boxes it ticks off. I remember wanting to start hobby projects with friends where the end-result would preferably be a native binary, and the limit was that I was the only-one with a C/C++ background. Now anyone with some scripting background can pick up Go in a few days, without having to worry too much about a build system, portability, cpu architectures, performance, memory leaks, ...
Sure, Google was the initial push, but it only really took off once projects like Docker showed it's potential.
I think that's the point really. I think the average programmer like using generics, but rarely builds their own code with them. I've used them from time to time to great effect, but the use cases were pretty isolated. Maybe that makes me average? /shrug
If you declare a map[string]int, Go will guarantee that keys are always strings and values are always ints, and it's a compile-time error to pass it to someone expecting a map[string]float64. Without generics, the only way to do that is to generate and compile a MapStringInt struct and a MapStringFloat64 struct and a...
In Go, the magic right now is actually in special-cased types like map. Generics actually have the potential to reduce the amount of magic as it exists currently.
The design can go badly wrong, of course, but it can also go wonderfully right. Generics are a very important feature to consider for the language.
I have no opinion on exceptions with regard to Go specifically. I think they serve a good purpose in other languages but are often misused.
Yes, I had read in an article about/by Walter Bright about D, that that was the insight he had, when working on the design of generics or templates for D:
To paramet(e)rize the types (of a class or function or method), just like you parametrize the arguments of a function or method.
Update: searched for and found the article that mentions that:
[ Walter: We nailed it with arrays (Jan Knepper’s idea), the basic template design, compile-time function execution (CTFE), and static if. I have no idea what the thought process is in any repeatable manner. If anything, it’s simply a dogged sense that there’s got to be a better way. It took me years to suddenly realize that a template function is nothing more than a function with two sets of parameters –compile time and run time–and then everything just fell into place.
I was more or less blinded by the complexity of templates such that I had simply missed what they fundamentally were. There was also a bit of the “gee, templates are hard” that predisposes one to believe they actually are hard, and then confirmation bias sets in.
I once attended a Scott Meyers presentation on type lists. He took an hour to explain it, with slide after slide of complexity. I had the thought that if it was an array of ints, his presentation would be 2 minutes long. I realized that an array of types should be equally straightforward. ]
So much this. Been doing this for 25 years and I loathe magic like Exceptions. I consider Go's explicit error handling a plus. Any editor would let you code ife to generate the error scaffold.
I don't hate generics, but I don't require them either. If the Go guys can make them work well and fit into the language i'd be fine with it, but I don't want them to feel pressured into throwing something out there for the language purists. I doubt they feel pressured. They've been around the block and have as good a sense as any group i've ever seen for what to include in the language.
Go is not the language to use if you want to write clever code, but it's great when you write code for businesses that must run 24x7.
I hate generics. also, I hate exceptions.
Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory.
If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring.
Better one hour writing "if err" than two hours looking at logs at ohshit.30am.