Because in many shops IT decides what languages people use, given the platforms, not devs. Also quitting the job isn't always an option. That is why some of us have to put up with languages that we rather not.
We change the language; people who formerly enjoyed the language now have to put up with a language they rather not. Their only option is to quit programming since there are no programming languages they enjoy left.
Go 1.7 is still around. If people can still run python2, by all means, keep fighting the good fight.
You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question. “ If your code did not use generics, it can continue to not use generics. If you did not interact…
Can't you and yours just freeze at go 1.7? That way, you get your diversity. Pretend every code base that's using go 1.8 is using java or something. A lot of us who write go everyday think generics aren't complicated and are tired or repeating ourselves.
This shows a profound lack of understanding of software development at scale. Also, as I've said many times in the thread above, I'm not talking about this specific implementation of generics.
And that is the exact joy of using a language like C or Go; you need to sort your things, just add in two pointers and make it a list you sort on. Eight or now sixteen extra bytes and you have a good tuned data structure. I don’t want to use a bunch of generic structures, I want to use the ones that solve my particular use case best.
I always say "Just right is all wrong". The time and standardization cost is often just too much for the small gains. I'd much rather have everything be reusable, abstracted, and one size fits all, aside from the tiny fraction that matters enough to optimize.
Good points. But for myself, I like it when the structure of the code and data structures exactly fit the need. Like the old quite, “show me your header files and hide the C files, and I will understand your program.”
Rust isn't a functional programming language. You could try OCaml, it's kind of a halfway point between Go and Haskell.
Rust has first-class functions. Not only that, but it also has immutability by default, and ADTs with pattern matching. If OCaml is functional, why wouldn't Rust be?
Well, one big one is lack of tail call elimination. If you can't write even a simple tail-recursive algorithm in the language, it's not a functional programming language.
I’ve audited a bunch of complex codebases in Golang that were very readable. Surprisingly readable actually
In my experience, that happens when people consciously manage the way they use their language, or have the trained instinct to do so unconsciously. At a certain scale choice of language doesn't really influence this all that much (as long as the language isn't Perl I guess, I've never seen that done cleanly.) I've worked on really neat big Scala codebases and really terrible big Go codebases – a determined developer…
I couldn't disagree more. Everything I've read in Java was a huge messy pile of spaghetti code. C++ and C can definitely become unreadable very quickly. Rust, on the other hand, I find harder to mess, although there are still lots of ways to do it. And then there's Golang, I've read so much Golang code that I'm surprised when I run into something that isn't readable. Happened to me once, obviously the code had been written by Java developers (factories lol)
Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.
> Existing libraries resorted to code generation a lot. guess what generics is in a lot of languages? code generation! the files just aren't saved to disk. IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.
> aren't saved to disk
This is a big win. They can’t get stale, they don’t need review, and you don’t have to remind everyone which files should never be edited.
It's less that it gained a new feature, and more (the fear at least) that it made a change for the worse. Avoiding updating to a new version of OSX that stabs you in the face is a reasonable thing to do, despite it being a new feature.
Go already had generic structures anyways. Go maps supported generics. Or did you always use map[interface{}]interface{} everywhere for the purity of your anti-generics position ?
The built-in types that supported generics were limited to the essentials; slices, arrays, maps, etc. Those basic building blocks were obviously sufficient to allow Go to reach the level of success it has. It's not an argument to allow for unlimited generics.
There is a slight difference between the two. With a map[†]bool, you can do something like: if myset[thing] { ... } With a map[T]struct(), you end up with: if _, ok := myset[thing]; ok { ... } Sometimes, the saving in space is TOTALLY worth the extra verbosity. Sometimes, the slight clarity from "non-existent keys return the zero value" wins.
You've also opened yourself up to bugs by allowing the map values to be "false". Using a "set's" value in an if statement doesn't make sense either, compared to if _, exists := something[item]; exists { ... } which is explicit regarding what's actually going on. As Rob said, "Clear is better than clever." https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s I also don't want to be hunting down whoever creates a map[T]b…
I would say that "exists in the set" is determined only and exactly by "mySet[thing]" returning true, not that there happens to be a key in the map.
But, that's one of those "requires extensive documentation" (and ideally, wrapping in a custom type and provide methods for checking and manipulating the set(s)).
> In fact kotlin/java has better peak performance than Go. Not really no.
Sophisticated garbage collection and JIT have a very high ceiling. The CLR and the JVM are incredible technologies.
The thing I hate about the JVM is that I'm always trying to tune it. So many options and nobs to turn. With Go I just run execute the program, no tuning necessary.
You are posting a criticism of the feature, in response to a comment that is an answer to that criticism . If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere. But just because you don't interact with a problem doesn't mean it doesn…
You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question. “ If your code did not use generics, it can continue to not use generics. If you did not interact…
Of course I'm not directly answering a polemic gotcha. If I work in Go, and I have a pain point in Go, and I want that pain point to be addressed, that's not being 'against diversity' or being 'for diversity'. It is being against wasting lots of time for nothing. Why are you against productivity? You continue to not directly answer that question.