One question: As far as my knowledge told me, anything (or most?) interface{} in Go will be put to heap instead of stack. Will generics change that?
I really want to utilize those 2~4K stack spaces for the routines.
Go 2, here we come
361–370 of 534 posts
Re: Go 2, here we come
#362Earlier quoted context omitted.
I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…
Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most c…
It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.
Re: Go 2, here we come
#363Earlier quoted context omitted.
I'm hoping things like generics can just be accepted to be a good idea moving forward and that we can all agree that languages without them are handicapped. I still fell things are up in the air about exceptions but maybe we can just agree on generics which would make me feel better. Using go without generics just felt insane to me...
Yeah, Go has some really fantastic aspects around tooling and a good concurrency story, but it's otherwise such a huge step backwards. I can't fathom the reason for not having generics. It's such a simple, completely common-sense abstraction. Things like typeclasses or multimethods offer vastly more abstraction power. These are (a bit) more difficult to understand, but you certainly don't have to be a genius (take it…
s/genius/masochist/g
Re: Go 2, here we come
#364Earlier quoted context omitted.
hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.
> direct usage of syscalls instead of libc Why do you want to use libc for Go? You wouldn't use the Rust standard library for Go, why the C standard library?
It is very common for language runtimes to link and depend on libc on Unix, even if the libc API is not directly exposed in those languages. Go is somewhat unusual in this regard.
MacOS doesn't guarantee backward compatibility for direct syscalls. This has caused bugs like this with compiled Go binaries:
https://github.com/golang/go/issues/16570
Go has very recently started using libSystem (which is analogous to Linux libc or Windows CRT) on macOS to avoid this issue.
On a more philosophical level, POSIX is defined in terms of a C standard library, and not using libc means Go doesn't support and/or must implement itself various features that are otherwise provided to POSIX applications by the system (like locale handling). Your mileage may vary in terms of whether that's a bad thing or a good thing.
Re: Go 2, here we come
#365Earlier quoted context omitted.
I agree heartily that context is viral in APIs, but would argue that that's essential to the nature of context. Accordingly: implicit association of context with a goroutine would introduce a complementary API virality issue: you now need need to worry about whether anything above or below you starts to delegate their work to separate goroutines.
Not sure what you mean here. How does an implicit context change any semantics? You would still be able to override which context is given to goroutines you spawn. As a developer, you'd have to be aware of the implicitness, that's the only difference.
I agree it doesn't change the semantics, and that you can express the same set of programs (given that you still let people explicitly handle contexts, send them over channels, etc). I just mean to highlight that removing context-usage information from go function signatures does not mean that usage or non-usage of context isn't part of a function's API—it's just now global state, and needs to consider its interactions with everything else in the same routine (instead of everything lexically in scope).
Re: Go 2, here we come
#366Earlier quoted context omitted.
I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large ch…
It's people that have seen the abuses of C++ templates. They're very powerful and therefore people tend to want to use them for really complicated things. Look up things like SFINAE and compile time metaprogramming. Templates were not intended for those things. When they work they're ok, but if they go wrong good luck following the 10 line error message. Here's an example from Rust: https://www.reddit.com/r/rust/comm…
Any sufficiently advanced type system can be used for compile-time metaprogramming - that's just an inevitable side effect of a type system expressive enough to capture all the more convoluted (but still plenty common) cases without hacks like interface{}.
Re: Go 2, here we come
#367Earlier quoted context omitted.
Languages are products as well, either they grow to fulfil the needs of their customers or their fade away.
What if the need is for a small language without generics?
In what context would “need” a language to not have generics? I can understand not “wanting” generics to keep it simpler, but I can’t see that as a “need”.
Personally, in any typed language, I want generics, not having them feels very limiting.
Re: Go 2, here we come
#368Earlier quoted context omitted.
Don't be stupid. A "decimal" type is a floating-point number, just with a different base. It solves none of the underlying problems. (Which is why, incidentally, nothing made in this millennium supports it.)
It’s been a while since I COBOLed, but if I recall, the COBOL decimal is similar to Currency types in languages like C#. (Maybe I’m misremembering.) If I’m right, though, it’s not a floating point number. It’s currency properly handled via integer math under the hood.
In C#, there's a "decimal" type. Which is exactly that - decimal floating-point. However, one catch about it is that it doesn't allow for the exponent that would place the decimal point somewhere outside of the representable digits of the number (i.e. unlike floats, the difference between any two decimals is never more than 1).
But it's still plenty useful, because it allows to accurately represent decimal fractional numbers, which is exactly what's needed in many domains, since humans work with decimal fractional numbers. Representing money would be one particular example.
Re: Go 2, here we come
#369Earlier quoted context omitted.
As a beginner, I really like rust. It has excellent package management, robust compiler messages, pattern matching... etc. But once I start trying to build non trivial data structures it becomes a nightmare. For example, doubly linked list, any sort of graph is extremely hard for me to build in rust but extremely easy to build in golang. I am still learning the full capability of rust, hopefully as I do more practice…
You're not the only one having trouble writing basic data structures in safe Rust: [1] [1] https://rcoh.me/posts/rust-linked-list-basically-impossible/
Of course, if you're comparing with Go, you need to compare apples to apples - since Go doesn't have ownership tracking, the equivalent Rust would necessarily have to be unsafe.
Re: Go 2, here we come
#370Earlier quoted context omitted.
I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.
Despite most of my professional programming being in Go nowadays, I am extremely sympathetic to the Haskell/FP way of thinking about things, and trying to make invalid state unrepresentable. However, having made the mistake a few times now of trying to use "unsigned ints" for things that I want to assert are never negative, I've learned the hard way not to do that. The problem is, there's always some bug you have in…
> if this int or uint under or overflows, throw an exception
Overflow flags are supported on some architectures, so it would really just be a matter of checking that flag.