I know the comments aren't meant for silly jokes but I'm very disappointed that there's no "Go 2 Considered Harmful" jokes here
This is a awesome joke. Thanks for the laugh.
Go 2, here we come
381–390 of 534 posts
Re: Go 2, here we come
#382Earlier quoted context omitted.
I like how Haskell does it. When you simply write a number like "3" it will infer the type to be "Num a => a" which means it could be any type you have loaded that defines the functions in the typeclass Num: class Num a where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a "3.0" would be "Fractional a => a" which means it defines the…
This is a great system for tying in new number types with existing ones, but the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me. Coupled with the fact that so many standard functions (like length, for example) want to return an Int rather than an Integer, it just leads to me spewing ((fromIntegral ___)::Integer) all over my c…
If you don't like the automatic cast, you can always manually cast inline by doing (3 :: Int). I've used this a number of times when doing numeric stuff in Haskell.
Re: Go 2, here we come
#383I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
This was one thing COBOL got right: built in support for a DECIMAL data type.
Fixed – Fixed-place decimal math library for Go (github.com)
https://news.ycombinator.com/item?id=18559625
Re: Go 2, here we come
#384I know the comments aren't meant for silly jokes but I'm very disappointed that there's no "Go 2 Considered Harmful" jokes here
There's this[0] one from 10 hours ago, but it's pretty buried by actual discussion at this point.
Re: Go 2, here we come
#385Earlier quoted context omitted.
I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing
Except length/cap/index are always positive, so I think int was a mistake here.
I think that the rationale for using int for array indices and lengths and so on is to avoid shooting yourself in the foot with wrap-around arithmetic (again, my thesis being that when 99% of people use integers, they expect them to behave like integers and not wrap)
Take for example code which finds consecutive differences in a list, something like
for i := 0; i So this is the rationale for using signed integers rather than unsigned integers. I think the language semantics should go further, and use true integers pretty much everywhere. Note that the compiler could still easily see that the index variable in the loop above is bounded, and use a machine word under-the-hood. But the programmer only ever has to think about well-behaved integers.
Re: Go 2, here we come
#386Earlier quoted context omitted.
"As for all the folks claiming they'll leave Go if it gets generics" Baffled at this claim I searched and found one person who really seemed to be saying "if Go changes dramatically...". This recurring notion that Go fans are anti-generic is not rooted in reality. Instead they simply didn't buy the "either it's there or the language is useless -- generics or bust!" argument that pops up in every Go discussion. It's a…
I don’t know about threatening to leave Go, but I’ve definitely seen a lot of posts claiming Go is better without generics.
The more nuanced and better side of that is that any language is better without badly designed and badly implemented generics.
Re: Go 2, here we come
#387Earlier quoted context omitted.
> 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 Linu…
> It is very common for language runtimes to link and depend on libc on Unix
It is, and this is where you have to choose between a fragile executable that linked to a specific vendor and version of libc (glibc, musl, etc.). or a bloated executable that statically links it.
> MacOS doesn't guarantee backward compatibility for direct syscalls.
Sounds like Go should use the stable API MacOS does offer. If the stable API is libSystem (different than libc), then so be it.
But if we're talking about Linux libc, there's no reason for Go to use it.
> POSIX is defined in terms of a C standard library
Specifically POSIX.1 (not POSIX.2).
Also, for what it's worth, POSIX compatibility falls short of Go's goals for compatibility. Specifically, on Windows. So I'm not sure what there is really to gain by following a different language standard for a different set of platforms that you desire to support.
Re: Go 2, here we come
#388Earlier 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…
I'm of 2 minds. I come from a Java background so I've personally wanted generics. ORM's are 1 use case that comes to mind. But . There are many modern languages that already have generics. Why can't Go be that one that doesn't cave in and remains powerful in its niche and perhaps may never be the preferred tool in other areas? Why must it be useful for web development, microservices, DAL, etc.? Any implementation of…
As someone who quite likes generics, I'd love to see how a modern strongly-typed language solves problems without them. And I think that's what the Go community and developers have been trying to do up until now. It looks like they're giving up. I'm not sure whether we'll ever find another way to tackle composition/scalability as effectively as generics do, but such a technique would be fascinating to see.
Re: Go 2, here we come
#389Earlier quoted context omitted.
This is a great system for tying in new number types with existing ones, but the lack of explicitness about casting exact types (Integer, Rational) to inexact types (Int, Float) has led to many bugs and confusions for me. Coupled with the fact that so many standard functions (like length, for example) want to return an Int rather than an Integer, it just leads to me spewing ((fromIntegral ___)::Integer) all over my c…
If you don't like the automatic cast, you can always manually cast inline by doing (3 :: Int). I've used this a number of times when doing numeric stuff in Haskell.
I do know how to manually cast, although in my case I'm usually casting to Integer. I was arguing that a cast from Num to Float, Double, Int etc is a lossy operation, and breaks the semantics of arithmetic, and so should not be done implicitly.
Re: Go 2, here we come
#390Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…
Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.
(Disclaimer: at Google)
My team has ~200k lines of Go code and I'm exceedingly happy with the state of the codebase. Having previously maintained a C++ codebase of similar size, I can say that the pace of changes is higher, the effort necessary for large scale refactorings is lower, and our ability to reason about the system is similar.
A few examples:
- Refactorings are simpler due to the use of consumer-side interfaces. Say you want to inject an in-memory cache above a backing store. To do that you probably have to change the constructor and provide an implementation matching the 2-4 relevant methods. That's it.
- Tracing code is slightly worse, due to having to track callers through said duck-typed interfaces, but on the flip side multi-threaded code is sufficiently simpler to reason about that I call it a wash. Having previously had to do threading in the form of "control flow" state machines, and then fibers (which were better but not perfect, and still aren't widely available), Go constructs are great. Locks where appropriate, channels where appropriate, overall very fast and clean code.
- Performance is good, and reliable. Not as good by cycle-count as C++ - and e.g. the comparable RPC libraries are definitely less mature than Google's very-well-kicked C++ libraries - but on the other hand it scales almost linearly. We started a system at ~5 cores/task under AutoPilot, and then when we next got around to adding more tasks it was peaking at ~60 cores/task at essentially the same per-core throughput. I've never managed to write a C++ server that can accidentally scale concurrency by >10x without hitting _some_ bottleneck.
- We use Go for ~everything. Server code, definitely Go. Client tools, also Go. Simple scripts, bash until they need their first 'if' or flag or loop, then Go too.
- I'd prefer real generics to interface{}, but the number of places it comes up is minimal enough that it's no more than a minor annoyance.
I can't speak to the issues of package management - we dropped compatibility with Go's native package structure fairly early on and went all in with blaze/Bazel (http://bazel.io) to coordinate builds and dependencies and whatnot, and haven't had reason to try modules yet.