4 ms·

I'd be interested to see whether people said the same about other languages with dominant frameworks now. I've personally learned that at very large people scal

by asim 4y ago

I'd be interested to see whether people said the same about other languages with dominant frameworks now. I've personally learned that at very large people scale, frameworks end up emerging aka the common libraries grouped together into a package that everyone then adopts as the starter. Frameworks leads to standardisation which leads to reuse which leads to generally better software development as can be seen by things like Rails and Spring.

preseinger 4y ago
In addition to the points raised in the other replies, I would observe that Go lacks most of the meta-programming features that frameworks rely upon to deliver value. You can't monkey-patch, you can't annotate functions, you can't really introspect types or do typical dynamic programming stuff. You can often use package reflect to hack up something approximating a solution to this class of problems, true. But, like package unsafe, package reflect sidesteps a bunch of language assumptions, conventions, idioms, etc. which means any code that uses reflection is going to be subtle, brittle. It's a tool of last resort, really, an escape hatch. Not something that you should consider part of your tool set. This is all by design, I think. Go tries to ensure that a straight-line reading of the code accurately represents the execution flow. So you can't really implement the inversion of control patterns that frameworks usually rely on without fighting the language.
geodel 4y ago
I could understand Rails as it is for an already dynamic language. But Spring existence which very heavily rely on reflection always perplex me even though I am forced to use at work. It throws runtime exceptions which would otherwise been compiler error in Plain Java. Further it turns some straight forward business logic in to some cultish bulshittery of endless packages, classes, annotations and so on. But hey, there is no xml config now, so it all is super modern stuff. Just yesterday, I had to look into perf issue of Spring based project. It has probably 500 line of core business logic. But it is littered in tens of packages and dozens of java source files. So it is standardization for sure but it does not seem to be leading to better results. It is however giving a great cover for bad stuff because now code follows all best practices as per Spring framework.
- asim 4y ago
  There's a point of diminishing returns to all technology. Even the folks developing Rails or Spring know that. This is why new things emerge which "simplify" that experience once more, but inevitably we just end up back in that same place. If I'm to examine the experience of hundreds or thousands of developers forced to use a certain tool within an organisation, they quite actively contribute back to fixing a lot of those problems within the frameworks. It always seems simpler to opt-out of it but then you end up having to reimplement a lot of the same things and maintain your own bespoke thing. Inevitably it becomes a game of tradeoffs, yes frameworks are multi-layered and sometimes that can be a problem but the alternative also doesn't scale when you need 1000+ devs to do something the same way.
- jen20 4y ago
  Every time I have to look into an "Enterprise" Java program it feels like playing a game of hide and seek with the hundred lines of business logic that exist in the midst of reams and reams of accidental complexity. It drives me nuts.
  - fruit2020 4y ago
    That’s just bad coding. It’s not the language itself
    - jen20 4y ago
      Sure, but the ecosystem encourages it. If it were _just_ bad coding I’d expect to see it everywhere, and have yet to run into a Go or Rust project that suffered in Tia way.
    - geodel 4y ago
      I guess the problem is it can't called out as bad coding because those codebases are apparently following the best practices of Java framework in use.
  - geodel 4y ago
    That sounds about right for most of Java projects I have come across in 15 yrs of my experience.
xani_ 4y ago
Or massive amount of bloat everywhere, depending on how good initial framework design was.
jerf 4y ago
A resolution for your confusion is that this is a result of Go being younger than the web. Languages turn over very slowly and most languages used on the web for the server are older than the web, or at the very least, older than the web being a major concern for them. Many "web frameworks" are, at their core, a way of hooking many different things together. Go's net/http is already that framework, so it is practical in Go to not have "a framework" tying everything together. You can take a router from here and a variable mapper from there and a template library from yet another place and they all already have the foundation to work together. Some of those places may even be from full "frameworks" of their own, and things still tend to work together pretty well. I emphasize the age of Go because I don't think this is a virtue of the language per se (considered as a bag of features), or because the developers were super geniuses who could see what nobody else could. It's just that net/http was able to be spec'd and put into the standard library based on the decades of experiences other languages had. I would expect any other upcoming languages to be able to pull off a similar trick, as long as they try. I certainly don't sit down with every Go web app I write with literally nothing but the standard library. I do have some non-trivial code written that way, but it isn't something I seek out as a terminal goal. It just isn't necessary to go commit to "Spring" or "Ruby on Rails" or some other framework just to get access to anything at all. I'm already in the Go ecosystem just by using net/http, you're not obligated to commit to a "framework"'s ecosystem just to get access to basic functionality because you're all but already tied in to a framework's ecosystem just by using Go, and there are many options for that basic functionality. And to be clear, I'm more agreeing with you than disagreeing with you; I'm trying to explain the divergence between your understanding and what the Go ecosystem has because I consider it a worthy question to ask, and there is legitimately an interesting question to consider here based on experience from many other languages.
- asim 4y ago
  I like the rationale here, had not really even considered the era in which Go was created and the implications for that in comparison to languages and frameworks of the past. You're right though, it changes things. My experiences from ruby and java were just that frameworks ended up creating standardisation and Go being the language of the Cloud was probably going to need something similar. Adoption curves take time but I think you're right, it's more likely that an extension to the standard library for distributed systems concerns works better than say a framework.

by asim 4y ago

preseinger 4y ago

In addition to the points raised in the other replies, I would observe that Go lacks most of the meta-programming features that frameworks rely upon to deliver value. You can't monkey-patch, you can't annotate functions, you can't really introspect types or do typical dynamic programming stuff. You can often use package reflect to hack up something approximating a solution to this class of problems, true. But, like package unsafe, package reflect sidesteps a bunch of language assumptions, conventions, idioms, etc. which means any code that uses reflection is going to be subtle, brittle. It's a tool of last resort, really, an escape hatch. Not something that you should consider part of your tool set. This is all by design, I think. Go tries to ensure that a straight-line reading of the code accurately represents the execution flow. So you can't really implement the inversion of control patterns that frameworks usually rely on without fighting the language.

geodel 4y ago

I could understand Rails as it is for an already dynamic language. But Spring existence which very heavily rely on reflection always perplex me even though I am forced to use at work. It throws runtime exceptions which would otherwise been compiler error in Plain Java. Further it turns some straight forward business logic in to some cultish bulshittery of endless packages, classes, annotations and so on. But hey, there is no xml config now, so it all is super modern stuff. Just yesterday, I had to look into perf issue of Spring based project. It has probably 500 line of core business logic. But it is littered in tens of packages and dozens of java source files. So it is standardization for sure but it does not seem to be leading to better results. It is however giving a great cover for bad stuff because now code follows all best practices as per Spring framework.

asim 4y ago
There's a point of diminishing returns to all technology. Even the folks developing Rails or Spring know that. This is why new things emerge which "simplify" that experience once more, but inevitably we just end up back in that same place. If I'm to examine the experience of hundreds or thousands of developers forced to use a certain tool within an organisation, they quite actively contribute back to fixing a lot of those problems within the frameworks. It always seems simpler to opt-out of it but then you end up having to reimplement a lot of the same things and maintain your own bespoke thing. Inevitably it becomes a game of tradeoffs, yes frameworks are multi-layered and sometimes that can be a problem but the alternative also doesn't scale when you need 1000+ devs to do something the same way.
jen20 4y ago
Every time I have to look into an "Enterprise" Java program it feels like playing a game of hide and seek with the hundred lines of business logic that exist in the midst of reams and reams of accidental complexity. It drives me nuts.
- fruit2020 4y ago
  That’s just bad coding. It’s not the language itself
  - jen20 4y ago
    Sure, but the ecosystem encourages it. If it were _just_ bad coding I’d expect to see it everywhere, and have yet to run into a Go or Rust project that suffered in Tia way.
  - geodel 4y ago
    I guess the problem is it can't called out as bad coding because those codebases are apparently following the best practices of Java framework in use.
- geodel 4y ago
  That sounds about right for most of Java projects I have come across in 15 yrs of my experience.

xani_ 4y ago

Or massive amount of bloat everywhere, depending on how good initial framework design was.

jerf 4y ago

A resolution for your confusion is that this is a result of Go being younger than the web. Languages turn over very slowly and most languages used on the web for the server are older than the web, or at the very least, older than the web being a major concern for them. Many "web frameworks" are, at their core, a way of hooking many different things together. Go's net/http is already that framework, so it is practical in Go to not have "a framework" tying everything together. You can take a router from here and a variable mapper from there and a template library from yet another place and they all already have the foundation to work together. Some of those places may even be from full "frameworks" of their own, and things still tend to work together pretty well. I emphasize the age of Go because I don't think this is a virtue of the language per se (considered as a bag of features), or because the developers were super geniuses who could see what nobody else could. It's just that net/http was able to be spec'd and put into the standard library based on the decades of experiences other languages had. I would expect any other upcoming languages to be able to pull off a similar trick, as long as they try. I certainly don't sit down with every Go web app I write with literally nothing but the standard library. I do have some non-trivial code written that way, but it isn't something I seek out as a terminal goal. It just isn't necessary to go commit to "Spring" or "Ruby on Rails" or some other framework just to get access to anything at all. I'm already in the Go ecosystem just by using net/http, you're not obligated to commit to a "framework"'s ecosystem just to get access to basic functionality because you're all but already tied in to a framework's ecosystem just by using Go, and there are many options for that basic functionality. And to be clear, I'm more agreeing with you than disagreeing with you; I'm trying to explain the divergence between your understanding and what the Go ecosystem has because I consider it a worthy question to ask, and there is legitimately an interesting question to consider here based on experience from many other languages.

asim 4y ago
I like the rationale here, had not really even considered the era in which Go was created and the implications for that in comparison to languages and frameworks of the past. You're right though, it changes things. My experiences from ruby and java were just that frameworks ended up creating standardisation and Go being the language of the Cloud was probably going to need something similar. Adoption curves take time but I think you're right, it's more likely that an extension to the standard library for distributed systems concerns works better than say a framework.