381–390 of 396 posts
Earlier quoted context omitted.
the part of your sentence before the comma is not fully related to the part after it. iow, the first part does not imply the second part. a lang could have a trustworthy future for maintenance of existing apps, like in terms of support from vendors, while not being a very good choice for greenfield applications, due to not having modern language features and libraries. but there is so much cobol in critical infrastru…
[flagged]
Thank you, rsc, for all your work. Development in Go has become much more enjoyable in these 12 years: race detector, standardized error wrapping, modules, generics, toolchain updates, and so on. And while there are still things to be desired (sum types, better enum/range types, immutability, and non-nilness in my personal wishlist), Go is still the most enjoyable ecosystem I've ever developed in.
> non-nilness Ah, I still remember this thread: https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
Ouch, who were they asking? There are so many problems from even the most simple CRUD apps where "lack of a value" must be modelled, but where the zero-value is a valid value and therefore an unsuitable substitute. This is probably my single biggest pain point with Go.
Using pointers to model nullability, or other "hacks" like using a map where keys may not be set, feel completely at odds with Go's stated goal of high code clarity and its general disdain for trickery.
I know with generics it's now trivially easy to implement your own Optional wrappers, but the fact that it's not part of the language or even the standard library means you're never going to have a universal way of modelling this incredibly basic and common requirement across projects. It also means you're never going to have any compile-time guarantees against not accidentally using an invalid value—though that's also the case with the ubiquitous (value, error) pattern and so is evidently not something the language is concerned with.
Earlier quoted context omitted.
While vendoring is great, generics is bad addition to Go, since they complicated Go type system too much [1]. This makes typical Go code with generics hard to read and hard to maintain. [1] https://go.dev/blog/type-inference
Language was literally castrated without generics.
Earlier quoted context omitted.
The responses from Ian and the Go fans are not very well-thought. To begin with, zero values were never a great idea. It sounds better than what C does (undefined behavior), but zero values can also hide subtle bugs. The correct approach is to force values to always be initialized on declaration or make use-before-initialization an error. Having said that, it was probably too late to fix zero values by 2009, when Go…
If there's a non-nullable type, then there's types without zero values, and that means some basic properties of Go no longer hold. I don't know how many times that can be said differently. Whether something is in a struct or not is not relevant.
Earlier quoted context omitted.
If there's a non-nullable type, then there's types without zero values, and that means some basic properties of Go no longer hold. I don't know how many times that can be said differently. Whether something is in a struct or not is not relevant.
What basic properties no longer hold?
Earlier quoted context omitted.
> it's always been someone breaking something or something along those lines Not only is this a complete lie, but God forbid there's a process in place to catch these things instead of verbally abusing your coworkers for making mistakes, which Linus has done himself. > Imagine every outburst you have is public and pointed to for years to come You may be surprised to learn that the rest of us don't talk to anyone like…
> You may be surprised to learn that the rest of us don't talk to anyone like this. The moral superiority is misplaced: https://news.ycombinator.com/item?id=41017195 But I am not surprised. CoC proponents universally do the same as the people they criticize. Only the application of rules is selective.
Wild that you both made an account for this and dug through my comments just to comment on a comment on an article you didn't read.
Earlier quoted context omitted.
> it's always been someone breaking something or something along those lines Not only is this a complete lie, but God forbid there's a process in place to catch these things instead of verbally abusing your coworkers for making mistakes, which Linus has done himself. > Imagine every outburst you have is public and pointed to for years to come You may be surprised to learn that the rest of us don't talk to anyone like…
> You may be surprised to learn that the rest of us don't talk to anyone like this. You do. By outright claiming that I'm lying when I share what I've seen. Of course with no substance to back it up. Let me tell you: I've seen what I've seen. Have I seen an incomplete picture? Almost certainly. Am I wrong? Perhaps. Am I lying? No. Your post is extremely aggressive, pretty darn toxic, and explicitly the sort of stuff…
> Only those instances make the news. And then get repeated time and time again. It's a super-biased view not at all representative of his day-to-day behaviour.
You certainly can't represent your post as "I've only seen what I've seen" with that opener. You were claiming the OP was spreading misinformation. That is the lie. Which is why I provided an instance of Linus's tirades that doesn't match up with what you said.
Don't call someone "super-biased" and then be surprised when people don't roll over for you.
> Your post is extremely aggressive, pretty darn toxic, and explicitly the sort of stuff that's not appropriate here.
It's ironic that my mild comment is upsetting you while you defend a mans right to say his employees should've been aborted. Is it just because he's famous? Or because you think the employees were being stupid? Have you considered that "doing stupid" is a subjective assessment that people use as a cudgel to act poorly? What if I thought you were doing stupid, could I say the things Linus says?
Here's some more for you: https://lkml.org/lkml/2012/7/6/495
Earlier quoted context omitted.
This argument is brought up again and again, but it is just wrong. Go had both generics and iterators from the get go. Just not user defined ones. Thus it is obvious that the creators of the language always saw their need for a simple and productive language
Go provides generic types since v1.0 - maps, slices and channels. Go also provides generic functions and operators for working with these types - append, copy, clear, delete. This allows writing clear and efficient code. There is close to zero practical need in user-defined generic types and generic functions. Go 1.18 opened Pandora box of unnecessary complexity of Go specification and Go type system because of gener…
Thanks for your leadership of the Go team over the past 12 years, and for your patient comments and guidance on our proposals and PRs.
Best wishes for the future, and hope to see you in the community again.