Go 2, here we come | Hacker News Reader

Go 2, here we come

blog.golang.org

816 pointsmdelias516 comments

I’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-level data structures like lists, hashtables, etc are content to just leave us with the bare minimum support of numbers, being basically whatever the hardware thinks a number is. The semantics of integers and fractions are perfect, and everybody already knows them. On the other hand, overflows in int32’s are weird, and if your idea of a fraction is a floating-point number, then you can never have something like (5/3)*6 evaluate to 10 exactly.

To be clear, I think fixed-width integers and floating-point numbers have their place, I just see no reason why they should be the default.

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 functions in the typeclass Fractional (in addition to being a Num):

    class Num a => Fractional a where
      (/) :: a -> a -> a
      recip :: a -> a
      fromRational :: Rational -> a

Depending on how you use the value, the type would be further refined in compile-time. For example, if you did `recip 3`, 3 couldn't be any Num anymore, it would have to be some Fractional.

Regarding (5/3)*6, it does equal 10 using floating point. A better example would be how 0.1 + 0.2 is not equal to 0.3. We can see this:

    ghci> 0.1 + 0.2 == (0.3 :: Float)
    False

If we specified that we're working with Rational values, which are also Fractional a => a, and which are defined as a pair of integers, one representing a numerator and the other a denominator, roughly like so:

    type Rational = Ratio Integer
    data Ratio a = a :% a

then we can see that 0.1 + 0.2 does equal to 0.3:

    ghci> 0.1 + 0.2 == (0.3 :: Rational)
    True

It's pretty cool that Haskell lets you define new types of numbers and use them like any other. While you can transparently support hardware type numbers, represented by types like Int, Float, Double, Word, Word8, Word16, Word32, Word64, you also have transparent support for arbitrary precision Integer and Rational. Writing your functions to work with the typeclasses like Num and Fractional lets your functions work with any of these types and future types defined.

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 code.

I love all of the automatic casting between exact types, but happily implicitly casting to inexact types is (in my opinion) a big mistake.

> [...] 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.

What do you mean? As far as I'm aware, you always have to explicitly convert exact types to inexact types in Haskell (using "fromIntegral" and "realToFrac").

> 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 code.

Indeed this is rather annoying. It's this way because of legacy reasons (see https://www.reddit.com/r/haskell/comments/60u10b/do_function...).

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.

Makes no sense to me to redefine existing integer types. Why not introduce a primitive type "num" for arbitrary precision rational numbers instead?

As a long-time Racket and Scheme user, I'd say that arbitrary precision numbers as default bring more disadvantages than advantages. As an option with syntax support Yes, but not as a default. it just makes it harder to port all kinds of code that relies on modulo arithmetics.

> it just makes it harder to port all kinds of code that relies on modulo arithmetics.

If you're relying on modulo arithmetic, you should be using a fixed size integer anyways, not one that varies based on the architecture. Go has fixed size integer types available, and modulo arithmetic should be using those, not "int".

I'm not sure how these two are related. Why would you mix modulo operations and fixed size? Modulo on an arbitrary bigint is perfectly valid and useful.

Modulo arithmetic refers to the property of fixed-size integers where they will predictably wraparound in expected ways if you overflow or underflow them. This wraparound is "free", so it used to be commonly used for cyclic high performance code. An arbitrary bigint is computationally more expensive, and it will never experience this effect, so it's a double whammy of irrelevance for bigints. You can manually do a modulo operation on a bigint, but that just makes them even more computationally expensive than a fixed size int, requires more code, and would be considered an unnecessary inconvenience by most people who care about modulo arithmetic.

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead?

Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.

This argument falls flat for me. Classes aren't supported natively by processors either, yet any number of OOP languages use them.

It's generally nice when you can do simple things with the language's built-in standard library. I tend to prefer languages with more powerful standard libraries because it means that you can more easily move across codebases since they'll all be the same. If commonly used data types like rationals, hashes, maps, strings, etc., aren't defined in the stdlib, then there'll be any number of different libraries to use them, and you'll have to potentially re-learn a lot of different unnecessary things when working on different codebases.

It's like building in special handling for a string type, exactly one instead of a catalog of library options.

I'd say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of "minimalism" would be providing tools to allow libraries to define what other languages can only support as special builtins. C++ and Scala went down that road, they minimize builtins by empowering libraries to replace them. That's also a form of minimalism, but not the one chosen by Go.

Tangent: now I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type it inherited from Java or if just reimplements those syntax extras in the standard library using implicits.

"X isn't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it" is a general-purpose argument to cherry pick which primitives you support and which ones you don't. Surely this isn't your actual reason you choose to oppose Rationals / BigIntegers as primitives while accepting hashmaps and arrays?

Arrays, slices, hashtables, and channels are not supported natively by the processor, but Go still has them as primitives. Why not also add a number type which behaves in a sane, easy-to-understand, useful way?

Scheme has an explicit minimalist philosophy, so much so that when R6RS was released with too many conveniences it fractured the language and community. Now there's two specs, R7RS-small and R7RS-big, and they're far less popular than R5RS.

Rationals are also the default number type.

Lists are the base type used throughout Scheme, and can be used to implement arrays and hashmaps and whatnot, so Scheme doesn't really need them, you can just use a library.

... That didn't stop the committee adding types to the spec. Like records, promises and other complex types.

What is useful and necessary to a language isn't defined by what the processor can natively do, or we'd only use registers, not arrays. And it isn't defined by a overbearing attitude towards one or more philosophies.

This is reminiscent of 'numeric tower' discussions from years ago.

I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that is crazy and I can’t think of any useful use case for it. If it’s not the case then please explain me what that proposal is really about...

"int" in Go the native index type for arrays. I consider it an error to use it for anything else, and since I've adopted that policy, I've had no particular problem with ints.

Probably a good linter idea in there somewhere.

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 the program that will drive the uint "negative", wrapping over to a huge number. Unfortunately, since you get no warning when that happens, it tends to take longer to show up, and without a clear cutoff to say "ah, this is clearly invalid" it can be hard to even program detection code, whereas checking for "less than 0" can be unambiguous.

I'd loooove it if I could easily, cheaply, and universally (i.e., not just in Go, but across all my programming languages) turn on a behavior that says "if this int or uint under or overflows, throw an exception instead of trying to do whatever stupid thing you're going to do". I get the sense this is heading down the road where in 20 or 30 years, this is just going to be common sense. However, we are very early on the road yet from what I can see. Whenever I bring it up, even today, even in this sort of context, it still is generally negatively received. (But not uniformly. A few other people agree. I think momentum is with me. I'm not sure my programming career will live long enough to see it, though.)

Using unsigned indexes would be fine if the program automatically throws an error on wrapping. Otherwise, it’s an accident waiting to happen, since you have to code all of your arithmetic keeping in mind the fact that the numbers are trying to blow up in your face.

If x is unsigned, then you can’t rearrange an inequality like x >= 4 into x - 4 >= 0, since the first inequality is only true sometimes, whereas the second is true always. This looks obvious, but bury it a little way into some nontrivial index arithmetic and boom.

Another more aesthetic reason is that indices can represent offsets into a structure relative to some other index, and in this case you really need negative numbers.

In general it is nicer to use signed numbers for indices. The actual index can't be negative, true, but differences between them can, and it means you don't have so many dubious sign conversions.

Because you want to represent errors. For example a find() function that returns the index of some element: you want to return -1 when the element doesn't exist.

> I'm curious what the motivation was to use int instead of uint considering indexes cannot be negative in Go.

I want to emphasize that I do not know the true answer to this question.

I think that indexes are int to play nicely with a decrementing loop counter. Doing:

    for i := len(n) - 1; i >= 0; i-- { fmt.Println(n[i]) }

requires i to be signed due to the last iteration.

Crazy indeed. This was like lessons learned #2 from C, which later introduced the stdint types int32_t et. al.

A modern language with this type of confusing and platform dependent behavior is inexcusable. By all means, include a native data type as big as the processor can handle (size_t), but don't call it int which is the default data type most people will use out of pure laziness.

Which would you choose instead? To default to 32 bits (even on 64 bit systems) or to default to 64 bits (even on 32 bit systems).

Defaulting to 64 bit math on 32 bit systems will have a huge performance penalty on generally the slowest/oldest systems where this penalty is least desirable. It's not clear to me what the benefit to this would be for most programs.

Running 32 bit ints on 64 bit systems will cause problems handling large arrays on systems with a lot of memory. I think it also complicates generating efficient loop code, although C++ gets around this with signed integer overflow being "undefined behavior".

Of course Go has int64 and int32 types if you want to use them (and all conversions require explicit casting), but the default type for array lengths etc is the platform native type. But what is the better alternative?

I would use int and long like in C# for example, with no magic int that can be 32 or 64 bit depending on the platform to avoid any confusion.

And as a result of this, you can't have a 3GB byte array in C#. I think there needs to be a big benefit to make hard-coding a restriction like that into the language worth it.

Unfortunately I've read every comment in this HN thread (so far) and I haven't found any specific one mentioned, just people calling it "crazy" and "confusing" over and over.

Go is a language that has explicit pointers! And of course those can be 32 or 64 bits and change struct sizes, field offsets etc. There are certainly things about Go that are confusing but I've never thought this was one of them.

Just FYI Go has int8, int16, int32, int64, and int types. Only the 'int' type is the machine-native one. It's always been obvious to me that 'int' is the one without a fixed size, but I think this would be less obvious if the naming convention was different using short, int, long etc.

The subset of Go users who deploy on 32bit hardware in 2018 and care about performance at that level, is likely to be vanishingly small.

Its not crazy, its defined by the system ABI, C, C++ has this too in that can be whatever depending on the ABI, hell char can be 32 bits.

It may be crazy but it's not exactly without precedent. Neither C nor C++ fix the sizes of the fundamental integer types, although for backward-compatibility reasons popular 64-bit platforms still have 32-bit `int` and even `long`. But yeah, there's a reason eg. Rust has no `int` and friends but `i32` etc. instead.

Rust has a `usize` which is 32 or 64 bits depending on the platform and also serves as the native index type for arrays and such.

Right, 64-bit Windows has 32-bit int and long and 64-bit long long (LLP64) while 64-bit unixes generally have 32-bit int and 64-bit long/long long (LP64).

C only defines char, short, int has having a minimum size of 8, 16 and 32 bits.

You are not crazy, and it's what makes this proposal even more appropriate than other languages. "int" is already a magic type.

Yeah, sounds crazy. It only worked for C for 40+ years...

Ignoring the basic int type and using a zoo of preprocessor defines instead is what has worked for C all that time.

But I still think that native types have their place. It can often be quite reasonable to accept serious limitations on narrow machines where the performance gains won by the trade-off are desperately needed, lift those limitations on wider machines and grant an enormous safety margin on the widest architectures. When you dive deeper, the values where this makes sense still tend to be "index-like", as GP stated, but they don't have to strictly be indexes (e.g. IDs, a wider machine will be capable of working on bigger datasets and therefore be more likely to exhaust a given width of IDs, all indexes are identifiers but not all identifiers are indexes)

And what percentage of programs written in those 40 years are actually able to run on systems with more than one or two different memory layouts?

Why is that a problem? There's int8/16/32/64 for when you need to be specific.

I don't know how many times I've been writing a program using int, then suddenly I have to do some math on the index of a range (for example), and the math.* functions require int64. I start casting to int64, but things get infected and it spreads. Eventually I refactor everything to use int64 and wonder why int can't just be an alias for one of the others. Personally I would make it int64, since that is what the standard library thinks math should be done with.

Odd, I've rarely had this issue, and almost never need to do complicated math on the index of a range (maybe "multiply by two and add one" kind of stuff, but nothing from the "math" pkg). Also, note that the math.* functions all use float64, not in64.

Yes, you're right float64 in the math package. So I've definitely run into this with float vs float64.

As for the int vs int64, I definitely run into what I describe on Project Euler. Probably using a self referential map[int]int when I need to suddenly pull an int64 and everything gets infected.

I realize it's just a matter of convenience for me, but I personally have no downside to int == int64.

Meh I use C# and I rarely need an int bigger than 2147483647, and if I do I use a long which gets me up to 9223372036854775807, and if I need more than THAT then I'll use a math library of some sort.

I think the question though is that if “int” were an actual integer, would you still default to using int32/int64, and for what reason? There are valid uses for fixed-width types, but beyond domain-specific number crunching (crypto, image processing, etc) I would argue that the use of these types is technically incorrect, and not what people expect. Even experienced programmers will see “x > x + 1” and mentally replace that with “true”, even though if x is fixed-width, the value of that expression actually depends on x.

The problem with overflow isn't just needing to store numbers larger than 2 billion. Sometimes, intermediate values are larger than that even if the final result isn't.

Take averaging as a very simple example. Doing (a + b) / 2 will overflow if a and b are sufficiently large, even if the average will always fit in 32 bits. Things like this go unseen for years.

don't most people compute the mean iteratively when they need to do this? Sure, it goes unseen, but programmers on systems like this are expected to understand the math model and write tests.

I get you point. I'd probably go float/double precision for that task.

There have been 1,543,530,695,158 milliseconds since epoch.

That would fit into a spacious Int64.

I typically wouldn't be passing around milliseconds since epoch as an raw number, but then that's C#, I guess you might do that in other languages for performance or out of necessity.

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

It's a perfectly reasonable niche use case for achieving maximum performance.

My main issues with it are:

1. Like many other performance optimizations, it is a trade-off. You may be sacrificing easy maintenance or even introducing breakage (if the person using it doesn't understand the limitations and implications). So IMHO you should only do it if you can show through profiling, etc. that the gain is real and worth it.

2. As a matter of language ergonomics, it should never be something that anyone does unknowingly. You should have to explicitly ask for it. The type name should be something blindingly obviously like "native_int" or "word_int".

Even Swift who’s mantra is do nothing unexpected or implicit has a machine dependent (word sized) Int type.

You’re trading off security here. Users are going to shoot themselves in the foot assuming that int is this size or this size.

People have traditionally wanted to use the maximum sized type that can fit in a register.

More precisely: they wanted the integer type that was large enough and ran their code fastest.

On CPUs with 64-bit and 32-bit registers, that typically is the register-sized integer type. Machines with 16-bit registers are a bit of an edge case, as 16-bit integers may both be a lot faster on them then 32-bit integers and, in many cases, too small)

If go chose to use 32-bit integers as default, some users on 64-bit systems would complain that they couldn’t create, say, an array of 6 billion ints. If they chose 64-bit, some users on 32-bit systems would complain their loops were needlessly slow, and code bloated (why waste 4 bytes of almost every integer in a program?)

Not having generics makes this more of a problem. If go had generics, switching between integer sizes could be a matter of recompilation using a different compiler flag)

A sufficiently advanced compiler would help here, but go doesn’t have one (not exceptional), and doesn’t even aim to have one (compilation speed seems more of a goal than run-time speed)

Traditionally the register size was too small, it's very common to have numbers above 256 or 65536. It's not true anymore with 32 bits numbers and a limit of 2 billion.

On 64 bit systems you can have large arrays that are bigger than a 32 bit int. For example, it's nice to be able to load a >2GB file into a byte array.

For comparison, Java's int type is 32 bits on 64 bit systems, but then this limits the array size. It seems like a lesser evil to have a platform-native int type than to limit the size of arrays (especially since servers can be expected to increase their max memory going forward).

Of course, standardizing on 64 bit ints instead would require emulating them on 32 bit systems, when they can't support that much memory anyway (you could argue that 32 bit systems don't matter much anymore, but if you really don't care about ever running on them, then you can just treat 'int' as 64 bits and not variable size).

C# is the same, int is merely an alias for Int32 and the default Array type only holds 32bit.

If you really need to, it's easy to wrap this into your own BigArray-class holding a 32bit-array-of-32bit-arrays and overriding the []-operator with Int64 as argument.

It's a rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.

I feel you, but, that's uintptr. int is more useful as the "native type" for array/slice length/cap/indexing

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

That would be quite a fundamental change. At the moment _int_ and _uint_ have certain semantics that, if changed, would surely break many applications and libraries that rely on the current semantics. I am finding it hard to think of a more sweeping and drastic change to the core of a language.

Having said that, I'm by no means a Golang expert – this is the comment of an outsider looking in. I get that the proposer is Rob Pike and obviously Mr. Pike is god-like so what is it I am missing? Is Go 2 meant to break everything? That's like, wow.

Any low-level hardware bit-banging code is going to have to be audited or break in subtle ways, will it not? Is Golang different from C and C++ and languages of that ilk that this sort of change is not that much of a problem? Help me out here folks, I'm genuinely perplexed.

If the change as originally proposed went through, it probably wouldn't affect most uses of bitbanging low level code because they are already using int32/int64 rather than int (which has different size on different platforms). You are correct that it could definitely break some programs though, and so with recent sensibilities veering away from making any non- backwards-compatible changes, an amended proposal would probably just introduce a new "vint" type (maybe removing the old int type at the same time if it is really ambitious)

If these are new datatypes then they would break nothing (ignoring the "int" default part).

> so what is it I am missing?

The Go team has been adamant about avoiding any changes that break existing code. The whole point of Go 2 is that at some point that might have to happen and they're trying to minimize that pain.

I've been thinking about this, and even though it's indeed a breaking change, it's one of those changes that can be easily toggled through a compiler flag. I cannot picture many libraries relying on the edge cases that Pike enumerated.

My (admittedly unsophisticated) mental model is that int32 and the like are simple primitives that can be stored in registers and use the processor's native ADD/MUL codes, while BigInt is going to be some boxed structure with its own implementation of arithmetic operations. For as common as number munging is (especially in somewhat lower level code that Go shoots for), it would carry a huge performance penalty, wouldn't it? Or are there more sophisticated ways of offering a "true integer" type that I'm not aware of?

I'd like this because it'd make certain classes of programming problems simpler.

Admittedly, not for things I build in my day-job but mostly for the kind of things you'd get when doing 'project euler' or 'leetcode'. Or more seasonal, the coming "Advent of Code".

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments.

As for all the folks claiming they'll leave Go if it gets generics, it's faintly reminiscent of Mac fanboys claiming PowerPC chips were the Very Best right up until this was obviously not true. C++ generics are a PITA in many ways, but you can be insanely productive in the STL without having to hand-roll everything and with good type safety.

Despite the pain, I've been amazed at how easily you can build up some really complex data structures as pretty much one-liners ("Oh, I need a vector of maps from a pair of Foo to a set of Bar") that would either take a preposterous amount of code (or be a type-unsafe disaster waiting to happen) without generics.

Hopefully the final Go 2 generics proposal will capture some of this goodness without some of the horrifying C++ issues (error messages, bloat, sheer brain-numbing complexity).

"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 fine, if imperfect, language without generics. It's a better language with them.

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.

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 chunk of the community coming from dynamically typed languages. In which case they're just have a negative reaction to unfamiliarity.

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 code is not that, and will be handed off to novices over and over for fixes.

So, it’s a question of whether you cater to the advanced developer who can capably handle a vast toolset, or do you commit as a community to more rudimentary tools, in order to reap the rewards of systemic simplicity.

There is no right answer.

I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level.

Go, EZ-Go, C, EZ-C, etc

I am writing all of my code in EZ-JS

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{}.

> Of course you can say “just don’t do that”

This exactly. The beauty of Go is that currently you do not need a book called "Go, The Good Parts".

Yes, generics would make a lot of things easier, but almost everything more complex and footgunnish.

>I believe in the future all languages will fork into a simpler novice subset for general use and an expansive language for infrastructure. These will both be valid in the same parser, but the subset will be quarantined at the package management level.

I don't think we'll see this happen much for existing languages, but it could be a very interesting angle for a newly-designed language (or rather pair of languages).

Although ultimately I do want generics in Go I am afraid they will make the language more difficult to use and understand. Generics in c++, c#, scala, java, etc all tend toward being very complex and change the way programs are written.

The focus moves towards a taxonomy of types and developers (myself included) sometimes get stuck on difficult type problems. There's something about trying to preserve type safety which sets the bar extremely high for bypassing the type system when there's not an easy solution and before you know it you've wasted 2 or 3 days writing code which doesn't actually do anything but placate the compiler.

And often that type-safe concoction you create is almost indecipherable when you come back to it later.

For example here's a project I worked on recently which cached a concrete version of a generated method using generics:

https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/...

Used like this:

    var originalMethod = DynamicMethodBuilder<Func<object, byte[][], object, object, bool, T>>
               .GetOrCreateMethodCallDelegate(
                    redisNativeClient.GetType(),
                    "SendReceive",
                    methodGenericArguments: new[] { typeof(T) });

At least for me that was really hard to figure out how to do and I still have to squint to see what the heck its doing. The non-generic version wasn't type-safe and it wasn't as fast, but it sure was a lot easier to read and understand.

And to give some sense of the complexity involved, Rob Pike mentioned in his talk that the proposal spec for adding generics to Go is longer than the spec for the entire language.

I think the complexity is worth it, but I just hope we can be cautious about how and where generics get used in real-world code, otherwise we'll end up with gobbledy-gook that only experts can decipher... and that would be really sad, because the promise of Go was a language normal engineers could be productive with.

>Generics in c++, c#, scala, java

They're not all the same though are they.

C++/CLI had both compile-time generics (templates) from C++, and run-time generics from the CLR. And they could be complementary at times.

For compile-time generics, Dlang are a lot more sane that C++, having had the benefit of coming later, and dumping C compatability.

Similarly, CLR (C#, ...) generics had the benefit of being designed having seen Java first, so IIRC they're baked into the CLR. CKR generics were derived from work done at MS Research Cambridge, and I seem to remember Don Syme (F# creator) being rather proud of them. Disclosure: I was contracting at MSR Cambridge back in 2007.

Anyway, the golang designers will be aware of these implementations, so hopefully they'll come up with a nice design.

I'll answer from my perspective.

I don't hate generics. I see the value of generics, especially after having worked with Go for so long; I've had to do some mental gymnastics to get around not having proper generic collections.

That being said, I'm not excited about seeing generics in other people's code. The added complexity doesn't really solve problems I have anymore.

That being said, I'm actually way less excited about overloading.

I think generics and function overloading is going to make me think "where the hell is this coming from?" a lot more often and then I'm going to need to load it up in my IDE, or vim with way too many plugins, and start following definitions.

I think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.

But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.

If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed.

This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.

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/comments/5nifpm/they_said_rust...

That's what people don't want.

That's not compile time metaprogramming at all, it's just series of wrapped closures. It's basically the sequence of function call names preceding that call backwards, with different capitalization.

The big difference between C++ and Rust is that, when you scroll down in this Reddit thread, it shows that the Rust guys have a clear path for fixing this issue, whereas there is no fix for this in C++ (that I'm aware of).

Ha ha, "10 line error". [ Puts on Monty Python voice] "What I wouldn't give for a 10 line error..."

Incautious use of the template mechanism - or just a minor typo - has given me couple screenfuls in the past.

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{}.

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 generics in Go will come with complexity tradeoffs.

I feel like the community learns more about languages and software engineering when we maintain language diversity and see the pros and cons of each approach in practice.

I want generics for selfish reasons, but would also like to see how a modern strongly-typed language solves problems without it.

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.

For me at least, the reluctance comes from the new proposal process not having yet proved itself for large backwards-incompatible features. I want to be assured that a Go with generics is a Go with a really well-integrated feature, and not some grafted mutant appendage whose only real purpose is to appease the greater community.

It's great that they're trying out the process on smaller, more simple proposals. My hope is that this system will either produce really good features, or reveal that there are simply no satisfying solutions.

Coming up with a complex solution is much easier than finding a simple one. Go forces you to find those simple solutions. There are places where generics are the only solution, but they also enable lazy design.

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 from me). I can kind of get why a language targeted towards "average" programmers might want to omit these.

But here's the thing: The less abstraction power a language has, the more complexity must be handled by the developer. This leads to things like Java Spring, which you do have to be a genius to understand.

s/genius/masochist/g

>"Oh, I need a vector of maps from a pair of Foo to a set of Bar"

This is a fun example since you can do that in Go now, as it comes with a generic vector (essentially) and map :D

I think that was the design decision, 95% of generics use cases are covered by having growable arrays and maps, so why clutter the language with generics.

I like generics, I think most people who dislike them are coming from C++ templates, which has downsides that don't exist in newer generics systems (such as in C# or F#)

What are generics?0

Rather than writing multiple functions that take different types as args and return different types (say int8, int16, int32, etc.) but do the exact same thing, with generics, you can instead write one function that takes a number (which could be any int type) and return a number, and you only wrote one function. That is generics in a nutshell. The function is generic, not specific to one type.

Generics allow for less code, thus they are easier to debug, test and reason about. I've used them a lot in C++ and I do miss them in Go. It's not a deal breaker for me either way, but for people who write larger, more complex code, not having them makes it more difficult (more code to write, test and maintain).

C does not have generics either. Go is a lot like C in this regard.

C has minimal generics support since C11.

Wouldn’t this make golang slow though? Isn’t that what people claim makes python slow?

A simple example of generics is generic collections.

Without generics, if you need a list filled with TPS Reports you basically have 2 choices:

- Use the 'untyped' List that deals with objects. You will have to cast to TPS whenever you look up an item and you will have to make sure that no one accidentally adds a Timesheet to this list.

- Write a custom TpsReportList. I'm sure you'll be able to write an implementation as efficient as the language creators. Oh an if you copy and past from TimesheetList, don't forget to check all names. `tpsReports.AddTimesheet()` is just embarrassing.

With generics, you will have a `List<T>` type. If you need a list of TPS Reports you will use the type `List<TpsReport>`. If you need a list of Timesheets, you will use `List<Timesheet>`.

You can't add the wrong type of item to such a list, you will always get the declared item from that list and you can't assign an instance of one type to a variable of the other type.

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go.

There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure out. I haven't felt so viscerally aggressive about software like that whole experience made me feel in a long time.

I hope Go2 makes something concrete from the start and sticks with it, for better or worse.

Having used the new Go module system (introduced in Go 1.11 as an option, to be the default choice in 1.12) since August, it's my opinion that this is now a solved problem.

The biggest source of pain moving forward is going to be the projects that haven't transitioned, including the various command-line tools that work on parsing, generating and manipulating Go code (e.g. linters, code generators). Most of the important ones are already there, and I've transitioned several myself.

As an added bonus, word is that the Go team wants an official package repository system (similar to Cargo, RubyGems etc.). I wouldn't be surprised if this happens rather quickly.

> it's my opinion that this is now a solved problem.

It's starting to look like a viable solution, but it's not even close to actually solved yet. Why does `go mod why <module` make changes to your module? How do you run go get to install a remote package when modules are enabled (without explicitly running `GO11MODULE=off go get`)? Why isn't the module cache concurrency safe? Why does the module cache sometimes mysteriously cause compile errors until you `go clean -modcache`? There are so many little bugs and oddities.

And as you mentioned, a lot of things have side effects now that didn't use to, which has catastrophically broken a lot of the tooling surrounding the language. Autocomplete using gocode used to be nearly instant. Now it sometimes triggers downloads and takes 30+ seconds.

I'm hopeful that go 1.12 will be the first release where this problem is really solved.

There are bugs, but I was referring to the design of the whole thing.

By the way, your "go get" bug was fixed today [1], if I understand your complaint correctly: With the new modules turned on, you could no longer do "go get" globally.

(I would agree that it's a little weird that "go get" outside a module installs it globally, while inside a module it installs it locally; that's going to trip up scripts and Dockerfiles, and it should really be two separate commands. "go mod add" to add a new dependency, for example.)

[1] https://github.com/golang/go/issues/24250#event-1996119923

There are still some rough edges, but I agree that the new module system is very good. And it's given me the confidence in Go to start using it far more broadly than I had before, when every new project meant hang-wringing over how to handle dependencies. Now it Just Works well enough for 90+% of use cases, with no extra steps required. It just works.

I just started learning Rust for a small project, and I found its "one clear path" model very appealing (I don't know if it is a formal goal, or if it's just a happy accident based on a smaller, more focused, community). It doesn't just apply to the package manager, but that's one of the first bits a beginner sees. Rust has a single, easy-to-find, "pretty good" answer for nearly every question a beginner asks, at least, it has, so far, for me. Cargo is that answer for packages and for building, and it's pretty good, and there's no debate about how to install or build Rust tools and libraries.

I didn't really find that to be the case with Go, so even though Go is a simpler language, I have been more productive, much more quickly, in Rust. Within a couple of hours of starting my project (with only a cursory glance over the docs and tutorial) I had my project daemonized, had options parsing working, had system calls working, got logging working, etc. It was shocking how quickly I was up and running.

I'd been hesitant to try Rust, because it looks big, and I'm kinda tired of big languages. I just don't have enough time/motivation to study a bunch of nuanced syntax and such; I'll never be a great C++ programmer, though I can muddle through and usually understand other people's C++ code. But, so far, Rust is proving to be one of the easier languages I've learned lately, partly due to the holy path being well-defined, and partly due to strong libraries that overlap my particular project perfectly (being a systems language built by very smart people, it has some very good systems libraries).

I don't mean to imply Go is a hard language, it's not. I picked it up pretty quickly, too. Both are easier to learn than, say, JavaScript, because they're much smaller. But, I agree that there isn't a super clear path forward for a beginner with Go, including with installing and building. You just have to acquire more tribal knowledge to work in Go than in some other languages (but, much less than many others...older languages tend to have tons of that kind of thing).

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 it gets easier. In the worst case I think I would still use it to build data pipelines since I really enjoyed the syntax and the safety check as long as I don't get into smart pointers or raw pointers.

Also another annoying point is that some libraries use nightly.

I have heard this is a really good resource for understanding this exact aspect of Rust

http://cglab.ca/~abeinges/blah/too-many-lists/book/

I have to ask why you're not using a data structure from a library, though.

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/

Rust explicitly set out to have an excellent built-in package management solution. They tapped Yehuda Katz early on for this.

> They tapped Yehuda Katz early on for this.

After trying three or four times to build one on their own that is!

Rust easier to learn than JS lol... In Rust you have issues that will or will not overcome easily, nothing like that happen in Go. And seriously getting starting in Go takes less than an hour:

- Install Go

- Install VSCode + Go plugin

- Start working

I explicitly said above that Go is an easy language to learn. But, I found Rust easier.

And, yes, I'm finding Rust easier to learn than JavaScript. Without question. It is a much, much, smaller and more cohesive language. It has some new concepts (features or techniques that I have never used in any other language), but so does modern JavaScript, and with JavaScript there's usually five ways to do it, and half of them are really poorly thought out. I don't dislike JavaScript. I'm not saying one shouldn't learn some; one definitely should. But, it's definitely going to be "some", for most people, because there's just too much of it to learn it all, unless you can devote yourself full-time to being a JavaScript expert. I aint got time for that.

As I mentioned, I've built a (toy) project in Go. I've spent more time with it than Rust at this point. I know how it works, and what getting started looks like. And, though Go was pretty easy with few pain points, I've found Rust to be easier and to provide a more clear path for a beginner to follow, so far.

Everyone is different, and we're all coming from different places. No one has exactly the same set of starting conditions for learning a new language as I do. For some, Go may be easier than Rust (I expected it would be, which is why I started with Go and avoided Rust for so long). For me, I am finding Rust easier. I haven't done much with it, but I was surprisingly productive surprisingly fast.

Coincidentally, here's Rust's getting started workflow:

- Install Rust

- Install VSCode + Rust plugin

- Start working

My only experience with Go was around 2012-2013. It was fun, but I did not bother sticking with it. The forced directory structure was a little bit annoying and I found myself writing interfaces for everything. I'm sure people will say it's my fault as a programmer, but it turned me off from the language.

The new module system removes $GOPATH and the forced directory structure.

Go modules are available in go 1.11 today. If you're envisioning another new pkg management solution besides that, I don't think that's going to happen.

The fact that it didn't have an official package manager from day 1 is a big issue to me. All other new languages have an officiel package manager - elixir, rust, ... https://github.com/golang/go/wiki/PackageManagementTools

go1.11 pretty much solved this, though there are still many dependency managers out there and projects which rely on them that should be upgraded to support the New Way.

"package" in Go has always referred to a folder. Or in other words, a shared namespace for every entity exported by every file in that folder. "module" refers to a package which has a go.mod file in it; that module package + all of its children become versioned via that go.mod file and are distributed as one unit.

It operates identically to npm; npm packages are folders, and there's a special package with a package.json which versions that folder and all of its children. Then, that "package.json package" is what is distributed.

It's ironic from a language that invented gofmt...

I'm curious what language you come from that has much better package management than Go. I'm guessing not JavaScript, or C++, or Java, or Python, or...

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows.

Haven’t tried it since.

Hope lots of this change to make the language more welcoming for Newcomers to the language.

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.

That's terrific news! GOPATH and the file system conventions are horrible for me as well. It forces me to break my personal conventions and workflow that I use for every other language. I avoid using go for new projects now because it got to be so annoying and disruptive (a somewhat shallow reason, I know).

Don't get too excited. You don't have to place your projects within $GOPATH anymore, but all your dependencies are still forcefully downloaded to – and imported from – the shared $GOPATH. AFAIK they didn't provide a way to have your dependencies localized to a subdirectory of your project's root. The documentation for "go mod vendor"[1] makes it seem like it should accomplish that task, but I couldn't get it to work for initial pull of dependencies – it only worked after dependencies were already downloaded to $GOPATH, at which point it was willing to make a copy of it within the project.

[1] "... or to ensure that all files used for a build are stored together in a single file tree, 'go mod vendor' creates a directory named vendor in the root directory of the main module and stores there all the packages from dependency modules"

That's not a shallow reason: the annoyance in aggregate motivated a language usability improvement with no regressions.

That ended up being the biggest hurdle for me. I wanted a single repository with some Go source code, some Python, some C++, and I didn’t want to have to put the repo in a specific place or set environment variables for every project.

Nowadays I just put my Go source code in <repo>/go/src/example.com/pkgname and that works well enough, but it's a bit clumsy and reminds me of bad experiences navigating Java source trees. I haven’t switched to modules yet but I will once I get 1.12 everywhere.

> there's an experimental feature

That's not a feature but a fix for a design problem, and currently the only fix is an experimental one.

For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.

"All that is excessive is insignificant.", said Talleyrand.

By your standards c and c++ are not professional tools.

I don't understand the issue with language improvements, should we only use languages that were perfectly designed to start? Like JavaScript?

Weird syntax? Maybe you should try Haskell, OCaml, Erlang, or even Rust instead. Then come back to Go and tell me if it's actually that "weird."

It's a bit Pascale-y, which may be a turn off to some.

I do wonder why you'd consider Rust, (or even Haskell), to have weird syntax?

Rust is probably the least weird of those I listed. I find its syntax "too busy", similar to C++.

Haskell, I feel, needs no explanation.

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows.

My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

The other thing that turned me off from Go was testing. It has good enough support for unit testing but it really lags behind in integration testing. Sometimes you want to know that if you hit this endpoint with this payload you get this response back. It's harder than it should be to write integration testing where you spin up the application and test it end to end.

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :)

Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those.

Not saying that features like byebug have no use at all, of course.

I think the closet Go equivalent of 'byebug' would be delve[0].

It's got more of a learning curve than a REPL, but very powerful. Editor plugins for Go also tend to have good convenience support for delve, making using it less painful. For example, vim-go[1].

[0]: https://github.com/derekparker/delve/blob/master/Documentati...

[1]: https://github.com/fatih/vim-go/blob/master/doc/vim-go.txt#L...

> For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

Isn't that what a normal debugger does? Or am I simply just living in lala-land because of C#.NET/Visual Studios terrific debugging experience?

I remember php and the hell that was xdebug. It was much easier and more efficient to simply to a `var_dump` whenever you needed to debug.

You might like Rust. It has a much better story in these areas.

Weird syntax? I’m sorry this doesn’t look like your favorite language.

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

But go isn’t built on top of C? Why would they add more dependencies that complicate and slow down the compilation process and hurt portability?

No, by default Go programs and the whole Go toolchain has no C dependencies. The whole Go toolchain is implemented in Go and it doesn't like into any C libraries. Go links against libc only if you either use CGO or a package which has C dependencies, but I am not sure whether there is any package left in the standard distribution, that does.

Same for me. I moved all my code into the GOPATH pattern after finding that I had 3 separate clones of the Linux kernel in separate places. (And not just for development, just for reading and grepping.) I made myself a helper tool for navigating the GOPATH:

  $ cg gh:torvalds/linux # cg = cd to git repo
  $ pwd
  .../src/github.com/torvalds/linux

The code is at https://github.com/majewsky/gofu#rtree if anyone's interested.

> 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.

Actually, the issues you mention are already fixed by Go modules.

EDIT: Removed a parenthetical that was based on a misreading of the parent.

I believe they’re saying that vendor support is a good thing in Golang.

Thanks; I definitely misread. I deleted the relevant bit from my post.

No oxford comma:

the performance, the community around it, and vendors support

FWIW GOPATH has not been required since 1.8. It now defaults to $HOME/go if not set.

Go is pretty easy to get up and running in Windows. There's an installer for the compiler and you can install vscode and the Go extension pretty quickly.

Windows is an afterthought for most programming languages (ever try ruby or c++?) and Go's cross-platform capabilities were a breath of fresh air.

I agree with the package management system and $GOPATH. I would add that is awkward that most of the libraries are not thread safe when go routines are core to the language.

Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain.

Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho.

But call me crazy when I say that I like C++ and can read it effortlessly :)

Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt).

It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.

I can get used to something and still dislike it.. with Go it's mostly the bracket style, or put differently, the inability to turn off automatic addition of semicolons before parsing. I'd actually rather "have to" put semicolons manually, but no, I have to suffer so others don't have to put an additional line into their style guide.

"you'll get used to it" is a bad measure of usability.

C++ is definitely something to behold in terms of syntax. It's hard to justify much of the type-system syntax (meta-templates, `sizeof...(Args)`, and `std::forward<Args>(args)...` come to mind). I'm picking on argument-packs here and ignoring the beauty of initializer-lists, operator-overloading and user-defined literals (which allow great syntax in user-code but their own syntax is haunting in library-code). I doubt that C++ would look the same if the syntax were created from scratch with the current set of features.

So it's fair to say Go's syntax is unfortunately limited in expressiveness (and I too find myself mystified by how to express ideas neatly with go), but I have a hard time imagining C++ is something worth emulating without adding a whole bunch of subjective caveats to what "should" be avoided.

If you like c++ then you just haven't given Go enough time to sink in.

It reads more left to right then right left like c++.

I've given go plenty of time to sink in, and I still prefer c++. Things like not allowing implicit type conversions on things that clearly are not a problem (int16->int32) are just annoying.

Call me crazy but deep inside I'm a toaster.

Well 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, well that's just a different language, and we'll just end up on the hedonistic treadmill towards another Java. No thank you.

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.

> Simple scripts, bash until they need their first 'if' or flag or loop, then Go too.

If you don't mind, can you give a little insight on what this looks like in practice? I'm not sure how to use a compiled language as a script. I've played with executing go as a script using a shebang hack, but I somehow don't think this is how others are doing it.

For reference, the shebang hack I was using looked like this:

    //usr/bin/env go run $0 $@; exit $?
    package main

    import "fmt"

    func main() {
        fmt.Println("i am a script")
    }

Anecdotally (n = 10 or so) every Go codebase I've worked on has devolved into a trash fire, so no. Turns out collective idiots can write horrible systems in any language.

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?

If there was such a need, the languages without them would still have a major market, which isn't the case.

Naturally those of us coding since the early days have experience with programming languages without generics support, yet a large majority eventually adopted generics.

Even C has minimal generics support since C11.

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.

I feel the same way. By the time Go2 releases, I hope Rust has solidified its async/await syntax, and Rocket can build on stable.

As I understand it, async/await is not going to be too far behind the initial 2018 Edition (which is coming to stable soon).

Latest estimate is 'in 2 release cycles' (iirc), or 12 weeks.

I really don't know why you got downvoted. The fact that go was meant to force "average" programmers produce maintainable code is an extremely important push for the language.

I do think that generics are needed if go wants to become more useful in contexts others than network middleware or data plumbing, but i'm also pretty sure that adding them will help cripple a lot of codebase in a very short term.

I don't think Go pushes maintainable code. It's simple. That's it. Most of the code bases I see have no layers. As long as you write once and forget, you're fine. After that Go's lack of structure with functions for structs just floating freely in the source file makes things hard to manage. The community's extension of the language to prefer 1 or 2 large files per package makes things worse. The lack of an explicit interface implementation makes it hard to jump to the interface definition of a function on a concretion.

Is there a definitive source for the "average" programmers target? I'd always considered it a tongue-in-cheek response to architecture astronauts who sneer at Go's simplicity.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

-- Rob Pike

From https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...

And there are other hints on https://talks.golang.org/2012/splash.article

> when your team members are idiots

Just remember, they probably think the same thing.

If Go implement generics I’m out

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine.

The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site gets the right context) and downwards (if you want to support cancellation/timeout, which is usually the point of introducing a context).

Context's virality also applies to backwards compatibility. There have been discussions of adding context to io.Reader and io.Writer, for example, but there's no elegant way to retrofit them without creating new interfaces that support a context argument. This problem applies to any API; you may not expect your API to require a context today, but it might need one tomorrow, which would require a breaking API change. Given that it's impossible to predict, you might want to pre-emptively add context as an argument to all public APIs, just to be safe. Not good design.

Cancellation/timeout is arguably so core to the language that it should be an implicit part of the runtime, just like goroutines are. It would be trivial for the runtime to associate a context with a goroutine, and have functions for getting the "current" context at any given time. (Erlang got this right, by allowing processes to be outright killed, but it's probably too late to redesign Go to allow that.)

(I'm ignoring the key/value system that comes with the Context interface, because I think it's less core. It certainly seems less used than the other mechanisms. For example, Kubernetes, one of the largest Go codebases, doesn't use it.)

I have written the 'contextio' package that may be useful to you. It provides io.Reader and io.Writer wrappers that handle context cancellation. This allows to transparently add optinal context cancellation awareness to routines that work with I/O without injecting context as argument.

Doc: https://godoc.org/github.com/dolmen-go/contextio Example: https://godoc.org/github.com/dolmen-go/contextio#example-pac...

Forgive me since I've never used Go, but this sounds similar to having to add the async keyword to methods in C# all the way up the stack once you attempt to use an async method, as well as having to pass CancellationTokens down the stack to support cancellation. I've noticed it pollutes code with a lot of ceremony that I wish had been added to the runtime itself. Is this what you're talking about?

We do use it but mostly in middleware.

However, the reason we don’t use that more is partially because of the viral nature of context - it came late in kube lifecycle, so we didn’t ensure it everywhere and now it’s a lot harder to wire (clients have been iterated on for a while).

I have a closed PR from 2015 to kube that added per request ID tracking that we closed as “wait until we have context everywhere” and we’re still waiting.

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.

Because I think discussing actual solutions is better that just complaining, this is my current favorite design document to address context:

Go Context Scoping [1] by Eyal Posener. It even has a working PoC implementation [2] which is pretty ergonomic and could become even moreso with language integration.

I think this concept solves most of the problems we currently face with context. As a consequence of making context available per goroutine it basically becomes an implementation of gouroutine-local storage. But this is more because context.WithValues exists in the first place than because of this proposal. In fact context has effectively become the de-facto GLS anyway, except it makes everyone's code ugly to do it.

[1]: https://posener.github.io/context-scoping/

[2]: https://github.com/posener/context

Not making Go routines values like Ada Tasks is what led to awkward solutions shouldered by the developer such as "context". Too many time Go developers were told to solve issues in user-land, this is the consequence of that.

Having to manually pass context through so many functions in code bases is definitely not ideal.

It doubles the surface area of every library that deals with anything related to IO, and forces middle libraries that don't and shouldn't care about context to double their surface area just to support connecting their consumers to their upstream providers. "not ideal" is an understatement.

Coming from languages that lack such a «convention», I quite like Context. Try implementing something similar in java or even node is also a giant pain

It's not the fastest thing in the world, but task-local storage in C# is pretty great. Miss it much in TypeScript.

I really like the humility in this part of the statement:

> After almost 10 years of exposure, we have learned a lot about the language and libraries that we didn’t know in the beginning, and that was only possible through feedback from the Go community.

It's so tempting to hold one's project back until it seems perfect. And then, even worse, to defend it as perfect in the face of real-world feedback. I really appreciate it when smart people do their best, but in full recognition that a lot of things will be learned once real use happens.

Rob Pike had a good talk on the Go 2 process and a few of the proposals that went up on YouTube a few days ago:

https://youtu.be/RIvL2ONhFBI

I hope they keep the changes reasonable and do not introduce any breaking changes. I like the language as it is now and I'm very productive in it.

Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant int to a uint to use it in a shift expression. This won't break any existing code).

So at least this first round is quite unlikely to break anything in real use.

For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.

I would like to see more Unicode operators, at least as options. It's crazy that we still use * for × in 2018. Yes, I know that most US keyboards don't have that symbol but that's a solvable problem. I use an international layout on my Linux systems and can type it easily.

Also, I prefer using ' for the thousands separator and was happy when C++ adopted it. It's less visually intrusive, especially with variable width fonts, and some calculators even use apostrophe. Also, in identifiers, the underscore has semantic meaning: foo_bar is different from foobar. But 1'234'567 is meant to be identical to 1234567, so underscore isn't the best choice.

Yeah the swiftness of changes in Swift have turned me off to that language until it stabilizes.

Go is a decade old with many large production-grade code bases. The language is pretty stable, and worth learning!

I've been reading this proposal

> #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood.

The proposal as far as I can make out says allow signed integers for shifts but panic if they are negative.

This seems like a step backwards to me pushing checking which the compiler made you do to runtime.

Personally I'd expect a negative shift to shift the other way, but that doesn't seem to be a popular option with the team.

> This seems like a step backwards to me pushing checking which the compiler made you do to runtime.

No that means this operation is currently unchecked by the compiler: https://play.golang.org/p/nJmaEOkObk1

why would someone shift numbers in the first place? I only shift uint8

> Go 2 will be much more community-driven.

Please no ...

There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind.

I'm also worried about how being "community driven" will change the philosophy of the language.

I think "community driven" means less than you fear. I think it means that community feedback is used to push the language in directions that scratch some of the major community itches. That seems perfectly reasonable to me - more reasonable than making changes in a vacuum, in fact.

But I don't think that they're going to let the community run wild and completely change the character of Go. I think they're looking for wins that matter to users, but wins that are possible within the framework of what Go is.

HN has a good rule [1] about comments: "Please don't post shallow dismissals, especially of other people's work." The above comment is being downvoted because it just voices dissent, not a real, substantive opinion. I can guess what their intent is, but that's hardly a basis for good discussion.

[1] https://news.ycombinator.com/newsguidelines.html

That made me remember part of an interview done to Dennis Ritchie back in 2000:

  When I read commentary about suggestions for where C should go, 
  I often think back and give thanks that it wasn't developed 
  under the advice of a worldwide crowd. C is peculiar in a lot 
  of ways, but it, like many other successful things, has a 
  certain unity of approach that stems from development in a 
  small group.

I haven't been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?

IMO: very much still half broken. Calling functions is still experimental[1] and in my experience has yet to work even once, there's no display formatting options (afaik) so you are often looking at a chunk of bytes instead of something useful (after diving several times more layers deep than other debuggers require), and you pretty often can't view memory that's in scope at another call stack location without going to that location. All of which gives you a pretty crippled experience, especially as it makes conditional breakpoints extremely limited in use.

That said, it's mostly just half, before it was like 3/4 or worse. It has improved in stability (I haven't had it randomly disconnect at all since late Go 1.9 days, but I haven't pressed it hard at all either) and GoLand's integration works well and is mostly fast. It just can't do anything except set breakpoints and view memory.

[1]: https://github.com/derekparker/delve/blob/master/Documentati...

If you use Goland 2018 it's pretty seamless, there are a few things missing like being able to get ptr addresses and view values in hex, and it's a little laggy compared to VS but not bad.

Is Goland's debugger written by Jetbrains?

Yes, it uses delve under the hood and acts much the same way as VS.

I've never had any issues with debuggers over the past year of developing full-time in it.

I use GoLand for development, which I believe uses Delve by default and it's entirely pleasant.

I've had really good luck using delve with vs code. Easy setup and good experience overall

Delve

fmt.Printf() debugging is always a time-honored tradition.

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.

> We are constrained by the fact that we now have millions of Go programmers and a large body of Go code

Are there really "millions" (plural) of Go programmers?

Sounds like a bit of an overestimate, no?

Vague estimate is that there are 18 million programmers in the world[1] and that 4% of them use Go[2], so 0.7 million would be a starting point guess as the total number.

Note that these were the first two Google search results I found for "number of programmers in the world" and "percentage of programmers in different languages" so... being off by a factor of 10 or more is likely.

[1] https://www.computerworld.com/article/2483690/it-careers/ind... [2] https://www.statista.com/statistics/793628/worldwide-develop...

These numbers seem pretty accurate, and I wouldn't expect that they're off by anywhere like a factor of 10.

Think about it: the number of programmers in the world is certainly not off by 10 factor - no way there are 180 million programmers in the world, only 18 of which are visible.

Similarly, there's no way that 43% of programmers in the world are Go programmers, that's again quite clearly off.

I think an estimate of 700k Go programmers makes a lot of sense, maybe with a factor of x2. I would very strongly doubt that there are more than 2 million Go programmers in the world.

Not sure, but I wouldn't be surprised. There seem to be a lot of Go developers in China and elsewhere who don't really participate in the English-speaking Go community.

I don't really see a reason why there'd be a large iceberg of Go developers in China. There's no reason why programmers in China would use Go in higher proportion than elsewhere in the world.

When I was young I thought Dijkstra published a paper called, "go2's considered harmful!'. I think the next version of Go should be Go3.

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

There's this[0] one from 10 hours ago, but it's pretty buried by actual discussion at this point.

[0]: https://news.ycombinator.com/item?id=18561684

This is a awesome joke. Thanks for the laugh.

Non-go user here. So what are the most desired fratures from Go 2 in the community?

I remember something about generics not being supported.

Helpful link from the text: https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+l...

These are Go2 proposal PRs, sorted by upvotes.

Generics and errors are the things that come up most frequently in surveys.

It seems Go wants to have a more open development process, but it looks like all the decisions are ultimately under the purview of the "Go team". Does the Go team include any community members? Or is this "open process" still essentially up to whims of a small group working at Google?

"... keeping the language small and clean" + Go Modules is the sweet spot for me.

That’s 1.12 though, isn’t it? I’m not disagreeing that it’s the sweet spot, I just think we already have it, or close enough.

I am torn apart between investing the next one year between Go and Rust. I want to do some cool systems level programming. Both seem to be very good at it. Go has additional advantages of being older (and may be wiser).

What does the hivemind think?

> some cool systems level programming.

What projects did you have in mind? I think the answer to your question depends on what you mean by "systems level programming" and what you plan on doing/trying.

This blog post doesn't answer likely the biggest of all questions: Will there be breaking changes? If so, how will those be handled?

"As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change" sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee.

I'd love if the compiler would stay backwards compatible and packages / modules could be pinned to a certain version, either during import or in the package / module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2. Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.

It is very clear that there are breaking changes for Go 2. However, they are testing out their new proposal-review system using non-breaking changes included in Go 1.

I'm learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.

C++ is the weird one out, you might have a declaration like:

    int (*f)(int x);

The variable type is around the variable name. Some of it is before and some of it is after. In Go it’s simpler:

    var f func(int x) int

If I want a void function, I can just leave the return type off, I don’t need to add "void":

    var f func(int x)

It’s easier to write a parser for this, because you know that this is a variable declaration just by looking at the very first token and finding a certain keyword. If you write a parser for C or C++ it’s much more complicated, because you have to keep track of which identifiers name types in the scope that you’re in. Generally, more modern languages like Java, C#, Go, and Rust are much easier to parse, they are often designed to be relatively straightforward to parse with e.g. an LL(1) parser, or close to it, maybe you can just use recursive descent.

In C++ it's also a bit inconsistent,

    int f1(int x) { return x + 5; }
    std::function<int(int)> f2;
    auto f3 = [](int x) -> int { return x + 5 };

You also have to invent a placeholder for when there aren’t types:

    int x = 3;
    auto x = 3;

In Go you just omit the type, and you don’t need a placeholder:

    var x int = 3
    var x = 3

Other languages where the type comes after: Haskell, Python (PEP 484), ML, Rust, Pony, Nim, TypeScript, Swift.

In fact I think the way C/C++/C#/Java do it, with the type at the beginning, is actually somewhat rare.

Pascal did it:

     procedure SetColor
         (const NewColor: TColor; const NewFPColor: TFPColor); virtual;

Rust does it too:

   fn do_twice(f: fn(i32) -> i32, arg: i32) -> i32

Go is similar, but less symbols:

   f func(func(int,int) int, int) func(int, int) int

A lot of languages have had type declarations at the end. The first popular which comes to mind is Pascal (see http://wiki.freepascal.org/Fibonacci_number).

You get used to it. Having to deal with this kind of differences between different programming languages is a lesser concern in the grand scheme of things.

> no other widely usage language does that

Swift, Kotlin, TypeScript, Rust

Like everything different, it can feel odd at first, but I actually prefer it now. Think of it as "Joe is a Person" is more natural than "Person named Joe".

My experience is limited to c, c++, java, all of them did 'type variable' instead of 'variable type', now I see there are many others that are doing things very differently. Thanks.

Love Go's one binary does http-server-login-everything-etc, can't be simpler for deployments.

I also believe it was More ergonomic if 2 variables have the same type:

func(foo, bar int) bool

I'm curious if making go an ISO standard was ever considered.

Given that go is already pretty well specified (and, perhaps more importantly, has 2 mature implementations) it's hard to see what advantages having it formally standardised would bring.

https://golang.org/ref/spec

What would be the benefits of an ISO standard? The list of programming languages with an ISO standard is pretty short https://en.wikipedia.org/wiki/Category:Programming_languages...

Am I reading this right that the list in the #Proposals header are the only proposals from the Go2 bucket that are being considered for 1.13?

I was hoping "check" would make the cut.

Yup. Specifically because they are backwards compatible and well known problems being used to test their proposal feedback system.

I really wish Go 2 can make dependency management easier.

Basically a solved problem now: https://news.ycombinator.com/item?id=18563267.

Have you tried go modules since 1.11? It's significantly simpler now than it was before.

Will we finally get a normal module implementation?

What's wrong with packages?

With that naming practice, it will probably become as hard to google problems as with AngularJS and Angular 2.

I've yet to see any mention of immutable data types, which I find I would use more than even generics.

Awaiting obligatory "go 2 considered harmful" YNews article.

So generics are in?

Wasn't Go2 considered harmful :-?

Throw Semver OuT THE WINDOW!

GOPATH is the ugliness of Go. Can't imagine that overhead for a modern PL.

Go modules will replace GOPATH, they're available since Go 1.11.

that will be gone as of go 1.12 - already opt outable in 1.11

Go 2 Considered Harmful:

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...

When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all the dirty low level assembler code (for sorts and other area's in which speedup was huge over COBOL). Was shown how my approach was far more wasteful of CPU resources and why others would not be able to maintain such code as all the rest used GOTO's. I will admit, it was nicely explained and this is in a time in which mainframes offered the only computer solutions for business of this scale and not cheap.

I will say GOTO's work well for exception handerling, but still doable without. But for speed, though less of a factor today, it still translates as faster code at the low level of CPU runs.

But then, things move on and you will always have that wave of what students are taught being cutting edge compared to what is actualy in use in work. A friction many would have encountered in one form or another, even today. Be it style, design or language/tools choice. What is the best today, may well be outdated tomorrow, but you have to maintain that legacy investment and it is often too costly/risky to rewrite that legacy for something that itself could be legacy the next day.

So as for harmful, well they can spagetti up code if used badly, yet that comes to many approaches and if they are that bad, why do CPU's still have JUMP instructions you could counter-argue.

Oh and well played on the humour.

I appreciate a good joke, but is this really necessary on a thread like this?

Here's the equivalent Reddit thread; better suited for this sort of comment:

https://www.reddit.com/r/golang/comments/a1j3h6/go_2_here_we...

I wonder how many people got the joke without reading the link. Good one, boss.

I always appreciate a good joke but unfortunately this has become the top comment as of now and is not adding to the real discussion around Go 2. This is a typical case of when I use my downvote power. Great joke but we should keep HN noise free.

this kind of comment says a lot about current state of HN

this is the new Reddit

You got me. Genuinely thought it was gonna be a critique.

Big fan of both Go and also Rust. It is time we move beyond C and C++

Once C++ modules support comes out it will become a lot more interesting, removing the need for makefiles hopefully.

https://clang.llvm.org/docs/Modules.html

I apologize for asking a question that will likely lead to a flame war regardless of your answer, but which is better? I've used Go for a while for certain apps, but as a primarily functional programmer I find my way of thinking often clashes with the language (and I also don't like the verbosity).

So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go?

I would love to have type-clases a-la Haskell (implicits with parametric polymorphism, which is dead-simple and well understood) and universal pattern matching everywhere, but this is, of course, just a dream.

I would love to have ML/Scala-style syntax for curried functions and function definition via pattern-matching with guards, which is also, it seems, out of questions.

Actuall, the more of ML a strict language gets in - the better.

What is really funny is that Bell Labs did a lot of ML research, especially on stdlib, but Go team is ignoring everything which is not of the C flavour. Pity.

Again, ML is absolutely wonderful, and type-classes are the biggest single major innovation since Smalltalk.

It is better to lean towards ML instead of heading towards Javascript.

I smell the second coming of the Python 3 fiasco.

I'd be surprised if something similar to python 2/3 happens. The go team have been very explicit in saying that all go 1 code must continue to compile, and transitioning to go 2 needs to be as seamless as possible (most likely using tooling to automatically migrate code across, a la go fix from the early days).

What's that famous tag line? Oh, yes:

"Use of Go 2 Considered Harmful".

Hahah oh no, I literally started learning Go last night. Now what?

Finish learning it tonight. It's not that big.

No worries, "Go 2" is going to be delivered in small incremental changes.

This is going to take years to happen, so you're fine. This is just an announcement of what the process for coming up with Go 2 is going to look like.

I'll be very sad if this goes the way of Perl 6

It won't. It's an explicit requirement that it will not. Or even a Python 3. I had a slide saying as such in an earlier presentation:

https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvk... (slide 140)

Ian had a good talk & doc about this too recently:

https://github.com/golang/proposal/blob/master/design/28221-...

https://www.youtube.com/watch?v=LqKOY_pH8u0

Perl6 is amazing! Yes it took a while. Yes it doesn't have the same recognition as perl 5. Yes it's crazy. But it's crazy in fun sort of way.

At least Perl 6 is DOA and there's little confusion about it. The fiasco that was Python 3 was much worse for how drawn out it was.

Honestly that would be great if it took the momentum out of Go and killed the language.

I loathe working in Go.

>* 1. Allowing generalized unicode identifiers.*

I'm all for full support for unicode string manipulation.

But when ever are "unicode identifiers" a good idea? All kinds of BS decisions (normalization etc) for no good reason at all. Would you share code with identifiers written in RTL language? Chinese? Hieroglyphics?

And I'm saying this as someone who's not a native English speaker.

If it was an APL dialect I'd see some reasoning, but what good does it do for Go?

Reply on news.ycombinator.com