5 ms·

I can not wait to never have to type interface{} again.

by kbd 5y ago

avl999 5y ago
Sad thing is that there is always a bunch of whining in any thread about 1.18 with people complaining about how much generics are going to ruin the language. I cannot wait for this release either, getting a proper set of data structures and concurrency libraries will be worth their weight in gold.
- digianarchist 5y ago
  Some things are just really painful to do in Go: merging maps, drilling into a JSON structure, checking if an element exist in a slice. Hopefully generics alleviates some of this boilerplate.
  - skybrian 5y ago
    I haven't used Go in a while, but those don't sound particularly hard. Isn't searching for an element just a for loop?
    - erik_seaberg 5y ago
      Rereading the same loop more than once is not a good use of time. A generic function can be named and reused forever.
      - skybrian 5y ago
        When I was writing Go I used to write little helper functions named "findThingy" that just wrapped a single for loop. A typical module might have a few of them. It wasn't hard to read and it wasn't that big a deal. I think the boilerplate from error handling hurts readability more. It will be nice not to have to do that, though, if I get back to Go again.
- akshayshah 5y ago
  I'm particularly excited to have all the patterns from the slice tricks wiki page[0] shipped as a standalone package. (I'm not sure why the slices package doesn't include any of the good stuff...) Understanding those patterns requires internalizing the relationship between slices and arrays, which is important but too high of a bar for a simple, safe in-place filter. [0]: https://github.com/golang/go/wiki/SliceTricks#additional-tricks https://github.com/golang/go/wiki/SliceTricks#additional-tri...
  - azth 5y ago
    What's quite sucky is that they will remain as standalone functions and not member functions, so you can't chain them (e.g. slice.Sort(...).Filter(...).Reduce(...))`. Not sure why golang is resistant to adding member functions to types.
    - EdSchouten 5y ago
      Why not just get a “pipe” operator added to the language instead? Many functional programming languages already have one. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/functions/#pipelines https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... No need to alter the type system of the language, while it’s clearly a syntactical improvement you’re looking for.
      - jen20 5y ago
        I (sadly) can't imagine that getting through the language modification process, somehow, though it certainly would solve this particular problem! If we're looking for things that Go could usefully take from functional languages I'd personally start with the much lower-hanging fruit of some guarantees about mutability of structures, though. (ps: Hi, Ed!)
    - erdeibit 5y ago
      My guess is that compilation time could be increased, which would let Go in the same boat as Rust or C++. I suspect every nice or must-have feature you add to a language, you must take the choice between deal with it in runtime or compilation time. Not adding features, no choice to take.
- aaomidi 5y ago
  To be fair, I am really excited for generics. However I do think the lack of the is the major reason go is such a readable language. Not being able to hide complexity behind types of types of types really ends up making code easier to follow. I'm excited and anxious about generics in go.
  - lttlrck 5y ago
    Isn't interface{} similar to void * - the king of hiding types?
    - hellcow 5y ago
      Yes, but it's a bit like Rust's `unsafe` in that reaching for it first is not a great practice. There's usually a better way. Using interface{} where you truly don't know and can't predict the data being sent to you is mostly something that libraries (like encoding/json) have already handled, so I don't have to interact with it much directly. I think generics are going to have the biggest impact in adding effortless type safety to all kinds of libraries, though.
    - aaomidi 5y ago
      I really don't come across this in most projects I read and learn from.
  - azth 5y ago
    Not sure golang is readable compared to other more expressive statically typed languages like Java and C#.
    - aaomidi 5y ago
      Definitely is for me and I used to only use Java for years. You can potentially test this for yourself by opening two large open source projects in each language and trying to figure out an issue from their issue tracker.
- geodel 5y ago
  > Sad thing is that there is always a bunch of whining in any thread about 1.18 with people complaining about how much generics are going to ruin the language. FWIW I think their complain even if not totally objective still have more weight as compared to non-users who say "I will use Go only when it has real generics/error handling/sum types/21st century features blah..blah.."
  - tomjen3 5y ago
    That depends on what the goal of Golang is. If they are happy with their current level of success, then sure. If not, there are a lot more non Golang programmers out there than there are current Golang programmers.
  - pjmlp 5y ago
    Sometimes there are tools that we have to use if we want to stay at current job, so it is nice when they actually update themselves into modern times, switching job everytime there is something we dislike isn't a viable long term career path.
deleted 5y ago
[deleted]
nick_ 5y ago
The resistance to adding generics to Go is a strong signal that the Go community has a serious problem.
- cachvico 5y ago
  Who's resisting?
- randomdata 5y ago
  He's talking about how Go 1.18 comes with a new "any" keyword, which is an alias to interface{}. Obviously there will still be uses for interface{}/any in your code, you just won't have to type interface{} anymore as you will be able to type any instead. This has nothing to do with generics.
tomjen3 5y ago
Now you can focus on if err return err instead. I wanted to like go for its crossplatformness, compile speed and relatively small memory usage while still being more practical than C++. But not having generics and having to constantly check for errors was the two big things that made me bail. Just to clarify, I don't want exceptions, I just want some language mechanism that changes err, value to be errOr<value>, which if passed to any function while an error will just propagage that to the return value of the function. Maybe for extra sugar something like errOr<value> | valueToUseIfError. This makes the code nice and thight, mean that I don't have to declare variables to give them one value to pass into the arguments of the next function and still perserve all the nice properties of Go. Also a nice cross gui library would be nice, but that is a lot harder. Still 20 years on the best cross gui library that compiles once and runs anywhere is Java...
- kbd 5y ago
  > Now you can focus on if err return err instead. Yes that is indeed the next most-frustrating thing about Go! In the last Go language survey (https://go.dev/blog/survey2020-results https://go.dev/blog/survey2020-results), about 90% of people wanted generics and 60% of people want better error handling. So, one down, one to go. Modern languages like Zig and Rust show how you can do "errors as values" way better. Zig has error returns and stack traces built in, there's no reason Go has to be so impoverished here.

I can not wait to never have to type interface{} again.

by kbd 5y ago

I can not wait to never have to type interface{} again.

Sad thing is that there is always a bunch of whining in any thread about 1.18 with people complaining about how much generics are going to ruin the language. I cannot wait for this release either, getting a proper set of data structures and concurrency libraries will be worth their weight in gold.

digianarchist 5y ago
Some things are just really painful to do in Go: merging maps, drilling into a JSON structure, checking if an element exist in a slice. Hopefully generics alleviates some of this boilerplate.
- skybrian 5y ago
  I haven't used Go in a while, but those don't sound particularly hard. Isn't searching for an element just a for loop?
  - erik_seaberg 5y ago
    Rereading the same loop more than once is not a good use of time. A generic function can be named and reused forever.
    - skybrian 5y ago
      When I was writing Go I used to write little helper functions named "findThingy" that just wrapped a single for loop. A typical module might have a few of them. It wasn't hard to read and it wasn't that big a deal. I think the boilerplate from error handling hurts readability more. It will be nice not to have to do that, though, if I get back to Go again.
akshayshah 5y ago
I'm particularly excited to have all the patterns from the slice tricks wiki page[0] shipped as a standalone package. (I'm not sure why the slices package doesn't include any of the good stuff...) Understanding those patterns requires internalizing the relationship between slices and arrays, which is important but too high of a bar for a simple, safe in-place filter. [0]: https://github.com/golang/go/wiki/SliceTricks#additional-tricks https://github.com/golang/go/wiki/SliceTricks#additional-tri...
- azth 5y ago
  What's quite sucky is that they will remain as standalone functions and not member functions, so you can't chain them (e.g. slice.Sort(...).Filter(...).Reduce(...))`. Not sure why golang is resistant to adding member functions to types.
  - EdSchouten 5y ago
    Why not just get a “pipe” operator added to the language instead? Many functional programming languages already have one. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/functions/#pipelines https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... No need to alter the type system of the language, while it’s clearly a syntactical improvement you’re looking for.
    - jen20 5y ago
      I (sadly) can't imagine that getting through the language modification process, somehow, though it certainly would solve this particular problem! If we're looking for things that Go could usefully take from functional languages I'd personally start with the much lower-hanging fruit of some guarantees about mutability of structures, though. (ps: Hi, Ed!)
  - erdeibit 5y ago
    My guess is that compilation time could be increased, which would let Go in the same boat as Rust or C++. I suspect every nice or must-have feature you add to a language, you must take the choice between deal with it in runtime or compilation time. Not adding features, no choice to take.
aaomidi 5y ago
To be fair, I am really excited for generics. However I do think the lack of the is the major reason go is such a readable language. Not being able to hide complexity behind types of types of types really ends up making code easier to follow. I'm excited and anxious about generics in go.
- lttlrck 5y ago
  Isn't interface{} similar to void * - the king of hiding types?
  - hellcow 5y ago
    Yes, but it's a bit like Rust's `unsafe` in that reaching for it first is not a great practice. There's usually a better way. Using interface{} where you truly don't know and can't predict the data being sent to you is mostly something that libraries (like encoding/json) have already handled, so I don't have to interact with it much directly. I think generics are going to have the biggest impact in adding effortless type safety to all kinds of libraries, though.
  - aaomidi 5y ago
    I really don't come across this in most projects I read and learn from.
- azth 5y ago
  Not sure golang is readable compared to other more expressive statically typed languages like Java and C#.
  - aaomidi 5y ago
    Definitely is for me and I used to only use Java for years. You can potentially test this for yourself by opening two large open source projects in each language and trying to figure out an issue from their issue tracker.
geodel 5y ago
> Sad thing is that there is always a bunch of whining in any thread about 1.18 with people complaining about how much generics are going to ruin the language. FWIW I think their complain even if not totally objective still have more weight as compared to non-users who say "I will use Go only when it has real generics/error handling/sum types/21st century features blah..blah.."
- tomjen3 5y ago
  That depends on what the goal of Golang is. If they are happy with their current level of success, then sure. If not, there are a lot more non Golang programmers out there than there are current Golang programmers.
- pjmlp 5y ago
  Sometimes there are tools that we have to use if we want to stay at current job, so it is nice when they actually update themselves into modern times, switching job everytime there is something we dislike isn't a viable long term career path.

deleted 5y ago

[deleted]

nick_ 5y ago

The resistance to adding generics to Go is a strong signal that the Go community has a serious problem.

cachvico 5y ago
Who's resisting?
randomdata 5y ago
He's talking about how Go 1.18 comes with a new "any" keyword, which is an alias to interface{}. Obviously there will still be uses for interface{}/any in your code, you just won't have to type interface{} anymore as you will be able to type any instead. This has nothing to do with generics.

tomjen3 5y ago

Now you can focus on if err return err instead. I wanted to like go for its crossplatformness, compile speed and relatively small memory usage while still being more practical than C++. But not having generics and having to constantly check for errors was the two big things that made me bail. Just to clarify, I don't want exceptions, I just want some language mechanism that changes err, value to be errOr<value>, which if passed to any function while an error will just propagage that to the return value of the function. Maybe for extra sugar something like errOr<value> | valueToUseIfError. This makes the code nice and thight, mean that I don't have to declare variables to give them one value to pass into the arguments of the next function and still perserve all the nice properties of Go. Also a nice cross gui library would be nice, but that is a lot harder. Still 20 years on the best cross gui library that compiles once and runs anywhere is Java...

kbd 5y ago
> Now you can focus on if err return err instead. Yes that is indeed the next most-frustrating thing about Go! In the last Go language survey (https://go.dev/blog/survey2020-results https://go.dev/blog/survey2020-results), about 90% of people wanted generics and 60% of people want better error handling. So, one down, one to go. Modern languages like Zig and Rust show how you can do "errors as values" way better. Zig has error returns and stack traces built in, there's no reason Go has to be so impoverished here.