3 ms·

> you can't enforce that breaking changes aren't put in 1.4.3 Eh ... why? In some languages, it's standard to run source/binary compatibility checks against ne

> you can't enforce that breaking changes aren't put in 1.4.3 Eh ... why? In some languages, it's standard to run source/binary compatibility checks against new versions and fail a build if the new version doesn't satisfy the requirements.

NateDad 12y ago
With decent static analysis you could check that the signatures of all types and functions are identical or compatible, I suppose, but checking that the functionality is compatible in any kind of generic way is impossible. The former is necessary, but not sufficient.
- frowaway001 12y ago
  > With decent static analysis you could check that the signatures of all types and functions are identical or compatible, I suppose "I suppose"? This has been done for years already. There are even GUIs for that (so that people don't have to use the CLI) which tell you "between 1.2.3 and 1.2.4 you did the following: ... This will break compatibility in the following cases: ..." So it's better to not even try? Additionally, for many changes it is reasonable and possible to check whether behavior has changed. Not every function has an unlimited number of inputs and outputs. That's one of the biggest reasons I avoid Go and PHP: It's not only that the developers ignore existing solutions if they haven't "invented" them themselves, but that they don't even care about improving things where no "perfect" solution is available. Ignorance and arrogance is a combination which doesn't make me trust them, and products based on their software. (OwnCloud, Docker, ...)
  - NateDad 12y ago
    I'm not saying "don't write a tool that does this". Sure, having an API diff tool for my code would be awesome. And it's possible someone has already written such a thing for Go. If not, someone definitely should. The problem I have is when other developers say "How can anyone possibly live without this?!" People have been living without X or Y feature some other language / toolchain has for a long time, and doing pretty ok. That doesn't mean we don't want that feature, just that we don't think it's the end of the world if we don't have it. Everyone seems to have their own pet "I can't live without this" thing. The thing is, when you've been coding for a long time, you start to realize that you can live without pretty much any feature. It may make some parts of your job harder, but unless we're talking about dropping down to assembly, I can deal with pretty much any language.
    - frowaway001 12y ago
      Well, let's just agree that there is some kind of selection bias in the Go community. Go developers seem to be emphatically content with not using the best tool for the job. That makes sense, otherwise those developers wouldn't have ended up with Go in the first place. For me it's not a question about "I can live without X?", but "why would I want to live without X?". I want the best tools to solve a job. Not some of the best tools. _All_ of them.
      - jbooth 12y ago
        I'm gonna just throw it out there for you: You Do Not Get It when it comes to Go. Internalize that. Nobody, fucking nobody ever, has said "this tool sucks, I think I'll use it exclusively from now on". They're seeing something that you are not seeing, most likely an appreciation of simplicity.
        frowaway001 12y ago
        > Nobody, fucking nobody ever, has said "this tool sucks, I think I'll use it exclusively from now on". You obviously don't read the Golang mailing list ... :-)
        jbooth 12y ago
        You read the golang mailing list? In addition to showing up on every HN and probably proggit thread about Go? How much time have you spent actually programming?

NateDad 12y ago

With decent static analysis you could check that the signatures of all types and functions are identical or compatible, I suppose, but checking that the functionality is compatible in any kind of generic way is impossible. The former is necessary, but not sufficient.

frowaway001 12y ago
> With decent static analysis you could check that the signatures of all types and functions are identical or compatible, I suppose "I suppose"? This has been done for years already. There are even GUIs for that (so that people don't have to use the CLI) which tell you "between 1.2.3 and 1.2.4 you did the following: ... This will break compatibility in the following cases: ..." So it's better to not even try? Additionally, for many changes it is reasonable and possible to check whether behavior has changed. Not every function has an unlimited number of inputs and outputs. That's one of the biggest reasons I avoid Go and PHP: It's not only that the developers ignore existing solutions if they haven't "invented" them themselves, but that they don't even care about improving things where no "perfect" solution is available. Ignorance and arrogance is a combination which doesn't make me trust them, and products based on their software. (OwnCloud, Docker, ...)
- NateDad 12y ago
  I'm not saying "don't write a tool that does this". Sure, having an API diff tool for my code would be awesome. And it's possible someone has already written such a thing for Go. If not, someone definitely should. The problem I have is when other developers say "How can anyone possibly live without this?!" People have been living without X or Y feature some other language / toolchain has for a long time, and doing pretty ok. That doesn't mean we don't want that feature, just that we don't think it's the end of the world if we don't have it. Everyone seems to have their own pet "I can't live without this" thing. The thing is, when you've been coding for a long time, you start to realize that you can live without pretty much any feature. It may make some parts of your job harder, but unless we're talking about dropping down to assembly, I can deal with pretty much any language.
  - frowaway001 12y ago
    Well, let's just agree that there is some kind of selection bias in the Go community. Go developers seem to be emphatically content with not using the best tool for the job. That makes sense, otherwise those developers wouldn't have ended up with Go in the first place. For me it's not a question about "I can live without X?", but "why would I want to live without X?". I want the best tools to solve a job. Not some of the best tools. _All_ of them.
    - jbooth 12y ago
      I'm gonna just throw it out there for you: You Do Not Get It when it comes to Go. Internalize that. Nobody, fucking nobody ever, has said "this tool sucks, I think I'll use it exclusively from now on". They're seeing something that you are not seeing, most likely an appreciation of simplicity.
      - frowaway001 12y ago
        > Nobody, fucking nobody ever, has said "this tool sucks, I think I'll use it exclusively from now on". You obviously don't read the Golang mailing list ... :-)
        jbooth 12y ago
        You read the golang mailing list? In addition to showing up on every HN and probably proggit thread about Go? How much time have you spent actually programming?