4 ms·

I think the go language has taken a position along the lines of "re usability and abstraction are overrated". I certainly think there is some truth to that, I a

I think the go language has taken a position along the lines of "re usability and abstraction are overrated". I certainly think there is some truth to that, I am really enjoying working with go on smaller projects and it is this philosophy that has made understanding the code much easier. But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code?

jrs95 10y ago
Well, it'd definitely be easier to change than something that had the wrong abstractions.
NateDad 10y ago
functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods. I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.
- 2_listerine_pls 10y ago
  Yeah, I guess some need to review the definition of abstraction.
  - sbov 10y ago
    Sometimes I feel like the OO world has redefined abstraction to only mean an interface.
    - pjmlp 10y ago
      It was already known in the 90's as component based programming. https://en.wikipedia.org/wiki/Component-based_software_engineering https://en.wikipedia.org/wiki/Component-based_software_engin... https://www.amazon.com/Component-Software-Object-Oriented-Programming-Szyperski/dp/B011DCDV40/ref=sr_1_6?ie=UTF8&qid=1490373711&sr=8-6&keywords=component+software+beyond+object-oriented+programming https://www.amazon.com/Component-Software-Object-Oriented-Pr...
- kuschku 10y ago
  And go can not write abstract functions and methods. I can not write a function dealing with arbitrary values. Somethind I’d do in Java with public static <T extends IIncrementable> T increment(T val) { val.increment(); return val; } is impossible to do in Go. You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times, once for every type. Fixing bugs became a nightmare.
  - deleted 10y ago
    [deleted]
  - jy3 10y ago
    > I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times Who would have thought. Maybe a rewrite would have been more appropriate.
    - kuschku 10y ago
      Porting meant rewriting here. But I still ended up with the same classes replicated hundreds of times. Polymorphic code is not possible in any other way in go – you always have to duplicate the code.
      - jy3 10y ago
        I'm sorry it went badly then. Your example intrigues me, isn't an interface enough? Is what bother you that the return value won't be typed T but IIncrementable in go?
        kuschku 10y ago
        Yes, exactly. This is an actual issue. My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts. So, the library now gets these functions, and does all the filtering on other threads. So either I have to replicate the entire async code for every type, or I can’t keep type safety.
weberc2 10y ago
> But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code? Doesn't this article speak to this? It mentions juju has over a million lines.
- goatlover 10y ago
  Yeah, but there is no comparison to the same project done in Lisp, Haskell, Java, etc. All the author is doing is relating their success using Go, which is great, but there is no comparison to how it would have fared in another language, except his previous frustrations with C#, on other projects, I guess.
  - weberc2 10y ago
    It would be ridiculous to expect Canonical (and even moreso, the author alone) to rewrite juju in another language as a simple comparison. Even if it were feasible, the comparison would be polluted by the experience gained by building the application initially (or you could rebuild with a completely new team of developers, but then you're introducing a whole new set of variables). The best we can reasonably do is compare applications aggregating on language.
  - sciurus 10y ago
    Juju was originally written in Python. They ported it to Go 4 years ago. https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/jLnMsUbYwrQ https://groups.google.com/forum/?fromgroups=#!topic/golang-n...
NateDad 10y ago
To actually answer the question - yes it holds true, yes it scales (in my experience). There are a lot of abstractions that we built for Juju. And we absolutely tried to ensure there was only a single source of truth for everything. It would have been totally unworkable if we couldn't reuse logic etc. We may not always have chosen the best abstraction, but that's a problem in any language.

jrs95 10y ago

Well, it'd definitely be easier to change than something that had the wrong abstractions.

NateDad 10y ago

functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods. I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

2_listerine_pls 10y ago
Yeah, I guess some need to review the definition of abstraction.
- sbov 10y ago
  Sometimes I feel like the OO world has redefined abstraction to only mean an interface.
  - pjmlp 10y ago
    It was already known in the 90's as component based programming. https://en.wikipedia.org/wiki/Component-based_software_engineering https://en.wikipedia.org/wiki/Component-based_software_engin... https://www.amazon.com/Component-Software-Object-Oriented-Programming-Szyperski/dp/B011DCDV40/ref=sr_1_6?ie=UTF8&qid=1490373711&sr=8-6&keywords=component+software+beyond+object-oriented+programming https://www.amazon.com/Component-Software-Object-Oriented-Pr...
kuschku 10y ago
And go can not write abstract functions and methods. I can not write a function dealing with arbitrary values. Somethind I’d do in Java with public static <T extends IIncrementable> T increment(T val) { val.increment(); return val; } is impossible to do in Go. You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times, once for every type. Fixing bugs became a nightmare.
- deleted 10y ago
  [deleted]
- jy3 10y ago
  > I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times Who would have thought. Maybe a rewrite would have been more appropriate.
  - kuschku 10y ago
    Porting meant rewriting here. But I still ended up with the same classes replicated hundreds of times. Polymorphic code is not possible in any other way in go – you always have to duplicate the code.
    - jy3 10y ago
      I'm sorry it went badly then. Your example intrigues me, isn't an interface enough? Is what bother you that the return value won't be typed T but IIncrementable in go?
      - kuschku 10y ago
        Yes, exactly. This is an actual issue. My system is usually designed that I provide a function that generates a value of type T, a function to filter T (T -> boolean), and a way to display Ts. So, the library now gets these functions, and does all the filtering on other threads. So either I have to replicate the entire async code for every type, or I can’t keep type safety.

weberc2 10y ago

> But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code? Doesn't this article speak to this? It mentions juju has over a million lines.

goatlover 10y ago
Yeah, but there is no comparison to the same project done in Lisp, Haskell, Java, etc. All the author is doing is relating their success using Go, which is great, but there is no comparison to how it would have fared in another language, except his previous frustrations with C#, on other projects, I guess.
- weberc2 10y ago
  It would be ridiculous to expect Canonical (and even moreso, the author alone) to rewrite juju in another language as a simple comparison. Even if it were feasible, the comparison would be polluted by the experience gained by building the application initially (or you could rebuild with a completely new team of developers, but then you're introducing a whole new set of variables). The best we can reasonably do is compare applications aggregating on language.
- sciurus 10y ago
  Juju was originally written in Python. They ported it to Go 4 years ago. https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/jLnMsUbYwrQ https://groups.google.com/forum/?fromgroups=#!topic/golang-n...

NateDad 10y ago

To actually answer the question - yes it holds true, yes it scales (in my experience). There are a lot of abstractions that we built for Juju. And we absolutely tried to ensure there was only a single source of truth for everything. It would have been totally unworkable if we couldn't reuse logic etc. We may not always have chosen the best abstraction, but that's a problem in any language.