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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

171–180 of 402 posts

Re: The State of Go

#171

Post by dilap »

Groxx wrote: post #124
dilap wrote: post #109

Earlier quoted context omitted.

Fair point! And I certainly don't claim that the Go devs don't make mistakes. They started with the theory that the problem should solved as Google does, by arranging that clocks don't run backwards. When it become clear that wasn't reasonable, they moved towards a new solution in a way that I felt was impressive.

It's mostly-impressively backwards compatible, I'll definitely agree there. It's clever, and in many cases it'll do the right thing automatically. Since it seems that's their goal, they achieved it quite elegantly, and that's a tricky thing to do. (edit: and quite quickly! seriously, this is an example of a healthy community at its best) But personally I don't agree with the decision - it adds surprises when you try…

There's no denying it's at least flirting with "too clever" territory. What saves it for me is (1) the analysis of a large body of code that seemed to show only positive impact (2) that the behavior is well-documented and (3) anytime you're converting between types, you should always be thinking, "what is the range of these types? what information might get lost?", which with (2), should leave you alright.

But, I could easily see looking back in 2 years and realizing you were right.

Re: The State of Go

#172

Post by pjmlp »

vvanders wrote: post #155
IshKebab wrote: post #77

Earlier quoted context omitted.

Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python. People comparing it to C++ and Rust miss the point.

Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

> To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

Having a GC doesn't forbid that, in very specific cases.

Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, System C#, Swift, D are all examples of such languages.

Re: The State of Go

#173

Post by prodigal_erik »

omginternets wrote: post #160
aeturnum wrote: post #86

Earlier quoted context omitted.

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars. Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's…

>Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it. Agreed, and I'd further argue: 1) most people driving Ferraris aren't skilled enough to drive them properly 2) most people driving Ferraris have no need to corner at 120 MPH 3) most people driving Ferraris are just trying to show off 4) most people driving Ferraris are more likely to hurt t…

It's an apt metaphor. Much like programming, there are a hell of a lot of people driving who really shouldn't be.

Re: The State of Go

#174

Post by randomdata »

algesten wrote: post #143
randomdata wrote: post #104

Earlier quoted context omitted.

I wonder this too. For how important generics are claimed to be, it does seem strange that nobody has stepped up and helped out the core team in this capacity. They have been quite open about wanting generics, but do not have the resources to dedicate to implementing them in an acceptable fashion. But being an open source project, anyone can step up to fill that void.

How can a google backed project not have the resources?

I don't know, but Google does frequently complain about not being able to find talent. Some of this is through fault of their own, but it is easy to imagine that they have not found suitable developers to fill the spot, for whatever reason it may be. They have lots of other business goals for what developers they do have. Putting their people on generics at the cost of some other business function may not be a good choice, even if it is theoretically possible.

Re: The State of Go

#175

Post by pjmlp »

labrador wrote: post #41
greg7mdp wrote: post #38

Earlier quoted context omitted.

How can you write an efficient container without generics?

I keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code

It would be wasted work, because no one in the community would take it.

So better spend that time contributing to other parts of the Go ecosystem, or another programming language project.

Re: The State of Go

#177

Post by baby »

aeturnum wrote: post #86
artursapek wrote: post #20

Earlier quoted context omitted.

What on earth is a "good" language? > you're clearly pitching for that vast bulk of mid-quality developers that make up the huge middle chunk of corporate devs That was actually something Google aimed for with Go, and I don't see what is shameful about it. It's a simple language on purpose. It is meant to be easily learned by any developer, and similarly Go code is meant to be easily read. Also, what sets Go apart fo…

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars. Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's…

> It's not necessarily a joy to drive

Go is the most fun language I've been using. On the contrary, I don't understand how some people can enjoy Java.

Re: The State of Go

#178

Post by baby »

user5994461 wrote: post #43
grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

Java reigns supreme because there is nothing which come close to its characteristics in terms of capabilities, libraries supports, tooling, performances, easiness to learn, simplicity and maturity. If you want faster or lower level, you gotta move to C++, which is uber-hardcore in terms of non-simplicity and impossible-to-learn. If you want easier, you gotta move to python/ruby/node.js, which are a joke in terms of p…

How is Java easy to learn, you need a huge IDE, I don't know how many SDKs or dependables and two pass compilation and 1000 layers of abstraction, ...

Re: The State of Go

#179

Post by zzzcpan »

sidlls wrote: post #164
vvanders wrote: post #155

Earlier quoted context omitted.

Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.

You can relatively easily get to manual memory management using Go's runtime, i.e. access those runtime·sysAlloc(), runtime·sysFree() functions directly, the way Go accesses syscalls in the external sys package [1]. It's like ten lines of code, nothing extraordinarily difficult.

[1] https://github.com/golang/sys/blob/master/unix/asm_linux_amd...

Re: The State of Go

#180

Post by yawaramin »

chimeracoder wrote: post #74
joaodlf wrote: post #14

I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric la…

> But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, ...

It's not a criticism, it's literally how the Go language creators themselves describe it. See the Rob Pike quote at http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

Post reply on HN