111–120 of 181 posts
If this isn’t obvious, we are lost. Creating a rest endpoint where a library would do is pure insanity.
I wholeheartedly agree with your sentiment.
Unfortunately, the obvious economic incentive to effectively paywalling code through the Internet, is so strong that on this very website (that was supposed to have hacker mentality) most of the comments are in favour of it, because “you have to make a living”…
Yes, I think we are lost.
A library is a piece of code that you embed. A service is already deployed and configured, ready to use.
Services provide a much nicer boundary for splitting responsibilities in any SaaS-like organization.
The difference lies in deployment. A library is a piece of code that you embed. A service is already deployed and configured, ready to use. Services provide a much nicer boundary for splitting responsibilities in any SaaS-like organization.
Libraries and services both have maintenance costs and upgrade impedance from clients. The costs might differ, but in my experience work out to about the same overall. The correct way to determine whether a piece of software should be a library or service is by examining its intended purpose and its dependencies. - If the software is dependent on another service or a data store, it should be a service: this provides…
I think this is roughly true, but at a BigCo it’s not really feasible/easy unless you have a monorepo or otherwise extremely good build/integration tooling to deal with many repos (though Go can sort of deal with this) The issue is coordinating changes (and, god help you, library releases) across repos is often an utter nightmare with multiple PR/merge builds
> it’s not really feasible/easy unless you have a monorepo or otherwise extremely good build/integration tooling to deal with many repos[...] The issue is coordinating changes [...] across repos is often an utter nightmare with multiple PR/merge builds I'm coming up on a year out of $BIG_TECH_JOB (where the idea of a monorepo was horrifying) and transferred to $WAY_SMALLER_NON_TECH_COMPANY_WHO_USES_TECH_JOB (where th…
It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…
You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice.
This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.)
In other words, you with straight face describe some really shady practice and you don't even realize how bad it sounds.
Earlier quoted context omitted.
This is making technology objectively worse to solve people problems, and this only expands. More software needs iron clad leadership and control. Any organization that lacks this can’t help but produce shit software. There has to be a single person with real decision making power than can force upgrades and prioritization of work, and they need to be able to axe people or teams who can’t hack it.
OK but most business compete in a market. And the people they employ are in a labour market. It seems that worse is better. What we see is just another manifestation of the current economic paradigm. Waste is winning. Making too many pairs of jeans so we burn tons of perfectly good new pairs daily wins. Throwing hundreds of engineers on problems bashing out hundreds of thousands of lines of code sending megabyte mess…
It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…
It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…
> It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. How is that different with services? I don't develop services, but I can imagine that before breaking the services, you have to poll with your biggest customers and you don't break until they are ready to move to the new version. The alternative I can imagine is to keep providing the old se…
If this isn’t obvious, we are lost. Creating a rest endpoint where a library would do is pure insanity.
And yet.. I wholeheartedly agree with your sentiment. Unfortunately, the obvious economic incentive to effectively paywalling code through the Internet, is so strong that on this very website (that was supposed to have hacker mentality) most of the comments are in favour of it, because “you have to make a living”… Yes, I think we are lost.