This will finally let me make the monad library I've been dreaming of for years. Be afraid.
A monad library in go can really on have one name… …
Go: Support for Generic Methods
111–120 of 288 posts
Re: Go: Support for Generic Methods
#112Earlier quoted context omitted.
Doesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing?
An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient. Representing it as 1000 separate 1000-elemen…
Isn't an array of arrays by definition the sequential implementation?
Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be.
They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array.
Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.
Re: Go: Support for Generic Methods
#113Earlier quoted context omitted.
Rust is technically older than Go, but who was actually using it when Go 1.0 came out in 2012? Rust 1.0 wasn’t until 2015.
The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0.
Do you just forget the things you write in earlier comments?
> Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing
Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language.
Rust barely existed at the time Go was first being developed. And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages, it’s extremely unlikely that Pike et al gave more than a cursory glance to what nascent Rust was doing at the time.
But even if they had, to suggest that they intentionally replicated a dumb thing from C but gave it a different name to avoid users being confused by a different thing from a language that roughly nobody knew about at the time is bananas.
Re: Go: Support for Generic Methods
#114Earlier quoted context omitted.
Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap". There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stret…
Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless. Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped thems…
> Nil exists in C and is widely considered to be a massive mistake in the language.
You're almost there, but it is wildly considered to be massive mistake in context of arrays. C has weird array semantics that are confusing and hard to get right, even for seasoned developers. That is where NULL comes to bite people time and time again. Go did not inherit C's arrays. Neither did Javascript. They go out of their way to avoid what C did. In Go, you can come close to the same semantics if you use the unsafe package, but take note the name.
Yes, they still have nil, but the scope is tightly constrained and while it is technically possible to misuse, you have to try pretty hard to do so. There are many other things that are more likely to end up being misused. Those would be the more massive mistakes.
> But Go could have been better.
Obviously. Every language ever created can be better.
Re: Go: Support for Generic Methods
#115Earlier quoted context omitted.
Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless. Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped thems…
> Nil exists in C and is widely considered to be a massive mistake in the language. You're almost there, but it is wildly considered to be massive mistake in context of arrays . C has weird array semantics that are confusing and hard to get right, even for seasoned developers. That is where NULL comes to bite people time and time again. Go did not inherit C's arrays. Neither did Javascript. They go out of their way t…
> You're almost there, but it is wildly considered to be massive mistake in context of arrays.
From Tony Hoare: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
Odd that he wouldn't mention the word "array" anywhere in that quote.
> Yes, they still have nil, but the scope is tightly constrained and while it is technically possible to misuse, you have to try pretty hard to do so.
Like by not remembering to check if a pointer is nil? Or actually comparing one typed nil to a different typed nil?
> Obviously. Every language ever created can be better.
Only one of us is arguing that reimplementing C’s mistakes is actually a good thing.
Re: Go: Support for Generic Methods
#116Earlier quoted context omitted.
> I personally can’t wait to see what next development will never have been “against the Go philosophy” and definitely not something that gophers argued was perfect the way it was any time misguided malcontents and rabble-rousers wrongly tried to suggest the language wasn’t perfect the way it was. I really hope it is more ergonomic error handling. Or maybe sum types/discriminated unions.
> I really hope it is more ergonomic error handling. They've publicly said no more language changes specifically for better error handling are coming, it will at most be the library-level improvements.
So this would be in line, then, with all of the other features they’ve publicly said aren’t coming and aren’t necessary but then do anyway after retconning their original stance?
Re: Go: Support for Generic Methods
#117Earlier quoted context omitted.
> Nil exists in C and is widely considered to be a massive mistake in the language. You're almost there, but it is wildly considered to be massive mistake in context of arrays . C has weird array semantics that are confusing and hard to get right, even for seasoned developers. That is where NULL comes to bite people time and time again. Go did not inherit C's arrays. Neither did Javascript. They go out of their way t…
> You're almost there, but it is wildly considered to be massive mistake in context of arrays. From Tony Hoare: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking perfo…
> Like by not remembering to check if a pointer is nil?
Rule of thumb is to not introduce values that aren't valid. Equally, don't put in -1 for an age value, even if the language allows you to. You might later forget to validate that the age value is valid.
Yes, mistakes are possible, but these types of mistakes are pretty rare. There is some value in eliminating the possibility of those mistakes, sure, but we cannot pretend that it comes cost-free. There is good reason why almost nobody uses Rocq.
> Or actually comparing one typed nil to a different typed nil?
This is something that is likely to confuse, but not a facet of nil. It is related to interfaces. Let's not flail around like one of those wacky blow up things at the used auto lot.
Re: Go: Support for Generic Methods
#118Earlier quoted context omitted.
> I really hope it is more ergonomic error handling. They've publicly said no more language changes specifically for better error handling are coming, it will at most be the library-level improvements.
So this would be in line, then, with all of the other features they’ve publicly said aren’t coming and aren’t necessary but then do anyway after retconning their original stance?
Could esteemed commenters please read the words the Go language team actually wrote?
> Or, we could decide that parameterized methods do not, in fact, implement
interfaces, but then it's much less clear why we need methods at all. If
we disregard interfaces, any parameterized method can be implemented as a
parameterized function.
> So while parameterized methods seem clearly useful at first glance, we
would have to decide what they mean and how to implement that.
Re: Go: Support for Generic Methods
#119Re: Go: Support for Generic Methods
#120Earlier quoted context omitted.
No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…
> term “systems program” has always meant network middleware that shuttles around JSON and transforms it. Who are we that has always defined that term that way. For any systems programmer golang has pretty much not been a solution. Systems is below layer 4 of the network stack, it is building the network stack in the first place.
Um, there is user-level implementation of TCP/IPv4+IPv6 stack in Go [0], developed and used by Google as part of its gVisor.