3 ms·
I've been writing software for 20 years. About half that in Go. Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just
by silisili 4y ago
I've been writing software for 20 years. About half that in Go.
Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just writes terrible code, or if there's whole swaths of domains I've not encountered. Or maybe a little of both.
I've never once been stumped by a lack of generics, for example, despite how many people claim it's unusable without them.
- pjmlp 4y agoPlenty of software has been written on languages without generics, but they have the excuse of coming up before generics were a common feature in mainstream languages. At least that has been finally fixed.
- shakow 4y ago> I've never once been stumped by a lack of generics Heve you never written a stack structure (since Go doesn't include one)? Never used a min/max function between numbers (go doesn't either)?
- rad_gruchalski 4y agoI have, maybe a couple of times. Never missed generics.
- ilyt 4y agoThose are not show-stoppers, just annoyances. Generics make it oh so much nicer to do some stuff but lack of them wasn't exactly something that I missed, just that I wished some libraries had for the cases you mentioned (generic map/reduce/math/etc.)
- ilyt 4y agoGenerics were never required, just their lack was annoying and their presence makes some things just cleaner and easier For example I deal in ops stuff so pretty common task is "here are desired and current set, generate list of add/delete operations to get from one state to another". I wrote iteration of that function a bunch of times pre-generics, eventually being just copy-paste-change-types but now I can just write [1] one that compares a slice of types and returns the elements present in left or right and [2] another that can do similar difference on disparate types via conversion function. Then there is a whole slew of map/reduce and math stuff that now can just have `Map` or `Max` function without worrying about types. Hell I can "just" write "parse all the slice elements in parallel, keeping order [3] once and never worry about it. That's also code that I wrote more than once before generics * [1] https://github.com/XANi/goneric/blob/master/slice.go#L77 https://github.com/XANi/goneric/blob/master/slice.go#L77 * [2] https://github.com/XANi/goneric/blob/master/slice.go#L106 https://github.com/XANi/goneric/blob/master/slice.go#L106 * [3] https://github.com/XANi/goneric/blob/master/parallel.go#L15 https://github.com/XANi/goneric/blob/master/parallel.go#L15
- valenterry 4y agoNo it's mostly just the blub paradox. You don't feel the pain because you didn't use some features/techniques of other languages that don't exist in Go. It's the same everyone. I, for example, never felt I was missing something until I learned about type providers. Now that I don't work in a language that supports them, I hate it. If I had never learned about them, I would probably never miss em.
- randomdata 4y agoHe didn't express a lack of pain, just that he was never in a situation where he was stumped by not having them. Generics aren't exactly magic. They can improve code, but you can live without them if you really have to. Although I think you are on to something per the original question about the appeal of Go. For all its faults, Go also gets a lot of things very right that aren't obvious until you have gained the necessary level of familiarity. Once you rise above 'blub', it is indeed hard to go back. While I spend most of my days in other languages full of all kinds of fanciful features, I did a short stint on a Go project and now especially hate not having blocking functions everywhere (async/await is one of those fanciful features I have to deal with) and sensible error handling.
- valenterry 4y ago> He didn't express a lack of pain, just that he was never in a situation where he was stumped by not having them. I mean, isn't that the same thing? You don't know you are "stumped" if you never experienced it. That's what I mean by "feeling the pain". > Generics aren't exactly magic. They can improve code, but you can live without them if you really have to. Of course - that's true for essentially any language feature. We can all use assembly if we have to, but I think that's missing the point of why OP asked. > Although I think you are on to something per the original question about the appeal of Go. For all its faults, Go also gets a lot of things very right that aren't obvious until you have gained the necessary level of familiarity. Sure, I mean: if you always used a language with an unergonomic and non-integreated builtsystem, you probably won't feel the pain or won't feel it as much as when coming from golang. That would be blub the other way around. Worse: the more languages (that are actually different) you have used, the more unhappy you are with every single existing language.
- somethingreen 4y agoOn one hand, the bar for things to be called bad has now dropped pretty low. Being not as excellent as other thing, or not being excellent throughout is enough. But I think the actual hate isn't coming from Go technical shortcomings. It's language authors and community attitude towards people asking for obvious QoL improvements. Generics are a bad enough example of community for years tactfully flipping off everyone asking for them and then, hey, here they are and the sky doesn't seem to be falling. But it's not the only example. Just a couple days ago I was researching if there's a way to somehow build struct tags from constants or use interpolation and sure enough, there's an old bug tracker suggestion entry that got a two sentence "won't do" reply with zero reasoning and a bunch of following entries just marked as duplicate and closed without reply at all. This happens a lot. And people don't appreciate it.