Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

211–220 of 670 posts

Re: Toward Go 2

#211

Post by notheguyouthink »

dragonwriter wrote: post #107
camus2 wrote: post #97

Earlier quoted context omitted.

> I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0. The problem with Python 2/3 is that Python 3 didn't add enough new features to make people want to move to 3. The problem with Angular 2 is that it just didn't know what it wanted to be. If Go2 doesn't break enough yet still break it will be no different from Python 2/3 fiasco. Go ha…

Breaking things aren't want makes people want to move; it's a cost, not a benefit. Now, you need to offer benefits to get people to pay the cost for those benefits. The Python 2/3 problem was because there was too much breakage for the perceived benefit (especially early on) for many users, not because there was too little breakage.

Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic.

As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage?

It would seem that pretty much any language change, from keyword changes to massive new features, breaks compatibility.

Re: Toward Go 2

#212

Post by ziotom78 »

nightski wrote: post #203
didibus wrote: post #177

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…

Nearly every item on your list is available with OCaml.

Apart from "great concurrency story", because of the well known problems with the GC. This might be a huge shortcoming for a number of people.

Re: Toward Go 2

#213

Post by mhh__ »

didibus wrote: post #177

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…

With the possible exception of the GC, d(lang) fits those parameters. Including optional lazyness, performance etc.

Re: Toward Go 2

#214

Post by zackmorris »

Go doesn't have const structs, maps or other objects:

https://stackoverflow.com/questions/43368604/constant-struct...

https://stackoverflow.com/questions/18342195/how-to-declare-...

This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data:

https://facebook.github.io/immutable-js/

Const-ness in the spirit of languages like Clojure would seem to be a relatively straightforward feature to add, so I don't really understand the philosophy of leaving it out. Hopefully someone here knows and can enlighten us!

Re: Toward Go 2

#215

Post by w8rbt »

pmarreck wrote: post #141
camus2 wrote: post #127

Earlier quoted context omitted.

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

If it weren't for Goroutines I would not find go very useful. I expect C++ will implement coroutines and/or fibers someday that will be very well designed and more carefully/broadly thought out.

Re: Toward Go 2

#216

Post by cdelsolar »

nightski wrote: post #203
didibus wrote: post #177

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…

Nearly every item on your list is available with OCaml.

Except no one's ever heard of OCaml.

Re: Toward Go 2

#217

Post by osteele »

pmarreck wrote: post #141
camus2 wrote: post #127

Earlier quoted context omitted.

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

That's what kept me from looking at the language for the last five years. I finally broke down and wrote my first Go program. Yeah, the errors (and lack of generics) are annoying, but it gets enough else right – tooling, runtime speed, compilation speed, type inference, parametric polymorphism (on interface types) – that I enjoyed it anyway. Every language has some annoyances; it's nice when there are only a few.

Re: Toward Go 2

#218

Post by Svenskunganka »

spyspy wrote: post #205
pmarreck wrote: post #141

Earlier quoted context omitted.

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

15 Million to 17 Million is not an order of magnitude.

The top 4 keywords in the list are what's used frequently in go to handle errors.

  if err != nil {
    return err
  }
So it's more like 7,7 million to 17,6 million (the top fifth "the" is from comments, so it doesn't count)

Re: Toward Go 2

#219

Post by cdelsolar »

kzisme wrote: post #136
frik wrote: post #110

Earlier quoted context omitted.

Multiple unrelated Go projects in different repos located in different directories. No problem at all with very other language, except with Go - not possible! I want to open cmd.exe (Win) or bash (Linux) and cd to the directory and build. And not configure a GOPATH in the environment variables of the current user or pretend it to the batch script, set it in IntelliJ Go plugin, etc. It so unflexible, so arkward, and t…

This is the sort of thing that makes it hard to get started with Go in my opinion.

It shouldn't be. Set the GOPATH once and use any text editor.

Re: Toward Go 2

#220

Post by vram22 »

pjmlp wrote: post #199
vram22 wrote: post #191

Earlier quoted context omitted.

Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...

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 about it, which were good too. He and his team seem to have taken a lot of pains and thought a lot about the design as well as implementation of the language, from both an academic and industrial use perspective - so it seemed to me.

There is also an interesting anecdote about use of Eiffel in the book, here:

https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

That section shows the the 1st edition of the book did use Eiffel (as I said above).

Post reply on HN