←back to thread

133 points avan1 | 4 comments | | HN request time: 0.316s | source
Show context
liampulles ◴[] No.45078861[source]
I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them.

It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing things with the god framework, because each project has to deal with a niche infrastructure environment and/or business context that requires some hack or additional dependency. Then when you need to, say, upgrade a language version, you can't follow the god framework's guide for doing this (if there even is a decent one) because it will break your workaround. So you end up with this hodgepodge which never gets updated until it reaches a critical point where it cannot continue to run on your infrastructure, and it forces a big migration project.

Using a selection of libraries to build up the elements of a web service, and creating your own high-level abstractions for utilizing them, does require an additional time investment, but it leaves you in more control to do upgrades piece by piece, and to pivot the way things work when it is needed.

I feel like the Go ecosystem follows the latter approach more than most, and it was bit of a mindset shift for me at first, but I've grown to appreciate it.

replies(10): >>45079009 #>>45079250 #>>45079251 #>>45079544 #>>45079627 #>>45079933 #>>45080311 #>>45080715 #>>45082526 #>>45083171 #
evantbyrne ◴[] No.45079933[source]
The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being able to map/filter/reduce from a result type into another generic type would be a complete game changer. Being able specify union types would eliminate my need for the "any" type. Being able to overload would clean up a lot of code. It needs more time in the oven.
replies(2): >>45080212 #>>45083933 #
1. overfeed ◴[] No.45080212[source]
> The reason Go does not have a grand framework is that the language has a severely underdeveloped type system

Counterpoint: PHP.

PHP 5.3 had an even less capable type system, but developed several usable frameworks.

replies(3): >>45080286 #>>45083720 #>>45085764 #
2. evantbyrne ◴[] No.45080286[source]
That's a complimentary point, not a counterpoint. I'm talking about Go's type system being restrictive. PHP and many other languages avoided that particular trap by allowing variables to be reassigned to any type. Java and many other languages went in a different direction and instead chose to build more complete type systems.
3. pkphilip ◴[] No.45083720[source]
PHP's type system is so "dynamic" that it is very easy to build frameworks for it.

For instance, PHP allows for even function calls like this:

$language = "German";

$functionName = $language."_send_email";

$functionName("Mike", "mike_1@gmail.", "Text ...");

This sort of flexibility has its own problems and it is only possible because of the very lax type system of PHP but it is also extremely powerful when it comes to developing reusable frameworks.

4. const_cast ◴[] No.45085764[source]
PHP has fully looped back around and have a more capable type system than Go or even JS or Python. It took a long time, but it got there and it did it pretty competently.

In the past it got away with it because of PHP magic. PHP let's you do pretty much whatever, at least in the past.