Go generics are not bad • Hacker News Board

Re: Go generics are not bad

#271

Post by RhodesianHunter » Sun, Jul 10, 2022, 3:25 AM UTC

hsn915 wrote: post #266

cookiengineer wrote: post #101

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is a…

What is for loop fatigue? Seems like a fake problem that one would only feel if they buy too much into functional programming. Some ideas in fuctional programming are useful, but overall, for loops are much more preferable to map/filter/reduce. For loops are much more easily amenable to incremental changes. "reduce" is particularly bad. It obfuscates control flow for no benefit at all.

>but overall, for loops are much more preferable to map/filter/reduce

I strongly disagree on this one. A .map or a .filter are clear and concise while filtering or mapping, particularly in a streaming situation where you're only iterating the collection once.

You can trivially write code using this paradigm that's easily readable, performant, and takes up a handful of lines that would take dozens in Go.

Re: Go generics are not bad

#272

Post by ratww » Sun, Jul 10, 2022, 3:54 AM UTC

throwawaymaths wrote: post #269

hither_shores wrote: post #259

Earlier quoted context omitted.

If your code can run IO operations synchronously and branch on the result of previous operations, you've already got an IO monad. The point of being explicit about that is that it allows you to check that a given piece of code can't do those things. Keeping database calls out of the render loop, for instance, is very much a matter of actual correctness.

In most languages with an io monads your power of proving that x can or can't be done comes at the cost of hiding the business data inside of the monad type (that wraps it) which severely impacts debuggability and in many cases, code legibility and understandability of the data you care about -- because there might be a business logic error elsewhere that you need to track down that no amount of formal correctness wi…

The decades-old solution for that is to not mix the business and IO code in the first place. If you do, that's entirely on you. This works exactly the same and has the same goals as in popular OOP architectural patterns like Clean Architecture, Hexagonal Architecture or Onion Architecture.

With the difference that with a better type system it becomes significantly harder to do this kinda thing to begin with, and that's a GREAT thing. Your business code is extremely simple, reusable, isn't intertwined with IO stuff and is 100% testable with minimal effort, without needing mocks or anything of the sort.

If you don't care about this kind of correctness, then fine, but don't pretend this is something that's not sought after by both OOP and FP practitioners.

Re: Go generics are not bad

#273

Post by ratww » Sun, Jul 10, 2022, 3:57 AM UTC

throwawaymaths wrote: post #229

ratww wrote: post #202

Earlier quoted context omitted.

I personally do. At my company we recently finished adding types to some libraries that were a core part of our system but were deemed "untypeable" by the maintainers of the libraries themselves (we're contributing back), and only band-aids existed. We needed several advanced typing features in our languages for that that weren't available for us a couple years ago. Each time we added more advanced typing to new sect…

That's not theoretical soundness, that's actual correctness. I'm mostly talking about things like io monads.

I don't see why you're assuming we did something different, I even said "advanced typing features". We have several effect-related types, including IO.

Re: Go generics are not bad

#274

Post by ratww » Sun, Jul 10, 2022, 4:08 AM UTC

morelisp wrote: post #245

ratww wrote: post #244

Earlier quoted context omitted.

Bullshit. “Misses several features” doesn’t mean “misses all features ever invented”. What an absurd interpretation. There are several languages in between Go and C++ that suffer from neither problem of having too much or too little.

Your lack of specifics means you’re more interested in language bashing than discussing the relative value of features for different contexts. It’s been almost two decades of increasing memory latency relative to clock yet Java still lacks value types? Unusable!

Alright, so you went from twisting my words to claiming I can't have an opinion unless I provide specifics. This thread already started with specifics: functional operators like map/filter/reduce/etc. What I'm addressing are personal attacks by Golang luddites.

Re: Go generics are not bad

#275

Post by ratww » Sun, Jul 10, 2022, 4:19 AM UTC

Matl wrote: post #252

ratww wrote: post #243

Earlier quoted context omitted.

Who cares if it’s cheap and tiring, it’s the truth. When it was missing generica, saying so was also called a “cheap shot”. There’s plenty of proposals of thing that can be improved in this thread alone. Not every post has to contain them to be valid criticism. Sure it could have more but that doesn’t warrant personal attacks.

> Who cares if it’s cheap and tiring, it’s the truth. You do realize that is a matter of personal opinion, right? There's plenty of developers who like the language, (doesn't mean they're not seeking to always improve it), then there's those who hate it. But a comment from someone who loves Go but says nothing more as to why would be equally as useless as a generic comment from someone less found of it. They're free…

No. It's not a matter of personal opinion. Go indeed lacks "several features, including safety features, that help people perform their job better". Whether you're one of those people and whether the language really needs those features is a different issue. But when it comes to modern languages Go stands out for lacking several important features. And of course no language "needs" most features: as long as it's Turing Complete it can do anything. But Turing Completeness is the lowest bar possible, and in the real world you need more.

What people are trying to have here is starting discussion of possible paths for the language to grow, no matter how crude that "start" is. It is "cheap" criticism? Sure, but it is valid criticism to the language. Sure, you can call those comments useless, but that's not what you're doing. What you're doing instead is taking language criticism personally, and then directing personal attacks at people making them. That's why your post was flagged, btw.

Re: Go generics are not bad

#276

Post by ratww » Sun, Jul 10, 2022, 4:25 AM UTC

morelisp wrote: post #247

kaba0 wrote: post #237

Earlier quoted context omitted.

Missing features is not the problem. A language is just as much what it has as much as what it doesn’t have. But the actual feature-set and lack-of-features Go has for it is ripe for plenty of valid criticism as is.

> the actual feature-set and lack-of-features Go has for it is ripe for plenty of valid criticism as is. But this , as a criticism of Go, is vapid. Level the actual criticism, not a vague gesture towards the possibility of it!

The post that you're all talking about was replying to someone who attacked everyone criticising Go and called advanced PL features "type system fidget spinners".

Addressing this kind of post doesn't require providing examples of how Go can grow. Also, I don't see why is the bar for criticising Golang's stagnation so much higher than the bar for people that want the language to never change.

Re: Go generics are not bad

#277

Post by kaba0 » Sun, Jul 10, 2022, 5:22 AM UTC

morelisp wrote: post #248

kaba0 wrote: post #238

Earlier quoted context omitted.

How does it bring back productivity when it has the expressivity of C (at least before generics, it’s a bit better afterwards)

C doesn’t have methods, interfaces, closures, newtypes, packages, map or safe slice and string types, or safe automatic allocations. What bad faith nonsense.

And before generics it could not even implement maps in the language itself, hence my comment.

Re: Go generics are not bad

#278

Post by germandiago » Sun, Jul 10, 2022, 5:24 AM UTC

grumpyprole wrote: post #256

germandiago wrote: post #242

Earlier quoted context omitted.

Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.

Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.

Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.

Re: Go generics are not bad

#279

Post by throwawaymaths » Sun, Jul 10, 2022, 5:47 AM UTC

ratww wrote: post #272

throwawaymaths wrote: post #269

Earlier quoted context omitted.

In most languages with an io monads your power of proving that x can or can't be done comes at the cost of hiding the business data inside of the monad type (that wraps it) which severely impacts debuggability and in many cases, code legibility and understandability of the data you care about -- because there might be a business logic error elsewhere that you need to track down that no amount of formal correctness wi…

The decades-old solution for that is to not mix the business and IO code in the first place. If you do, that's entirely on you. This works exactly the same and has the same goals as in popular OOP architectural patterns like Clean Architecture, Hexagonal Architecture or Onion Architecture. With the difference that with a better type system it becomes significantly harder to do this kinda thing to begin with, and that…

Where did you get the idea that I practice oop? I exclusively use FP, and I use hexagonal-ish fp design. But question. Suppose you discover you have a logic bug and you write a pure logic test for it. But perhaps the path through the business logic was written by someone else, who has since left the company. It's a tax rule so you have to navigate through several layers of abstractions that are sometimes specialized for different countries, sometimes generalized. Maybe they didn't write all the tests that you'd like to see. You have one hour to deploy a patch because 9-5 customers are entering their work hours on a different continent whose tax rules are what you need to fix. How do you introspect the data that are moving through the code?

Re: Go generics are not bad

#280

Post by ratww » Sun, Jul 10, 2022, 6:06 AM UTC

throwawaymaths wrote: post #279

ratww wrote: post #272

Earlier quoted context omitted.

The decades-old solution for that is to not mix the business and IO code in the first place. If you do, that's entirely on you. This works exactly the same and has the same goals as in popular OOP architectural patterns like Clean Architecture, Hexagonal Architecture or Onion Architecture. With the difference that with a better type system it becomes significantly harder to do this kinda thing to begin with, and that…

Where did you get the idea that I practice oop? I exclusively use FP, and I use hexagonal-ish fp design. But question. Suppose you discover you have a logic bug and you write a pure logic test for it. But perhaps the path through the business logic was written by someone else, who has since left the company. It's a tax rule so you have to navigate through several layers of abstractions that are sometimes specialized…

Where did I say you practice OOP? I'm just making a comparison to another paradigm in my reply to demonstrate that this is not an FP problem alone, continuing the train of thought started by hither_shores. Not everything is about you, friend.

About the "IO monad in business" issue: there's ways to solve it without having to pass IO through business layers or having to break architectural constraints. In the OOP architectures alone there's lots of patterns to avoid doing it already, and if you're doing it should all be in place, probably by passing a repository down to the business layer. In FP there are similar patterns to avoid needing a monad down in business code, passing down a repository-analog is enough. If you can't solve it without a "hack", then it's fine: that's just technical debt. That's on you to fix later. Or not, it's your work. About the question: gotta need more context for that, that's the vaguest thing someone asked me lately.

It's however one's own choice to decide how to deal with that. I prefer using constraints imposed by the typing system. You're free to do otherwise, but don't imply nobody wants it like you did in your first post, as there's people who find it useful. Once again, not everything is about you and you alone.