10 ms·

As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely

As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter. Go works very well in domains with a well-defined and limited set of entities.

chessturk 8y ago
Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would be useful in that space, is it?
- mynegation 8y ago
  > What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism. When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation. > If Go! had generics, would that change it's suitability for finance? I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube. > I would think that first-class concurrency would be useful in that space, is it? Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
  - imetatroll 8y ago
    You can define methods on structs which is not unlike classes. You can define an interface with methods that allow objects to be processed in a more generic fashion. I think that more than anything it would require a change of mindset that people understandably don't want to deal with.
    - alexkavon 8y ago
      There's also always a package to handle that issue. [0][1][2] As well as other options. [3] I like to imagine that the "no generics, no way" crowd would never use the stairway in their building if the elevator broke down. [0] https://github.com/clipperhouse/gen https://github.com/clipperhouse/gen [1] https://github.com/cheekybits/genny https://github.com/cheekybits/genny [2] https://github.com/cosmos72/gomacro https://github.com/cosmos72/gomacro [3] https://appliedgo.net/generics/ https://appliedgo.net/generics/
      - pjmlp 8y ago
        Ah, but the generics building was conceived with an elevator to start with, and it will eventually be repaired. Go's building architects decided an elevator was superfluous, as everyone should walk 20 stores high every single day, it is good for their health.
        alexkavon 8y ago
        More like Go’s building comes building-agnostic, whether you have 20 stories or not. Anything you need (such as a generic elevator) can be added on. No need to walk 20 stories every day because you can just add what you need in through reusable packages.
        pjmlp 8y ago
        Actually no, because in the end it will look like an Escher building.
      - 8y ago
hactually 8y ago
I've worked on financial applications, and esp in the fintech space here in Sydney, a lot are using go. Java/net are just not fun and the mentality of the developers seems off-putting to a lot of new devs and those seeking to move fast and ship stable.

chessturk 8y ago

Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would be useful in that space, is it?

mynegation 8y ago
> What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism. When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation. > If Go! had generics, would that change it's suitability for finance? I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube. > I would think that first-class concurrency would be useful in that space, is it? Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
- imetatroll 8y ago
  You can define methods on structs which is not unlike classes. You can define an interface with methods that allow objects to be processed in a more generic fashion. I think that more than anything it would require a change of mindset that people understandably don't want to deal with.
  - alexkavon 8y ago
    There's also always a package to handle that issue. [0][1][2] As well as other options. [3] I like to imagine that the "no generics, no way" crowd would never use the stairway in their building if the elevator broke down. [0] https://github.com/clipperhouse/gen https://github.com/clipperhouse/gen [1] https://github.com/cheekybits/genny https://github.com/cheekybits/genny [2] https://github.com/cosmos72/gomacro https://github.com/cosmos72/gomacro [3] https://appliedgo.net/generics/ https://appliedgo.net/generics/
    - pjmlp 8y ago
      Ah, but the generics building was conceived with an elevator to start with, and it will eventually be repaired. Go's building architects decided an elevator was superfluous, as everyone should walk 20 stores high every single day, it is good for their health.
      - alexkavon 8y ago
        More like Go’s building comes building-agnostic, whether you have 20 stories or not. Anything you need (such as a generic elevator) can be added on. No need to walk 20 stories every day because you can just add what you need in through reusable packages.
        pjmlp 8y ago
        Actually no, because in the end it will look like an Escher building.
    - 8y ago

hactually 8y ago

I've worked on financial applications, and esp in the fintech space here in Sydney, a lot are using go. Java/net are just not fun and the mentality of the developers seems off-putting to a lot of new devs and those seeking to move fast and ship stable.