9 ms·

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of

by hbn 5y ago

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos. An empty interface can represent any type because every type inherently implements an interface with no methods. And that's what Go is all about -- implicitly implementing interfaces. If a newbie hops into Go and just starts using "any" I think they might assume it's a magic type that's at the base of everything, missing out on the fact that they're still taking advantage of interfaces.

egeozcan 5y ago
I kind of understand what you mean, as it's similar to what happened with prototypes and the late-comer class syntax in JavaScript, and in that case, it was a net positive change as most would probably say. Let's see how this plays out.
pawelmurias 5y ago
A language shouldnt be optimized towards doc avoiding newbies at the cost of making things verbose and ugly.
- jshen 5y ago
  Go is the most readable language I’ve used in terms of understanding other peoples complex code bases, and I’ve been doing this a long time and have used a lot of languages. Edit: It’s also one of the most approachable languages.
  - valenterry 5y ago
    Why don't you list the languages that you have used? Otherwise there isn't really any new information. For example for, having done Java, Scala, Python, Groovy, Haskell, Typescript and a couple others, Go reads extremely horrible. It feels as bad as enterprisey Java to me.
    - jshen 5y ago
      I’ve used all those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.
      - valenterry 5y ago
        It's far easier for you. It definitely isn't for me or in general. Thank you for answering the list of languages though. Makes me wonder what the concrete points are for, since I really have a different opinion. Maybe our minds just work very different; :)
        jshen 5y ago
        Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }); for (index = 0; index < choices.length; index++) { Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }
        valenterry 5y ago
        Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all at once without delay. This will be much faster compared to the code you posted, which will wait after each request, even though the rate-limit is not applied. Apart from that, I don't think the second example is complete, where does ce come from here? And also, I don't know Deno, but calling "sleepSync" already looks like a bad idea to me, no matter where it's used - especially since calling a sync operation within an async doesn't make much sense.
  - 3a2d29 5y ago
    Surely Python gets that honor over Go. As much as I like Go, Rust, C, over Python, I would never say the reason is readability.
    - eru 5y ago
      Python is quite readable for short snippets. It can be quite a mess for larger systems. That combination of trade-offs makes it a great language to solve interview style problems in on a white board. You can alleviate those larger scale problems in Python a bit with good IDE support, embracing type annotations, and going with a style that prefers immutability over action-at-a-distance.
  - pawelmurias 5y ago
    This change is intended to be used to avoid using interface{} with generics which aren't used by existing code
- joebob42 5y ago
  I agree, and I think this mistake is at the root of most of what are (at least to my biased point of view) the big mistakes made by go. Syntactical niceties and simplicity / obviousness are sometimes a tradeoff, but go 1.0 felt like the designers just folded their arms and refused to consider any niceness. I still don't understand why anyone would use go when there are so many better choices, but at least they're fixing some stuff now :)
benhoyt 5y ago
Counterpoint: I'm an experienced Go dev but still think of "interface{}" as a semi-special "any" type, just because it fits my brain better conceptually. "Any type" is simpler than "an interface with an empty method set, which is of course matched by any type". I think this is a win.
valenterry 5y ago
> I thought that using an empty interface to represent "any type" was kind of ingenious It makes me a bit sad to read that. We all are on a journey to be become better developers every day. But things like that are like a distraction. They make you think you found a really cool and smart concept, but you actually didn't and it's essentially just a hack. Not sure what the solution can be. But PL designers should be more clear about features that are just "hacks" and considered "bad" but necessary in practice due to certain constraints. Go's {} and nil-errorhandling are examples. Nulls (in any language) are another common example.
- Lhiw 5y ago
  Nulls aren't a hack they're the not yet set state. The problem is that languages don't create both nullable and non nullable types. Forcing everything to use options which infect everything with guarding at every layer of the stack is just as bad as nullable types. That is, nullable types aren't the problem, never was, the problem is developers not dereferencing them at the edges of code boundaries and using non nullable types internally. E.g. in rust, the first point you encounter an option type should be the point you handle the optionality of it and deref into a standard type with the value. From then on, your code is so much freeer.
- laumars 5y ago
  That’s a very condescending way of say “I don’t personally like this feature”.
- the-alt-one 5y ago
  It's not a hack, it's the natural way of expressing it in the chosen type system. The use cases for interface{} are often hacks, because of a lack of parametric polymorphism, but that's different.
Waterluvian 5y ago
This is valuable for a learning language and for learning in general. But it’s the kind of concept that ought to be abstracted away, in my opinion.
eru 5y ago
> It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Having lots of syntactic sugar works out OK for Haskell. For example, in Haskell straight-line imperative looking code is an alias for some underlying callback hell.
chmod775 5y ago
> Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious There's a few other languages out there that work that way. The split is probably is probably 20/80. Though "popular" languages heavily learn towards Java-esque interfaces - with TypeScript and Go being the odd ones in that bunch.
nightowl_games 5y ago
I'm an experienced programmer whos just learning go now and I never made the connection that interface{} meant 'an interface with no methods'. I've always thought 'interface{}' was the clearest wart on the language. Languages shouldn't be about teaching me things, they are just a tool. Keyboard input goes in, computer instructions come out. any is easier to read, more intuitive in its meaning and takes less keyboard input.

by hbn 5y ago

egeozcan 5y ago

I kind of understand what you mean, as it's similar to what happened with prototypes and the late-comer class syntax in JavaScript, and in that case, it was a net positive change as most would probably say. Let's see how this plays out.

pawelmurias 5y ago

A language shouldnt be optimized towards doc avoiding newbies at the cost of making things verbose and ugly.

jshen 5y ago
Go is the most readable language I’ve used in terms of understanding other peoples complex code bases, and I’ve been doing this a long time and have used a lot of languages. Edit: It’s also one of the most approachable languages.
- valenterry 5y ago
  Why don't you list the languages that you have used? Otherwise there isn't really any new information. For example for, having done Java, Scala, Python, Groovy, Haskell, Typescript and a couple others, Go reads extremely horrible. It feels as bad as enterprisey Java to me.
  - jshen 5y ago
    I’ve used all those languages. It’s far easier to make sense of a non trivial go code base I’ve never seen before than any of those.
    - valenterry 5y ago
      It's far easier for you. It definitely isn't for me or in general. Thank you for answering the list of languages though. Makes me wonder what the concrete points are for, since I really have a different opinion. Maybe our minds just work very different; :)
      - jshen 5y ago
        Just ran into a great example today. Was using typescript/javascript to hit an api that has a limit of 5 requests per second. One of these fails saying that it's making more than 5 requests per second, the other doesn't, is it obvious why? It took me several hours to figure it out, wouldn't have had this problem in go. choices.forEach(async (ce) => { let ce = choices[index] Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }); for (index = 0; index < choices.length; index++) { Deno.sleepSync(220); let cf = await getChoice(ce); // this makes the API call Deno.sleepSync(220); }
        valenterry 5y ago
        Good example, because that's exactly what I don't want to see when I read code. This should really be: streamOf(choices) .mapAsync(ce => getChoice(ce)) .throttle(5, 1.second) This is such a common use-case, it should really be in the streaming-library of choice. It's also a good example of how more abstract code is often better and has less edge-cases. In this example, of you have 4 choices, then these can send all at once without delay. This will be much faster compared to the code you posted, which will wait after each request, even though the rate-limit is not applied. Apart from that, I don't think the second example is complete, where does ce come from here? And also, I don't know Deno, but calling "sleepSync" already looks like a bad idea to me, no matter where it's used - especially since calling a sync operation within an async doesn't make much sense.
- 3a2d29 5y ago
  Surely Python gets that honor over Go. As much as I like Go, Rust, C, over Python, I would never say the reason is readability.
  - eru 5y ago
    Python is quite readable for short snippets. It can be quite a mess for larger systems. That combination of trade-offs makes it a great language to solve interview style problems in on a white board. You can alleviate those larger scale problems in Python a bit with good IDE support, embracing type annotations, and going with a style that prefers immutability over action-at-a-distance.
- pawelmurias 5y ago
  This change is intended to be used to avoid using interface{} with generics which aren't used by existing code
joebob42 5y ago
I agree, and I think this mistake is at the root of most of what are (at least to my biased point of view) the big mistakes made by go. Syntactical niceties and simplicity / obviousness are sometimes a tradeoff, but go 1.0 felt like the designers just folded their arms and refused to consider any niceness. I still don't understand why anyone would use go when there are so many better choices, but at least they're fixing some stuff now :)

benhoyt 5y ago

Counterpoint: I'm an experienced Go dev but still think of "interface{}" as a semi-special "any" type, just because it fits my brain better conceptually. "Any type" is simpler than "an interface with an empty method set, which is of course matched by any type". I think this is a win.

valenterry 5y ago

> I thought that using an empty interface to represent "any type" was kind of ingenious It makes me a bit sad to read that. We all are on a journey to be become better developers every day. But things like that are like a distraction. They make you think you found a really cool and smart concept, but you actually didn't and it's essentially just a hack. Not sure what the solution can be. But PL designers should be more clear about features that are just "hacks" and considered "bad" but necessary in practice due to certain constraints. Go's {} and nil-errorhandling are examples. Nulls (in any language) are another common example.

Lhiw 5y ago
Nulls aren't a hack they're the not yet set state. The problem is that languages don't create both nullable and non nullable types. Forcing everything to use options which infect everything with guarding at every layer of the stack is just as bad as nullable types. That is, nullable types aren't the problem, never was, the problem is developers not dereferencing them at the edges of code boundaries and using non nullable types internally. E.g. in rust, the first point you encounter an option type should be the point you handle the optionality of it and deref into a standard type with the value. From then on, your code is so much freeer.
laumars 5y ago
That’s a very condescending way of say “I don’t personally like this feature”.
the-alt-one 5y ago
It's not a hack, it's the natural way of expressing it in the chosen type system. The use cases for interface{} are often hacks, because of a lack of parametric polymorphism, but that's different.

Waterluvian 5y ago

This is valuable for a learning language and for learning in general. But it’s the kind of concept that ought to be abstracted away, in my opinion.

eru 5y ago

> It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Having lots of syntactic sugar works out OK for Haskell. For example, in Haskell straight-line imperative looking code is an alias for some underlying callback hell.

chmod775 5y ago

> Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious There's a few other languages out there that work that way. The split is probably is probably 20/80. Though "popular" languages heavily learn towards Java-esque interfaces - with TypeScript and Go being the odd ones in that bunch.

nightowl_games 5y ago

I'm an experienced programmer whos just learning go now and I never made the connection that interface{} meant 'an interface with no methods'. I've always thought 'interface{}' was the clearest wart on the language. Languages shouldn't be about teaching me things, they are just a tool. Keyboard input goes in, computer instructions come out. any is easier to read, more intuitive in its meaning and takes less keyboard input.