11 ms·

My experience translating a codebase from Python to Golang (chat application), is that 20k of Python really does translate to around 40k of Golang to get the sa

My experience translating a codebase from Python to Golang (chat application), is that 20k of Python really does translate to around 40k of Golang to get the same functionality. And it’s not just due to language but also expressiveness of the library ecosystem.

arp242 3y ago
I don't have any concrete measurements, but I think this is about right, ± a bit depending on the type of application. I don't think this is necessarily a bad thing though; Go is a bit more explicit on a number of things and there's less opportunity to make code 'dense'. Both have their own up- and downsides.
- josephg 3y ago
  I really think go goes too far to the point of hurting productivity and expressiveness. For example, go is missing any way to write parametric enums (sum types). Sum types make code much simpler and more expressive. The equivalent go code (using interfaces) is uglier, more verbose and more error prone. There’s a lot of features like that which go leaves out - like iterators, optional (nullable) types and so on. The only tradeoff I see is that go is faster to learn, because it has less syntax. But at the end of the day I don’t mind spending a bit more time learning a language if the result is I can write more expressive and clear code. I love go’s concurrency model. It’s clever and simple to learn. I wish they applied the same pragmatism when designing other parts of the language.
  - arp242 3y ago
    All these things are a trade-off; unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Whether it's worth the trade-off is a subjective judgement call and a completely different thing.
    - ReleaseCandidat 3y ago
      > unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Just about everything is "simpler" than Go's `iota` (which isn't even easier for the compiler implementor).
      - arp242 3y ago
        I never said there aren't features in Go I would rather see removed, or that there aren't features I would like to see added, or that Go is perfect in general.
        ReleaseCandidat 3y ago
        Súm types (or even just working enums) would replace iota.
        arp242 3y ago
        Only for some uses of iota. And iota is "simpler" from some perspectives, because you never have to deal with it anywhere except in const (..) blocks (that is, it's a very "localized" feature that barely interacts with anything else).
    - josephg 3y ago
      If all things are a trade-off, what would the trade-off of adding sum types be? > All these things are a trade-off; In some cases the trade-off is so one sided that its hardly worth the conversation. If everything is a trade-off, do you feel the same way about indenting your code? Or structured programming - aka using if/while blocks instead of gotos? I think I'd confidently say that indented code makes everything simpler. And if I were given the choice, I think I'd choose structured programming every single time. I also don't often find myself questioning my daily choice to use high level languages rather than writing assembly directly. What else? Mmm... functions? I like those. I feel the same way about sum types. They feel like an obviously good idea. Try as I might I can't think of any reason not to have them in a language like Go - except, as I already said - that they are another thing to learn when getting started. Having sum types and generics also makes it much easier for the type system to support optional types. And that makes it easier for a language to do away with Hoare's "billion dollar mistake". If you disagree, I'd love to hear what you think the downsides are.
tonymet 3y ago
Are you including the libs in the calculation? E.g. if in python you can “import map” and in golang you implement map, which one is being counted.
Mawr 3y ago
I very much doubt that. "The man barrier to translation was that, while at 14KLOC of Python reposurgeon was not especially large, the code is very dense. It’s a DSL that’s a structure editor for attributed DAGs — algorithmically complex, bristling with graph theory, FSMs, parsing, tricky data structures, two robot harnesses driving other tools, and three different operator-composition algebras. It became 21KLOC of Go." [1] [1]: https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.adoc https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado...
- aserafini 3y ago
  It’s not a subjective opinion: I’m saying that I’ve actually migrated a Python application to Golang (real time chat application with a lot of business logic) and it was 2x the line count. I expect the Golang line count ‘overhead’ gets bigger for typical LoB software that has to address any sort of enterprise mess.

arp242 3y ago

I don't have any concrete measurements, but I think this is about right, ± a bit depending on the type of application. I don't think this is necessarily a bad thing though; Go is a bit more explicit on a number of things and there's less opportunity to make code 'dense'. Both have their own up- and downsides.

josephg 3y ago
I really think go goes too far to the point of hurting productivity and expressiveness. For example, go is missing any way to write parametric enums (sum types). Sum types make code much simpler and more expressive. The equivalent go code (using interfaces) is uglier, more verbose and more error prone. There’s a lot of features like that which go leaves out - like iterators, optional (nullable) types and so on. The only tradeoff I see is that go is faster to learn, because it has less syntax. But at the end of the day I don’t mind spending a bit more time learning a language if the result is I can write more expressive and clear code. I love go’s concurrency model. It’s clever and simple to learn. I wish they applied the same pragmatism when designing other parts of the language.
- arp242 3y ago
  All these things are a trade-off; unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Whether it's worth the trade-off is a subjective judgement call and a completely different thing.
  - ReleaseCandidat 3y ago
    > unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Just about everything is "simpler" than Go's `iota` (which isn't even easier for the compiler implementor).
    - arp242 3y ago
      I never said there aren't features in Go I would rather see removed, or that there aren't features I would like to see added, or that Go is perfect in general.
      - ReleaseCandidat 3y ago
        Súm types (or even just working enums) would replace iota.
        arp242 3y ago
        Only for some uses of iota. And iota is "simpler" from some perspectives, because you never have to deal with it anywhere except in const (..) blocks (that is, it's a very "localized" feature that barely interacts with anything else).
  - josephg 3y ago
    If all things are a trade-off, what would the trade-off of adding sum types be? > All these things are a trade-off; In some cases the trade-off is so one sided that its hardly worth the conversation. If everything is a trade-off, do you feel the same way about indenting your code? Or structured programming - aka using if/while blocks instead of gotos? I think I'd confidently say that indented code makes everything simpler. And if I were given the choice, I think I'd choose structured programming every single time. I also don't often find myself questioning my daily choice to use high level languages rather than writing assembly directly. What else? Mmm... functions? I like those. I feel the same way about sum types. They feel like an obviously good idea. Try as I might I can't think of any reason not to have them in a language like Go - except, as I already said - that they are another thing to learn when getting started. Having sum types and generics also makes it much easier for the type system to support optional types. And that makes it easier for a language to do away with Hoare's "billion dollar mistake". If you disagree, I'd love to hear what you think the downsides are.

tonymet 3y ago

Are you including the libs in the calculation? E.g. if in python you can “import map” and in golang you implement map, which one is being counted.

Mawr 3y ago

I very much doubt that. "The man barrier to translation was that, while at 14KLOC of Python reposurgeon was not especially large, the code is very dense. It’s a DSL that’s a structure editor for attributed DAGs — algorithmically complex, bristling with graph theory, FSMs, parsing, tricky data structures, two robot harnesses driving other tools, and three different operator-composition algebras. It became 21KLOC of Go." [1] [1]: https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.adoc https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado...

aserafini 3y ago
It’s not a subjective opinion: I’m saying that I’ve actually migrated a Python application to Golang (real time chat application with a lot of business logic) and it was 2x the line count. I expect the Golang line count ‘overhead’ gets bigger for typical LoB software that has to address any sort of enterprise mess.