Live data from Hacker News

Toward Go 2

blog.golang.org

281–290 of 670 posts

Re: Toward Go 2

#281

Earlier quoted context omitted.

The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists —it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (…

> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). There is also the approach taken by Swift, where values of generic type are unboxed in memory, and reified type metadata is passed out of band. There's no mandatory monomorphization.

Really by "boxing" I mean "dictionary passing" (I've also seen the term "intensional type analysis" for it). That encompasses approaches like Java as well as those of Swift.

Hybrid approaches in which the compiler (or JIT!) decides whether to monomorphize or use vtables are also possible.

Re: Toward Go 2

#282
post #220
post #199

Earlier quoted context omitted.

I liked using it at the university back in the day, and didn't had to repeat code. Eiffel is a very powerfull language with good tooling, just failed adoption, because licenses were too expensive and software industry still has issues valuing quality.

Interesting to hear your experience. I had read a good amount about Eiffel and also large parts of Bertrand Meyer's book Object-Oriented Software Construction (quite a thick book too, and which uses the syntax and semantics of Eiffel, or something close to it, IIRC [1]), some years ago. Had found the language very interesting and also was impressed by it (and by the book). Read some case studies / success stories abo…

With Eiffel tools you got the IDE with interactive development, including a VM for rapid prototyping. Then you would use the AOT compiler (via compilation to C) to produce shippable binaries.

So combining the easiness of interactive development with performance when it was time to ship the product.

It was also available before Java was a thing.

This is what I always kind of missed with Java and .NET, the previous generation of languages (Eiffel, Modula-3, Oberon(-2)) all had a mix of interactive development and AOT compilation for shipping release builds.

Re: Toward Go 2

#283
post #209

Earlier quoted context omitted.

Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.

The opposite side of that coin is that other programming languages do already exist. Any new language is already playing catch-up to reach the state of the art. Go is 10 years old and in those 10 years has made astonishingly little progress at implementing basic features such as error handling, because the designers cannot escape their bubble. The most sensible thing to do is to kill Go, not to improve it. The root p…

> The most sensible thing to do is to kill Go, not to improve it.

Care to expand this? It's pretty clear that you don't find Go suitable for your own use cases, but I've found it to be an extremely productive language, despite the fact that it may have a couple of warts.

Re: Toward Go 2

#284

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.

There is so much boilerplate you have to write that productivity drops considerably, both because you have to re-re-re-re-implement things (or use code generation) and because you need to scan lot's of redundant code before making sense of it. The alternative is often to just use interface{}, which hurts performance and type safety.

This has so far been a theoretical concern for me only. If you want to write reusable data structures you obviously need generics. But none of the code I've written involves reusable data structures, so I can't say I really miss generics.

Re: Toward Go 2

#285
post #5

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

Did he compare those shortcomings with the shortcomings of not implementing generics at all? Because that is the tradeoff here. After decades of research, a decade of go, millions of lines of public and private code, a decade of feedback, and dozens of languages with generics, it's obvious that the perfect generic system isn't going to just happen, so it's not perfect generics vs imperfect generics, it's no generics vs imperfect generics.

Re: Toward Go 2

#286

Earlier quoted context omitted.

> Pike said "Go design" is done. Except that a language which design "is done" is a dead one. Guess C is done for.

I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.

I think you are confusing getting updates with "design"

Go gets frequent updates as well.

Re: Toward Go 2

#287

I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory fo…

Rust is probably what you are looking for.

> a functional language

Has closures.

Has pattern matching.

Has algebraic data types (however variants can't have generic parameters not present on the data type itself, but you can use trait objects to do that).

Functions that don't take &mut parameters, & parameters with types with interior mutability and don't call functions that do I/O are pure (although they may not terminate and may abort).

> optional lazy constructs

"Automatic" lazy costructs are usually unnecessary and thus almost never used, but can be implemented as a library using macros.

Can also just use closures and call them explicitly.

> great polymorphism

Has trait/typeclass polymorphism with either monomorphization or dynamic dispatch.

Structures can't be inherited, but composition gives equivalent results and is the proper way to do it.

There have been several proposals for inheriting structures though, so maybe it will be available at some point, despite not being advisable.

> statically typed with inference

Yep.

> generics

Yup.

Not higher kinded, no constant integer parameters and not variadic yet, but those features should be available in the future.

> great concurrency story

Rust is the only popular language supporting safe concurrency without giving up the ability to share memory between threads.

> an efficient GC

It turns out that a GC is unnecessary, and that reference counting is enough, which is what Rust provides (although it's still relatively rarely used).

If you insist on a tracing GC, there are/have been several attempts to add it, and maybe there will be a mature one in the future.

In particular, there is a "rust-gc" crate, and Servo has a working integration with the SpiderMonkey GC, which I suppose should be possible for others to use with some work.

> compiles quickly

Work in progress (incremental compilation, more parallelization).

> self contained binaries

Yes (or optionally using shared libraries).

> simple and effective tooling which takes only seconds to setup

rustup can install the compiler and package manager in one line.

If you want an IDE, you'll have to install that too separately. Work in progress on improving IDE functionality and ease of use.

> giving you perfomance that equals java and can rival C

Performance is at least theoretically the same as C since the generated assembly code is conceptually the same (other than array bounds checking, which can be opted out from with unsafe code).

> low memory footprint

Same as C.

Re: Toward Go 2

#288

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change bet…

Well, but that's not waiting, that's stalling.

Re: Toward Go 2

#289

Earlier quoted context omitted.

> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). There is also the approach taken by Swift, where values of generic type are unboxed in memory, and reified type metadata is passed out of band. There's no mandatory monomorphization.

Really by "boxing" I mean "dictionary passing" (I've also seen the term "intensional type analysis" for it). That encompasses approaches like Java as well as those of Swift. Hybrid approaches in which the compiler (or JIT!) decides whether to monomorphize or use vtables are also possible.

"Dictionary passing" is a good term for this implementation strategy, I haven't heard it named before. Do you know of any other languages that take a similar approach?

Re: Toward Go 2

#290
post #235

Earlier quoted context omitted.

The point of Go 2.0, IIUC, is that it throws away backwards-compatibility guarantees, so if they want to do something in Go 2.0 that breaks correct go1 code to support generics, that's on the table. So backwards-compatibility nastiness is not guaranteed.

Not quite. The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase. So, at runtime, Go 1 code needs to be able to work with Go 2 types. That will impose some restrictions, I imagine.

>The article mentions that Go 1 code needs to be able to coexist with Go 2 in the same codebase.

Interesting. Are there any other languages where that is allowed? I'm assuming that by "codebase" you mean all the code that gets compiled into one program or library (for compiled languages), or is part of one program or library (for interpreted languages). And I don't mean the case where only a common subset of Lang X v1 features and Lang X v2 features are used in the same codebase (because in that case, there is no issue). That latter case is possible, for example, in Python, and probably some many languages too. In fact by the definition of the case, it should be possible in all languages.

Post reply on HN