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.

▲

overfeed 2 days ago | parent | next [-]

> 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.

	▲	evantbyrne 2 days ago \| parent \| next [-]
		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.
	▲	pkphilip 2 days ago \| parent \| prev \| next [-]
		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.
	▲	const_cast 2 days ago \| parent \| prev [-]
		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.

▲

liampulles 2 days ago | parent | prev [-]

I think the Java stream API is amazing, and I do like that.

Not having the equivalent of hibernate level ORMs is not a disadvantage for me personally, just because I don't like ORMs - Asking chatgpt to spit out some SQL and mapping code for me and being able to tweak the actual SQL over time is preferable (but again that is just my preference).

I don't really agree with the idea that Go has an underdeveloped type system, I think its contraints lend itself to productivity in other ways. Of the various languages I've worked with, Go programs I expand have the highest chance of working the first time I run them, because the compiler and language server A) give meaningful indications of mismatched usages and B) older Go projects have a very good chance of just working, without me having to worry about getting them going with my IDE again. B is a product of the fact that they have been very conservative with the language.

	▲	evantbyrne 19 hours ago \| parent [-]
		Is it possible that some of the mismatch in how people view Go's type system is due to experiences differing from writing applications vs writing libraries? I personally find some of the repetition in Go code to be tolerable when writing web applications and CLI tools, but a real issue for the composability of libraries with different purposes. Going back to the database toolkit example, the query builder can easily return a result type, but what if I also want to handle validation of input before the query and then later return a HTTP response? Well to chain a result type end-to-end in Go requires it to have knowledge of all the different types/interfaces that it could map to, which I believe is way too broad of a responsibility for one type, even though all of those features feel as though they could very naturally chain together and reduce down to a single error. These kinds of type limitations effectively force Go libraries to live on their own islands where they don't compose with one another.