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

A Farewell to Go

churchwood.at

Post reply on HN
Print view View original

61–70 of 85 posts

Re: A Farewell to Go

#61

Post by disconnected »

notheguyouthink wrote: post #57
disconnected wrote: post #33

Earlier quoted context omitted.

I certainly hope not. Can't speak for Angular, but in Python land, ~9 years later, people are still cleaning up the fallout of the changes from Python 2 to Python 3. It wouldn't bode too well for such a young language as Go to go through the same process. My personal observations are that Go is gaining a lot of steam in many places. Announcing that they will break compatibility would make those places strongly recons…

> Announcing that they will break compatibility would make those places strongly reconsider their commitment to Go. Umm, they've actually announced the opposite. Not sure why you say that.

I meant hypothetically. Sorry if I wasn't clear.

As in, if in some hypothetical scenario, Google announced that they would break compatibility, it would be bad.

Re: A Farewell to Go

#62

Post by pmarreck »

Qworg wrote: post #25
pmarreck wrote: post #9

http://www.golang.sucks/ is both a better and a more comprehensive critique of Go. Rob Pike's quote about "They’re not capable of understanding a brilliant language" is extremely unfortunate, and a missed opportunity to elevate the art/science of programming and the much larger understanding of information theory in general for all programmers, instead of trying to appeal to the lowest common denominator. My first qu…

"Because many developers have a limited depth of understanding and no desire to increase it" is the pithy but correct answer.

Sham developers accelerating technical-debt spaghetticode, then. ;)

Re: A Farewell to Go

#63

Post by vec »

y0ssar1an wrote: post #37

According to my opinion, a programming language should let a developer use his or her style. gofmt is the best part of Go. Everybody's code looks the same. Broken Package Management This is a solved problem with dep. Switch your Go projects to dep today. In the documentation there is no mentioning of those missing things, you expect from a modern HTTP library. Go's philosophy is "less is more." This is the journey of…

> I guess I didn't need X after all. I just had to write a bit of code.

I guess I don't need functions and variables after all. I just have to write a bit of assembly code (for some definition of "a bit"). When the complaint is that a language is insufficiently expressive, noting that anything is possible at the cost of being more verbose isn't really a refutation.

Re: A Farewell to Go

#64

Post by pcwalton »

verroq wrote: post #52
matthewmacleod wrote: post #51

Earlier quoted context omitted.

That's a glib answer. You end up with a bunch of duplicated code when you do this.

How often do you implement generic data structures in your code? The last time you wrote one was probably in your data structures class.

The last time I wrote one was a few weeks ago. I've written dozens of them during my career.

Re: A Farewell to Go

#65

Post by txru »

hardwaresofton wrote: post #20
sergiotapia wrote: post #2

Haven't used Go in about a year and change, is Google going to pull an Angular and pull the rug out from under developers for Go 2.0?

The fact that Go is small, has a large community (outside googlers), and has a completely open spec makes it one of the least likely languages to just fade into obscurity. The Go language accomplishes some amazing things so far, and it a pretty decent choice in the systems-programming space. Even if google dropped it, there would almost definitely be another company or group willing to be it's benevolent dictator(s).

Isn't it somewhat problematic to consider Go as being in the systems programming space? A garbage collector seems like a pretty good disqualifying factor for that.

Re: A Farewell to Go

#66

Post by tcard »

didibus wrote: post #60
crb002 wrote: post #31

Go's most impressive feature to me is it's build ecosystem. Took one of Tyler Treat's experiments and had it running within 30 minutes, no real previous Go build experience. The language itself? Meh. Python/Haskell/C/LLVM IR cover my use cases. I see Go as another wrapper on top of LLVM IR when it is convenient and that is it.

I thought go compiled to native directly? Does it use LLVM under the hood?

The official compiler doesn't. Then there's llgo [0] and gollvm [1].

[0] https://github.com/go-llvm/llgo [1] https://go.googlesource.com/gollvm/

Re: A Farewell to Go

#67

Post by tcard »

brianolson wrote: post #41

Inheritance and Generics: How's the discussion for Golang 2 going? Do we get _some_ code reuse mechanism? Macros? Anything?

At the very least, you get as code reuse mechanisms: functions, ad hoc polymorphism via interfaces, struct and interface embedding, and reflection.

Re: A Farewell to Go

#68

Post by jgrant27 »

Go is a lowest common denominator language designed by a large company to make programmers expendable. It's ironic though because we all know how that worked out after Sun tried it with Java and what we now have some 20+ years later.

Re: A Farewell to Go

#69

Post by notheguyouthink »

disconnected wrote: post #61
notheguyouthink wrote: post #57

Earlier quoted context omitted.

> Announcing that they will break compatibility would make those places strongly reconsider their commitment to Go. Umm, they've actually announced the opposite. Not sure why you say that.

I meant hypothetically. Sorry if I wasn't clear. As in, if in some hypothetical scenario, Google announced that they would break compatibility, it would be bad.

Definitely agree with that.

Re: A Farewell to Go

#70

Post by concede_pluto »

owenmarshall wrote: post #45
eloff wrote: post #36

Earlier quoted context omitted.

Indeed, forget goroutines and channels. The most innovative thing Go brings to programming is gofmt. Between that and the simplicity of the language, it makes it so easy to dive into large foreign code bases and actually understand what you're reading. That's one of Go's strengths.

This is, IMO, one of the things that makes Go exceptionally well suited to enterprise development: software tends to pass around multiple different teams with widely varying skillsets, and tends to have a surprisingly long shelf-life. A simple language with enforced formatting means the code that I wrote several years ago looks much like the code I'd write today. Vendoring dependencies means I can ensure my environme…

> software tends to pass around multiple different teams with widely varying skillsets

I find this to be the most damning drawback: by design you can't ever get better with it, to cater to people who shouldn't be in the profession. There's a reason that using a spoken language clearly and eloquently is beyond the skill of a young child.

I agree that vendoring is the right solution for libraries that are not packaged for your target platform, in fact it's damn hard to reach truly deterministic offline builds without vendoring.

Post reply on HN