6 ms·

Author here. This thread made my day. To the people who have commented, thank you. I seldom get to interact with SE people who enjoy their craft, and to see t

Author here. This thread made my day. To the people who have commented, thank you. I seldom get to interact with SE people who enjoy their craft, and to see that so many have not only read my post but spent time writing out (dis)agreements brings a smile to my face. Some people have pointed out some historical inaccuracies, to which I'm grateful. Most of these points are taken from random sources I've consumed over the years, including for instance the two-week-turnaround, which was a hand-wavy quote from Brooks (video interview) for which I don't remember the source. Using it was for effect, perhaps a bit too eager on my part. I'm new to writing, and by extension, putting my thoughts to paper. This blog entry was written to concretize my thoughts on this subject, as I've found that writing them down helps to clarify them a lot, and to practice my English (non-native speaker). On the subject of minimalism: I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today, and what was standard then is outdated (or even deprecated) now. Throw in some IDEs, frameworks, licenses etc. and the amount of man-hours lost to auxiliary ad-hoc work has been both draining and expensive (for our customers). Switching several projects to Go mitigated this almost immediately, where the return of investment combined with the novelty factor has lifted the spirits of not only me but the people I've worked with. Going back is (for me) out of the question, at least for the time being. Happy to see people sharing their thoughts on this. Cheers :)

dmitriid 5y ago
> I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today Java, C# and Javascript are obsessive about backwards compatibility (one of the reasons Java's changes to the language are moving so slow). There's nothing magical about Wirth's languages or Go. What worked two years ago will be broken today, and the language has very little to do with it. > Switching several projects to Go mitigated this almost immediately As in: you haven't run into things that are broken yet.
- fredrikholm 5y ago
  > Java, C# and Javascript are obsessive about backwards compatibility This might be true for Java, but this has not been my experience for the other two. NET especially. Incrementally migrating from 4.6.* to CORE3 has been challenging, even when we've had external (expert) .NET consultants to help us. > There's nothing magical about Wirth's languages or Go. I don't think so either! On the contrary, they're everything but magical. > What worked two years ago will be broken today, and the language has very little to do with it. Almost on the dot two years since those rewrites happened and nothing (to my knowledge) has broken. On the contrary, looking at code examples and best practices from 2011 look exactly the same. Writing Swift, anything older than 2019 made me sweat. > As in: you haven't run into things that are broken yet. Longest record so far! :)
  - dmitriid 5y ago
    > Almost on the dot two years since those rewrites happened and nothing (to my knowledge) has broken. We have code in Java that's been running non-stop for two years. Undoubtedly we have .net code that's been running just as long. However, it's possible that switching from .net to .net core incurs costs because they are quite separate projects. We'v been running on .net core. > Writing Swift Yes, Swift is an entirely different story, and it's... a weird story to say the least. > Longest record so far! You haven't lived through switching to the new modules structure then :) That's quite a big breaking change (and poorly executed in my opinion).
    - deleted 5y ago
      [deleted]
    - hamburglar 5y ago
      > You haven't lived through switching to the new modules structure then :) That's quite a big breaking change (and poorly executed in my opinion) Ugh. I was on the other side of this argument until you brought this out. It’s a great point. The actual language is very good at compatibility but the dependency management did go through a big painful change that some internal code bases I work with but do not own still haven’t worked up the motivation to deal with.
_wldu 5y ago
I really appreciated the article. I feel the same way about Go as you do. No other programming language has made me feel this way. It's the most practical programming language I have used over the last 40 years.
- pa7ch 5y ago
  Agreed! Go has made a big difference for me personally, its simplicity and tooling design makes it easier for me to actually get wrapped up in in programming a solution instead if being paralyzed by the design and starting phase. Much respect for polyglot programmers and using the right tool for the job, but go personally clicks best for me. I prefer to focus on gaining a deeper understanding of writing effective and maintainable go for a variety of projects. So using go as my main language is actually really important for me. I'm thankful its possible to require that these days.
- publicola1990 5y ago
  How does Rust compare in that regard? Will 3 year old non-trivial rust code build/run without issues?
  - stouset 5y ago
    Yes, Rust releases have (arguably) kept better backwards compatibility than Go releases have. There have been IIRC a few Go releases that broke code in practice despite it being considered a non-breaking change.

dmitriid 5y ago

> I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today Java, C# and Javascript are obsessive about backwards compatibility (one of the reasons Java's changes to the language are moving so slow). There's nothing magical about Wirth's languages or Go. What worked two years ago will be broken today, and the language has very little to do with it. > Switching several projects to Go mitigated this almost immediately As in: you haven't run into things that are broken yet.

fredrikholm 5y ago
> Java, C# and Javascript are obsessive about backwards compatibility This might be true for Java, but this has not been my experience for the other two. NET especially. Incrementally migrating from 4.6.* to CORE3 has been challenging, even when we've had external (expert) .NET consultants to help us. > There's nothing magical about Wirth's languages or Go. I don't think so either! On the contrary, they're everything but magical. > What worked two years ago will be broken today, and the language has very little to do with it. Almost on the dot two years since those rewrites happened and nothing (to my knowledge) has broken. On the contrary, looking at code examples and best practices from 2011 look exactly the same. Writing Swift, anything older than 2019 made me sweat. > As in: you haven't run into things that are broken yet. Longest record so far! :)
- dmitriid 5y ago
  > Almost on the dot two years since those rewrites happened and nothing (to my knowledge) has broken. We have code in Java that's been running non-stop for two years. Undoubtedly we have .net code that's been running just as long. However, it's possible that switching from .net to .net core incurs costs because they are quite separate projects. We'v been running on .net core. > Writing Swift Yes, Swift is an entirely different story, and it's... a weird story to say the least. > Longest record so far! You haven't lived through switching to the new modules structure then :) That's quite a big breaking change (and poorly executed in my opinion).
  - deleted 5y ago
    [deleted]
  - hamburglar 5y ago
    > You haven't lived through switching to the new modules structure then :) That's quite a big breaking change (and poorly executed in my opinion) Ugh. I was on the other side of this argument until you brought this out. It’s a great point. The actual language is very good at compatibility but the dependency management did go through a big painful change that some internal code bases I work with but do not own still haven’t worked up the motivation to deal with.

_wldu 5y ago

I really appreciated the article. I feel the same way about Go as you do. No other programming language has made me feel this way. It's the most practical programming language I have used over the last 40 years.

pa7ch 5y ago
Agreed! Go has made a big difference for me personally, its simplicity and tooling design makes it easier for me to actually get wrapped up in in programming a solution instead if being paralyzed by the design and starting phase. Much respect for polyglot programmers and using the right tool for the job, but go personally clicks best for me. I prefer to focus on gaining a deeper understanding of writing effective and maintainable go for a variety of projects. So using go as my main language is actually really important for me. I'm thankful its possible to require that these days.
publicola1990 5y ago
How does Rust compare in that regard? Will 3 year old non-trivial rust code build/run without issues?
- stouset 5y ago
  Yes, Rust releases have (arguably) kept better backwards compatibility than Go releases have. There have been IIRC a few Go releases that broke code in practice despite it being considered a non-breaking change.