9 ms·

There's a tension in languages between making it easier to write many layers of libraries versus making it easier to write applications. Languages that want li

There's a tension in languages between making it easier to write many layers of libraries versus making it easier to write applications. Languages that want libraries that go ten layers deep need to carefully manage things with sophisticated type systems and compilers that can cut through and inline all the abstractions so it still runs fast. Think rust, C++, haskell (all of which, not by coincidence, have long compile times). Languages for writing applications and solving problems tend to have a flatter dependency tree and wider standard library (often including practical functionality like JSON parsers). Think erlang, Perl, PHP. I used to think Go was in the latter category, but it seems to be getting pulled into the former category. Perhaps that's a reflection of Go developers using more layers of abstraction than they have in the past?

politician 6y ago
Go benefits from a continuous flattening phenomenon due to how interfaces and types interact. The determination of whether a type implements an interface is done at the interface use site rather than the type declaration site (as in C#, Java, etc.) I don't think Go developers are using more layers of abstraction than they have in the past; they aren't smarter or more sophisticated than they were before -- RAFT was written in Go, for example. Your observation is a good one, however; are there other ways that Go idiomatically flattens type hierarchies?
- jeffdavis 6y ago
  "they aren't smarter or more sophisticated than they were before" To be clear, I was not suggesting that more layers of abstraction reflect more sophisticated developers. Just that more layers require something in the language to help developers manage those layers without going insane. There's a lot of wisdom in choosing a flatter approach when it makes sense.
  - politician 6y ago
    In your opinion, what languages do have effective tools for managing high towers of abstraction? I'm genuinely curious, having spent many nights building ontologies.
    - jeffdavis 6y ago
      C++ and Rust come to mind. C++ can certainly go awry, but it does seem to have the tools available, even if they might be hard to use. Rust still has a few things to prove, but things are looking fairly good. Both languages can express constraints (e.g. type constraints) so that you don't have to make too many assumptions, and you know when APIs change in subtle ways. And both languages use inlining heavily to get "zero cost abstractions". I'll include ruby as well. It doesn't have a lot of "tools" per se, but if you're working on a nice codebase, it works out well even if using a lot of gems. Part of this is probably the unit testing/mocking, and part of it is that the code is just smaller. It does nothing to help you with performance though, so it can get really bad. My experience with Java has not been great. I'm unconvinced that inheritance hierarchies are a good idea at all, or much of the other ceremony around Java-style OOP. Java uses JIT compilation, which can help with performance a lot. If by "ontology" you mean "hierarchy", I'd caution you against that approach. Hierarchies enforce an order that is just not there in many cases. For instance, if you have an iPhone, would that be Hardware/Apple/iPhone or Apple/Hardware/iPhone? An iPhone is both Apple and Hardware, but there is no real order to those two -- yet if you try to put them in a hierarchy, then you must choose (and the choice will matter). I think interfaces/traits are much better. Both Go and Rust got this right.
      - politician 6y ago
        Good insights. Sorry, when I said "ontology", I was referring to the Web Ontology Language (OWL).
deleted 6y ago
[deleted]

politician 6y ago

Go benefits from a continuous flattening phenomenon due to how interfaces and types interact. The determination of whether a type implements an interface is done at the interface use site rather than the type declaration site (as in C#, Java, etc.) I don't think Go developers are using more layers of abstraction than they have in the past; they aren't smarter or more sophisticated than they were before -- RAFT was written in Go, for example. Your observation is a good one, however; are there other ways that Go idiomatically flattens type hierarchies?

jeffdavis 6y ago
"they aren't smarter or more sophisticated than they were before" To be clear, I was not suggesting that more layers of abstraction reflect more sophisticated developers. Just that more layers require something in the language to help developers manage those layers without going insane. There's a lot of wisdom in choosing a flatter approach when it makes sense.
- politician 6y ago
  In your opinion, what languages do have effective tools for managing high towers of abstraction? I'm genuinely curious, having spent many nights building ontologies.
  - jeffdavis 6y ago
    C++ and Rust come to mind. C++ can certainly go awry, but it does seem to have the tools available, even if they might be hard to use. Rust still has a few things to prove, but things are looking fairly good. Both languages can express constraints (e.g. type constraints) so that you don't have to make too many assumptions, and you know when APIs change in subtle ways. And both languages use inlining heavily to get "zero cost abstractions". I'll include ruby as well. It doesn't have a lot of "tools" per se, but if you're working on a nice codebase, it works out well even if using a lot of gems. Part of this is probably the unit testing/mocking, and part of it is that the code is just smaller. It does nothing to help you with performance though, so it can get really bad. My experience with Java has not been great. I'm unconvinced that inheritance hierarchies are a good idea at all, or much of the other ceremony around Java-style OOP. Java uses JIT compilation, which can help with performance a lot. If by "ontology" you mean "hierarchy", I'd caution you against that approach. Hierarchies enforce an order that is just not there in many cases. For instance, if you have an iPhone, would that be Hardware/Apple/iPhone or Apple/Hardware/iPhone? An iPhone is both Apple and Hardware, but there is no real order to those two -- yet if you try to put them in a hierarchy, then you must choose (and the choice will matter). I think interfaces/traits are much better. Both Go and Rust got this right.
    - politician 6y ago
      Good insights. Sorry, when I said "ontology", I was referring to the Web Ontology Language (OWL).

deleted 6y ago

[deleted]