111–120 of 378 posts
* should the builtin generics syntax be compatible with the new custom syntax
* how many problems will be solved by the custom generics and how much complexities will be added. Is it a good balance?
Earlier quoted context omitted.
This can be said for any programming language and any community: there will always be bad code written by someone. Generic data structures are provided in many programming languages and there are many people that are very experienced in writing some of these, so being able to reuse, it's precious. In general the lack of generic price surfaces when you write libraries, not applicative code. But libraries are a big por…
I’ve been coding for decades. I’ve used all the fancy functional languages, written production code at scale with complex type systems, etc. my experience, they don’t add a lot of value compared to the costs. In my old age I’ve grown to prefer go for it’s simplicity. I hope we don’t lose it, and you all have the option of using the myriad languages that already do what you are looking for.
Still in my short Go career, I worked on at least 4 libraries, one of those needed generics to gain a huge performance boost, the other worked around the lack of generics, but I still wish it had it (a special kind of logger). In applicative code, the main issue with lacking of generics is the lack of generic slices functions (map/select). Initially I thought it would be fine, but then I wrote a piece of code that was visibly involved in copying data from one slice to another with some changes and that "shadowed" the "central" part of the code behind a bunch of loop codes. In those cases, to improve the ability to easily scan through the code, I wish I had some generic slice function to deal with it. I appreciate doing loops, but sometimes they are verbose enough to hide the interesting part of a piece of code. This is especially visible in applicative code where usually performance is not as important as much as the business logic.
Earlier quoted context omitted.
How is a generic data structure a COMPLEX ABSTRACTION?
If people would stick to common generic data structures (like a map/list that can handle any datatype), i'd be fine with abstractions. But some people have a tendency to play code golf with their codebases. I have, for example, encountered a "generic data structure" that looked like a normal linked list on the surface. BUT, it actually sorted the largest three items in the first 3 cells and the average in the 4th. Th…
To the people moaning about how generics will make their favourite language as awful and ugly as Java: all of the libraries and techniques you like and use today will always work. Little things like sorting will use generics pretty much transparently. All of the strongly typed code you write today that receives and returns concrete types will be just as valid tomorrow as it is today. Interfaces keep the same semantics and are a core part of how generics work.
I think it’s important to remember that the people who design this language like it for the same reasons you do.
As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. It will still be only in one place, where as in C++ you could have hundreds of functions with the same name across many libraries and you just have to hope your ide knows which to step into.
Earlier quoted context omitted.
There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.
I feel like it pretty much always turns out that the things you can't do without generics are, like, second-order things. Higher order functions, type safe custom collections, those are tools. What we care about mostly is what we actually build , and people build pretty much everything in every language, generics or not.
But some people like offloading that to the language: not having it in a language means you don’t have to control for it on your team/project contributors + some 3rd party library.
I felt Go filled this minimalist category well. It’s always nice having a modern mainstream option doing so, not just a niche one on the fringes (ala LISP), even if I’m not personally a fan.
I guess it’s hard to keep saying no.
Earlier quoted context omitted.
You say "verbose and repetitive", I say "easy to read without any surprises". The verbose patterns (if err!= nil for example) make the code predictable to read, you notice the code smell of missing error handling really fast.
I think readability has multiple dimensions, and it really depends what you are looking for. For example here's a code in Go to look for a Prime: func IsPrime(n int) bool { if n It's readable as it is simple to understand what each line does. Here for example is a code that does the same thing in Rust: fn is_prime(n: u64) -> bool { match n { 0...1 => false, _ => !(2..n).any(|d| n % d == 0), } } It's might seem more c…
That seems unfair when comparing:
Removing negatives from the Go implementation removes 6 out of 16 lines, bring it from 3x Rust to 2x Rust in line length.
Earlier quoted context omitted.
Yeah, that's why Kubernetes had to develop code generators. So focused.
I wouldn't know, I don't use K8s. But I did write a code-generating ORM for a Go project and found it in a bunch of ways superior to the ORMs I'd used in dynamic languages, like ActiveRecord. And I've also worked with heavily parameterized Rust crates that kept 20 tabs open in my browser just trying to work my way through a couple function calls. Don't get me wrong, I'd take Rust generics over codegen 8 times out of…
If they didn't, they would just not create another solution.
Having said that you might be right with ORM though. One of great reasons why ORM might be superior on statically typed language is that you can rely on the type system to ensure you writing correct code (you also get benefit of autocompletion, refactoring in IDE etc). The problem though is that the type system including generics might not be sufficient to express it. So code generation could be still superior here.
The JOOQ (not exactly ORM though) generates java code, even though Java has generics.
BTW: I personally think though that actual proper way to handle this problem is to what JetBrains did. They integrated DataGrip into their IDEs (I think it's available in the paid version though) after you connect IDE to the database, it starts detecting SQL statements in the code and treat it the same as rest of the code (i.e. auto completion, some refactoring (they still need to improve that more) etc). It makes an ORM no longer necessary for me. I think that's probably the way to solve the impedance problem.
Earlier quoted context omitted.
How is a generic data structure a COMPLEX ABSTRACTION?
They are complex. I’m guessing you haven’t thought about them much beyond the trivial use cases.
Earlier quoted context omitted.
How would you write a singly linked list who’s contents are arbitrary? What if you were to map a function over it? Say you want to use this data structure with third-party objects? How do you do that right now?
You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.
As someone who hasn't used Go, what would I do, then? The question about a generic data structure was very practical, your response was philosophical, and I still need a linked list.