I highly doubt that, throwing around data in ad-hoc plaintext formats that is written and parsed by brittle scripts is exactly what you not want to do. If you want to see good compositionality you should probably look in the world of functional programming.
I think the problem with composition is that people have used it for pretty much the opposite, because the term is a bit more vague.
People sadly use the term like a buzz word and whenever they connect thing, even if it’s simple two features of a framework or system.
When I read terms like composable is it’s often without any meaning and I’ve got to figure out what it means by the context.
That’s why I personally try to avoid it and I wouldn’t be surprised if others do the same. I know it means that correct usage of that word isn’t helped by this, but too me that word is pretty much burnt unless it’s some “celebrity” or friend using it.
The Go stdlib is extensive to the point that it’s clearly framework-adjacent. But it’s also minimal to the point that you’re almost certainly going to need dependencies to do certain things.
Do you really need to write your own bespoke routing engine? No you don’t. Use a framework for that.
mux and chi are both very capable routers, they’re not really frameworks. I prefer to use the approach of just using a simple router and the standard net/http handler interface over having a framework that tries to figure out every possible problem.
You don’t need to use another router, but it’s a pain to have to manually do things like reject POST requests to GET endpoints and whatnot. Plus you need to special case / to be both the homepage and the 404 page. Nothing insurmountable, but you can also just write your own 200 line library and not have to deal with it anymore.
I agree with the article on the basis that especially inexperienced programmers tend to ask for a framework first, like it’s a given that they will need one, also when going into a new field, be it going from backend to front end, vice versa, be it machine learning, game development or anything else even system administrator/devops. The first action seems to be finding a framework and eat too often in a generic manner, so but focused on a concrete problem which means evaluation is trimmed down to most features, most buzzwords or what Google, Facebook and Co. use.
I notice that even more experienced developers who have abandoned that way of thinking in their field of expertise start out there in a new field. Now of course I understand it’s not completely unreasonable to get a feel for something by relying on widely used frameworks, but looking beyond frameworks can bring a lot of benefits. It’s certainly not just frameworks that are used in successful projects, regardless of the field.
Good take, and in my experience this is how all Go teams and experienced Go engineers work.
The way I do things is “frameworkless” in the sense that I’m still using abstractions over the low level standard library things, but it’s a “do-one-job-well” composition of small simple tools.
And a heck of a lot of code-generation. Luv me type safety, ’ate runtime errors!
A framework doesn’t have to provide software. It could be an approach to solving your problem. Just like the software sort of framework, this sort is hard to tear out later.
So the best Go framework is the Go Way of plugging libraries together to perform the discrete roles.
I wish people could say that something favors composition without invoking “the Unix philosophy”.
It’s probably the best and most successful example of composition in the history of software, to be fair.
I highly doubt that, throwing around data in ad-hoc plaintext formats that is written and parsed by brittle scripts is exactly what you not want to do. If you want to see good compositionality you should probably look in the world of functional programming.
They’re not ad-hoc, they’re program specific. Why are you writing brittle scripts?
I think the problem with composition is that people have used it for pretty much the opposite, because the term is a bit more vague.
People sadly use the term like a buzz word and whenever they connect thing, even if it’s simple two features of a framework or system.
When I read terms like composable is it’s often without any meaning and I’ve got to figure out what it means by the context.
That’s why I personally try to avoid it and I wouldn’t be surprised if others do the same. I know it means that correct usage of that word isn’t helped by this, but too me that word is pretty much burnt unless it’s some “celebrity” or friend using it.
I don’t know; maybe a garden hose is an okayish way to put it.
The Go stdlib is extensive to the point that it’s clearly framework-adjacent. But it’s also minimal to the point that you’re almost certainly going to need dependencies to do certain things.
Do you really need to write your own bespoke routing engine? No you don’t. Use a framework for that.
mux and chi are both very capable routers, they’re not really frameworks. I prefer to use the approach of just using a simple router and the standard net/http handler interface over having a framework that tries to figure out every possible problem.
I may be showing my inexperience, but i haven’t yet built a project of the scale where I needed more sophisticated routing than the STL router
You don’t need to use another router, but it’s a pain to have to manually do things like reject POST requests to GET endpoints and whatnot. Plus you need to special case / to be both the homepage and the 404 page. Nothing insurmountable, but you can also just write your own 200 line library and not have to deal with it anymore.
I agree with the article on the basis that especially inexperienced programmers tend to ask for a framework first, like it’s a given that they will need one, also when going into a new field, be it going from backend to front end, vice versa, be it machine learning, game development or anything else even system administrator/devops. The first action seems to be finding a framework and eat too often in a generic manner, so but focused on a concrete problem which means evaluation is trimmed down to most features, most buzzwords or what Google, Facebook and Co. use.
I notice that even more experienced developers who have abandoned that way of thinking in their field of expertise start out there in a new field. Now of course I understand it’s not completely unreasonable to get a feel for something by relying on widely used frameworks, but looking beyond frameworks can bring a lot of benefits. It’s certainly not just frameworks that are used in successful projects, regardless of the field.
In other words, frameworks win at marketing because they court an audience that exhibits excellent growth characteristics.
This is a completely separate game from being the most elegant or technically sound solution.
I would add: Court an audience looking to use them for status or tribal affiliation. Hence all the ABCConfs, or ABCPodcasts, etc.
Good take, and in my experience this is how all Go teams and experienced Go engineers work.
The way I do things is “frameworkless” in the sense that I’m still using abstractions over the low level standard library things, but it’s a “do-one-job-well” composition of small simple tools.
And a heck of a lot of code-generation. Luv me type safety, ’ate runtime errors!
I would describe buffalo (https://gobuffalo.io/) as quite Rails-like, with a minimalist/plugable Go ethos.
Rails is as far from minimalist as you can get.
From the book advertised here the other day: https://lobste.rs/s/wiooyx/out_software_crisis_systems_thinking_for
A framework doesn’t have to provide software. It could be an approach to solving your problem. Just like the software sort of framework, this sort is hard to tear out later.
So the best Go framework is the Go Way of plugging libraries together to perform the discrete roles.