9 ms·

I only have a small amount of Go experience but in my humble opinion I don't think the lack of features is due to lack of time or funding. In fact it would have

I only have a small amount of Go experience but in my humble opinion I don't think the lack of features is due to lack of time or funding. In fact it would have probably been much easier to say yes to a bunch of features than to continually deflect and reject the demand for those. I'm sure anyone working with different stakeholders recognises this effect. They have very deliberately tried to minimise the feature set in order to keep the language easy to learn. C++ is probably the canonical example of a language which hasn't kept the feature set tractable but I'd even argue that Python may have fallen into this trap in recent history.

asah 3y ago
Given AI assisted programming, I'm not sure how much any of this matters...
- sakjur 3y ago
  Complex language features have much more of a toll on reading code than they have on writing code. One example that I like to use is that while Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" is doing on this particular line, since it'll always behave according to the core language rules. I think the total cost of debugging hours often ends up being several magnitudes higher than the cost of development hours. At least for me, the process of debugging is something that involves scanning the code to load up my brain with as much possibly relevant context as I can and then try to analyze what parts of that might explain the seen behavior. A carefully designed language should help to both minimize the size of that context and the amount of linguistical gotchas that are part of it. If I'd use an AI assistant, that lets me ask more pointed questions. Wouldn't that improve the assistance the AI can provide?
  - VBprogrammer 3y ago
    > Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" It's funny, in 10 years of writing Python professionally I can only think of one occasion when I had to dig into what a __add__ operation did (a Money library which didn't special case 0 meaning sum didn't work as you might hope). I think it's probably because python has a pretty comprehensive standard library which gives reasonably consistent examples of where to use them.
  - merb 3y ago
    That is not necessarily true. Especially the error handling makes it really awkward to read go code. A lot of languages with an expressive type system do look aweful when looking at methods. But the same thing can be done with go methods. Writing hard to understand go code is just as easy as say with scala or rust
    - sakjur 3y ago
      Oh, absolutely. I don't mean to claim Go as an outstanding example of a well-designed programming language. I appreciate Go's language design, but I also similarly appreciate Scala, Rust, Java, Erlang and various other programming languages I've interacted with. My point is more against the notion that AI assistants would make careful language design any less important than in favor of any particular language. The popular programming languages all have their own virtues and drawbacks (and the unpopular ones almost certainly have at least their own drawbacks).
    - randomdata 3y ago
      > Especially the error handling makes it really awkward to read go code. Go does not have error handling at all, just general value handing. What do you find awkward about its value handlers? They are essentially the same as every other C-style language out there.
      - VBprogrammer 3y ago
        It's certainly not difficult to understand Go error handling. But it does take up quite a bit of real-estate. I think more importantly for me, it's too easy to forget an error check. Having primitives which make error checking painless and validated by the compiler would be nice.
        usrbinbash 3y ago
        > it's too easy to forget an error check. How? What exactly makes this "too easy"? In regards to a functions error returns, there are exactly two things a caller can do func foo() (int, error) { // foo code } // explicitely ignore the error foo() val, _ := foo() // handling the error val, err := foo() _, err := foo() If I do the latter, I cannot ignore `err`. If I do, the compiler yells at me because there is now an unused value in my code. If I do the former, then I made the conscious choice that the error doesn't matter to me. Yes, this goes for `foo()` as well, because Go makes it exceedingly clear that errors are just return values, and that call ignores all returns.
  - mejutoco 3y ago
    I think you will like this quote :) "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan I dont know if it applies to language features, though.
  - xigoi 3y ago
    > it means that you'll never have to dig deep to understand what "+" is doing on this particular line, Instead you'll have to dig deep to undershnnd what "Add()" is doing on this particular line. How is that any different?
    - thunky 3y ago
      Because parent is taking about operators like "+" and how it can be confusing not knowing if a function call is behind it. This is different from obvious functions like "Add()".
      - xigoi 3y ago
        How is “Add()” any different from “+”? They're just two different names for the same thing – a function that adds two numbers or other objects.
        usrbinbash 3y ago
        > They're just two different names for the same thing No, they are not. One is a function, the other is an operator. An operator has implicit meaning. I know with absolute certainty, that `+` is supposed to mean that 2 things are added to one another. `Add()` is a function. Its name may or may not indicate what it is actually doing. Even if it indicates it, it may not be obvious how it is doing it's thing, or how good the indication is. Example: If Add takes as first argument a list and as second argument an integer, does it append the integer to the list? Does it add it to every element of the list? Does it sum the list and add the integer to the result? All these things could be meant by "Add"-ing an integer to the list. Does it have side effects? I don't know, and I don't expect to know, until I look at `Add()` (or at least read it's documentation). That is the big difference between operators and functions; With operators, I expect to know what it does, without looking it up. And that's also the big problem with operator-overloading, because as soon as a language supports that, that assumption flies out the window.
        thunky 3y ago
        Because if the language doesn't allow overloading (which is the context of this thread) then "+" will always be implemented by the language. That's a big difference.
- speed_spread 3y ago
  A line of code is written once but read ten times. AI making it cheap to write will only increase the maintenance burden. And if you need AI to maintain AI written code, you'll have gained nothing but a new dependency in your toolbox.
  - bananapub 3y ago
    > A line of code is written once but read ten times really? source? My counter-assertion is that I'd guess most code is basically never read - most of it is in ad-hoc PHP CMSes or VBA scripts.
    - speed_spread 3y ago
      My assumption about something coded in Go is that it was expected to be persistent and actively maintained. I agree that AI is good for one-off scripting purposes.
- bayindirh 3y ago
  If you can’t design your program in your head, and can’t trace the code by reading it, neither the compiler nor AI (i.e.: code derived from other people’s code) won’t help you. I like Go in that regard. You can keep the whole feature set in your head, and read/simulate the code without getting confused, and I’m telling this as a C++ fan.
- asah 3y ago
  The downvoting is so cute. Given the pace of AI development, y'all really think we're going to be typing individual lines of code in languages like golang? Seriously? Come on HN, you're better than this.
  - usrbinbash 3y ago
    Yes, I do expect that, and I will continue to do so, unless someone can show me a breakthrough in language modeling, that isn't just a big-data derived stochastic parrot. Being able to write code because I have seen lots of it, and know what code is supposed to look like, and being able to write code because I understand what code does, and what it does in context, are 2 completely different things.
mseepgood 3y ago
> They have very deliberately tried to minimise the feature set I thought this was common knowledge. They made whole conference talks about it.
- teodorlu 3y ago
  Might I ask for a link? I searched around, but didn't find anything. Perhaps the title is something different than "go minimal feature set".
  - Gys 3y ago
    For example https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM
- vram22 3y ago
  Yes, and Rob Pike has a post about it on his blog, command-central.com, IIRC.

asah 3y ago

Given AI assisted programming, I'm not sure how much any of this matters...

sakjur 3y ago
Complex language features have much more of a toll on reading code than they have on writing code. One example that I like to use is that while Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" is doing on this particular line, since it'll always behave according to the core language rules. I think the total cost of debugging hours often ends up being several magnitudes higher than the cost of development hours. At least for me, the process of debugging is something that involves scanning the code to load up my brain with as much possibly relevant context as I can and then try to analyze what parts of that might explain the seen behavior. A carefully designed language should help to both minimize the size of that context and the amount of linguistical gotchas that are part of it. If I'd use an AI assistant, that lets me ask more pointed questions. Wouldn't that improve the assistance the AI can provide?
- VBprogrammer 3y ago
  > Go's lack of operator overloading is occasionally a nuisance, it means that you'll never have to dig deep to understand what "+" It's funny, in 10 years of writing Python professionally I can only think of one occasion when I had to dig into what a __add__ operation did (a Money library which didn't special case 0 meaning sum didn't work as you might hope). I think it's probably because python has a pretty comprehensive standard library which gives reasonably consistent examples of where to use them.
- merb 3y ago
  That is not necessarily true. Especially the error handling makes it really awkward to read go code. A lot of languages with an expressive type system do look aweful when looking at methods. But the same thing can be done with go methods. Writing hard to understand go code is just as easy as say with scala or rust
  - sakjur 3y ago
    Oh, absolutely. I don't mean to claim Go as an outstanding example of a well-designed programming language. I appreciate Go's language design, but I also similarly appreciate Scala, Rust, Java, Erlang and various other programming languages I've interacted with. My point is more against the notion that AI assistants would make careful language design any less important than in favor of any particular language. The popular programming languages all have their own virtues and drawbacks (and the unpopular ones almost certainly have at least their own drawbacks).
  - randomdata 3y ago
    > Especially the error handling makes it really awkward to read go code. Go does not have error handling at all, just general value handing. What do you find awkward about its value handlers? They are essentially the same as every other C-style language out there.
    - VBprogrammer 3y ago
      It's certainly not difficult to understand Go error handling. But it does take up quite a bit of real-estate. I think more importantly for me, it's too easy to forget an error check. Having primitives which make error checking painless and validated by the compiler would be nice.
      - usrbinbash 3y ago
        > it's too easy to forget an error check. How? What exactly makes this "too easy"? In regards to a functions error returns, there are exactly two things a caller can do func foo() (int, error) { // foo code } // explicitely ignore the error foo() val, _ := foo() // handling the error val, err := foo() _, err := foo() If I do the latter, I cannot ignore `err`. If I do, the compiler yells at me because there is now an unused value in my code. If I do the former, then I made the conscious choice that the error doesn't matter to me. Yes, this goes for `foo()` as well, because Go makes it exceedingly clear that errors are just return values, and that call ignores all returns.
- mejutoco 3y ago
  I think you will like this quote :) "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan I dont know if it applies to language features, though.
- xigoi 3y ago
  > it means that you'll never have to dig deep to understand what "+" is doing on this particular line, Instead you'll have to dig deep to undershnnd what "Add()" is doing on this particular line. How is that any different?
  - thunky 3y ago
    Because parent is taking about operators like "+" and how it can be confusing not knowing if a function call is behind it. This is different from obvious functions like "Add()".
    - xigoi 3y ago
      How is “Add()” any different from “+”? They're just two different names for the same thing – a function that adds two numbers or other objects.
      - usrbinbash 3y ago
        > They're just two different names for the same thing No, they are not. One is a function, the other is an operator. An operator has implicit meaning. I know with absolute certainty, that `+` is supposed to mean that 2 things are added to one another. `Add()` is a function. Its name may or may not indicate what it is actually doing. Even if it indicates it, it may not be obvious how it is doing it's thing, or how good the indication is. Example: If Add takes as first argument a list and as second argument an integer, does it append the integer to the list? Does it add it to every element of the list? Does it sum the list and add the integer to the result? All these things could be meant by "Add"-ing an integer to the list. Does it have side effects? I don't know, and I don't expect to know, until I look at `Add()` (or at least read it's documentation). That is the big difference between operators and functions; With operators, I expect to know what it does, without looking it up. And that's also the big problem with operator-overloading, because as soon as a language supports that, that assumption flies out the window.
      - thunky 3y ago
        Because if the language doesn't allow overloading (which is the context of this thread) then "+" will always be implemented by the language. That's a big difference.
speed_spread 3y ago
A line of code is written once but read ten times. AI making it cheap to write will only increase the maintenance burden. And if you need AI to maintain AI written code, you'll have gained nothing but a new dependency in your toolbox.
- bananapub 3y ago
  > A line of code is written once but read ten times really? source? My counter-assertion is that I'd guess most code is basically never read - most of it is in ad-hoc PHP CMSes or VBA scripts.
  - speed_spread 3y ago
    My assumption about something coded in Go is that it was expected to be persistent and actively maintained. I agree that AI is good for one-off scripting purposes.
bayindirh 3y ago
If you can’t design your program in your head, and can’t trace the code by reading it, neither the compiler nor AI (i.e.: code derived from other people’s code) won’t help you. I like Go in that regard. You can keep the whole feature set in your head, and read/simulate the code without getting confused, and I’m telling this as a C++ fan.
asah 3y ago
The downvoting is so cute. Given the pace of AI development, y'all really think we're going to be typing individual lines of code in languages like golang? Seriously? Come on HN, you're better than this.
- usrbinbash 3y ago
  Yes, I do expect that, and I will continue to do so, unless someone can show me a breakthrough in language modeling, that isn't just a big-data derived stochastic parrot. Being able to write code because I have seen lots of it, and know what code is supposed to look like, and being able to write code because I understand what code does, and what it does in context, are 2 completely different things.

mseepgood 3y ago

> They have very deliberately tried to minimise the feature set I thought this was common knowledge. They made whole conference talks about it.

teodorlu 3y ago
Might I ask for a link? I searched around, but didn't find anything. Perhaps the title is something different than "go minimal feature set".
- Gys 3y ago
  For example https://www.youtube.com/watch?v=rFejpH_tAHM https://www.youtube.com/watch?v=rFejpH_tAHM
vram22 3y ago
Yes, and Rob Pike has a post about it on his blog, command-central.com, IIRC.