8 ms·
why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the
by mlevental 7y ago
why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional transformations, generics, enums, structs, iterators, objects with many method qualifiers, etc) but really nice and efficient to program in.
- astrobe_ 7y ago> why are people obsessed with simplicity? > "make things as simple as they can be but no simpler". Those people are obsessed, precisely, with the "can be".
- dimgl 7y agoI have yet to find one practical application for generics in the apps I've built in Go.
- mcguire 7y agoIf you've never used a screwdriver, all you can say about screws is that they make crappy nails.
- rad_gruchalski 7y agoEvery project I’ve written so far in golang could benefit from generics.
- freetobesmart 7y agobut what is the benefit? How does your code change. Generics are a tail abstraction. Its the last abstraction that you are able to make to your code to reduce boilerplate. This usually means that is the least useful and in generics specific case the boiler place it reduces is minimal. Its lack of impact is why I dont really care about the subject. Adding or removing generics to a project matters little. So why bother complaining. The class creation and encapsulation choices are much more impactful to future code edits.
- rad_gruchalski 7y agoMy experience from scala is that the use of generics is not an afterthought, not a boilerplate abstraction. They’re come in handy naturally when one knows how to use them, and it is not rocket science. The real benefit of generics. They enable composability. The complete scala collections library is the best example of that. The benefit is non-obvious on a single function level, a complete program is another story. It’s, of course, possible to to achieve something like this with golang and interface{}. I don’t mind working with it, all the type switches and what not make feel like a proper tinkerer! What is actually happening:, I’m wasting my time, the compiler already knows all the types. It can figure things out for me. Of course, a sound type system is then needed. The types switches are error prone, it’s like working with java.lang.Object everywhere. And if I can avoid all these “GetX” functions, where X is “String”, “Int”, “Int32”, “Int64” and so on, even better. Just look at viper, it would be so clean and lightweight with generics.
- fredmorcos 7y ago> Generics are a tail abstraction. Its the last abstraction that you are able to make to your code to reduce boilerplate. This usually means that is the least useful and in generics specific case the boiler place it reduces is minimal. This is absolute and utter delusional nonsense.
- silasdavis 7y agoGo strongly discourages you from making extremely useful abstractions over types early on in your design. You don't just write things the same way and remove boilerplate with generics you can exploit more symmetries.
- _ikke_ 7y agoThe benefit is that you can remove a lot of duplicate code that does exactly the same, except the type it operates on. The blogpost talks about the Reverse function. Especially when you need to make changes, (fix bugs, performance improvements, etc), if you have dedicated functions for these, it takes effort to keep them (plus tests) in sync. If you don't see any issue with this duplication, then I can see that generics don't add a lot.
- kd0amg 7y agoGenerics are more for developing reusable libraries than single applications.
- mlevental 7y agoThat's because you write a particular kind of program. Notice that there are no good ORMs or numerical libraries. Both of these are use cases for generics. Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one).
- dimgl 7y agoDevelopers think ORMs are evil because they've had horrible experiences with ORMs in general. I'm one of them. The only ORM that I enjoyed using was Dapper, and it's barely an ORM.
- runevault 7y agoDapper really is such a weird edge case. You still write all the sql, all it does is the conversion from a type to the input parameters and the returned rows into objects where the row names match the parameters of the class. Frankly I feel like that's the right way to build ORMs in all languages that have the facilities to manage it (and maybe those that don't you pass in a function pointer to do the dumping of rows into type for you)
- throwaway8879 7y agoThe sqlx package is a similar Go wrapper around SQL. Very handy for scanning into structs.
- buildzr 7y agoWhat sort of horrible experiences have you actually had with ORMs? Every time I've used one it's been an absolute joy, I hate repeating myself in my DB, in SQL, in mapping code and again in application code. The main thing I see people complaining about is performance edgecases, but for small and mid scale applications these can never take away the massive DRY principle gain good ORMs provide.
- twodave 7y agoAnd almost every usage of Dapper relies heavily on generics.
- stouset 7y agoAnd I had yet to find a single practical application for closures, right up until the moment I started using Ruby (and later, Rust). Turns out that they’re so useful in practice that they’ve been bolted on to—as far as I can tell—nearly every language in widespread use today. None of these languages “needed” such an improvement. Billions of lines of Java and C# were written without this feature. And yet today it would be virtually unthinkable to release a language without them.
- dimgl 7y agoI feel like closures are a consequence of having functions as first class citizens, so it's not exactly a direct comparison. But I guess I see your point.
- Smaug123 7y agoSafety! Generics allow you to get [theorems for free](https://ecee.colorado.edu/ecen5533/fall11/reading/free.pdf https://ecee.colorado.edu/ecen5533/fall11/reading/free.pdf), so generics make certain classes of error extremely hard to make.
- pknopf 7y agoThat's crazy. I've seen people implement templating of go files to support generics in Go because it's serves a valuable purpose.
- RHSeeger 7y agoI see you program in Blub (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html).
- bbatha 7y agoIf the std lib had functions that mapped to the "Slice Tricks"[0], like virtually every other language, I'd use them constantly. Sure I wouldn't write generic functions all that much, but calling generic code I would do every day and it would be a serious ergonomic, correctness, and readability improvement to have named functions for very common patterns like the slice tricks. 0: https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks
- iainmerrick 7y agoRight, I see this as the biggest benefit. Go already has generic built-in maps, channels and slices, so clearly those generic types are useful. If what I actually want is a multiset, say, it would be great to have a standard library class that looks and behaves similarly to map except it’s a multiset, rather than just having to use map and do all the little 1- and 2-line boilerplate tricks for the multiset operations. I can write shorter code that more clearly expresses my intentions, and reduce the risk of stupid little bugs in the boilerplate.
- whateveracct 7y agoIf you're writing loops that build up some accumulator, you could use generics. Even if you don't see that.
- iainmerrick 7y agoYou could use generics for that kind of code, but that doesn’t necessarily mean you need them. If you’re thinking of functional stream operators, many people think plain imperative iteration is easier to write (and easier to read).
- whateveracct 7y agoBy that logic, there's nothing you _need_ generics for.
- icholy 7y agoYou've never used a data-structure other than the built in maps and slices?
- haolez 7y agoC++ solves all problem that can be solved with Go, but with a lot more features. Why are we not using C++ where Go is currently being used? By your logic, this shouldn’t be the case.
- wvenable 7y agoI'm pretty sure C++ is used for exactly the game thing Go is used for. And C++ is used for a lot of other things as well. In fact, you will probably have trouble finding a problem that wasn't solved by C++ by somebody. Scientific computing, server process, CRUD applications, embedded applications, AI, graphics, programming languages, libraries, etc. C++ has a lot more features and therefore it's actually able to be used for a lot more things. People that don't need a language that can be used for every possible computing problem think that maybe C++ is a tad too complicated. Those people certainly have a point.
- esarbe 7y agoI don't think it's the feature-set that makes C++ viable for more situations than Go. In my opinion that's only because Go uses managed memory. That takes part of the runtime behavior of the code out of the hands of the programmer. This counts out Go for situations where you need precise control over runtime behaviour. That said; C++ is a ridiculously complicated language. I don't get why people think that Rust is difficult.