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

91–100 of 402 posts

Re: The State of Go

#91

Post by Groxx »

rpercy wrote: post #62
stefano wrote: post #54

Earlier quoted context omitted.

It's the same cognitive load, really. Instead of deciding how to best propagate exceptions, you're now deciding how to best propagate the error value.

Not really. In a language like Java, some of the questions I'd have to ask myself are: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Should I throw a checked or unchecked exception? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataS…

>check if err != nil, prepend a descriptive message, and return it.

That'd be the RuntimeException equivalent, sure. But what do you do for the equivalent of checked exceptions? Errors are frequently recoverable, "err != nil" alone does nothing to help you there, and string manipulation is a horrific alternative to types.

Re: The State of Go

#92

Post by artursapek »

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…

> Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it.

I agree with everything you wrote except this. After 3 years in a job where I had to use Ruby on Rails, I am utterly tired of "magic" and I regret the many hours of my life I have wasted debugging issues that were created/concealed by it. Lack of magic is a feature in my opinion. But as you said, that's all this is - opinions.

Re: The State of Go

#93

Post by mattnewton »

DrBazza wrote: post #42

Given some of the comments, I'll make the same comment I've made before: Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. I'm a C++ dev, and I really enjoy using Go. If you don't like what it does or how it does it, it's not for you. Either way, people are out there using it, making systems from it, and generally getting on with…

Idk if that's such a clean binary, one of my favorite languages is Haskell, and people both complain about that and don't use it :)

Re: The State of Go

#94

Post by sambe »

naaaaak wrote: post #2

Awful to try to read on mobile. Regular page anywhere?

Completely unusable, perhaps the worst in recent memory of any front page article. Strange thing is that previous Go presentations have looked almost identical aesthetically but worked well.

Re: The State of Go

#95

Post by geoka9 »

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…

Using a similar metaphor, I'd compare Go with a jet that's high performance but easy to fly - i.e. it doesn't have the numerous gotchas and quirks high performance jets usually have that the pilot has always have to keep in mind to avoid shooting themselves in the foot (aka making a hole in the ground :)).

E.g. it won't let you overload your engine by using a very special feature that lets you get away with it, but it'll let you fly fast and enjoy afterwards how trouble free the experience was.

OK, I think I'll stop with the mataphors now :)

Re: The State of Go

#96

Post by DougBTX »

zzzcpan wrote: post #19
rusbus wrote: post #11

I was glad to find they made it much easier to define custom sorts for slices. But! Why on earth does what should really be syntactic sugar make sorting nontrivially slower? It speaks to the lack of expressiveness in golang that you can't make sorting less egregiously verbose without adding a performance penalty.

> what should really be syntactic sugar They probably use run time reflections, not a compile time syntactic sugar a.k.a. generics. As Go doesn't have those, so anything like that would require a compiler hack and nobody likes hacks.

Syntax sugar is extra syntax to make an existing feature easier to use, syntax sugar has no runtime impact.

Generics are not syntax sugar, they add functionality such as stricter compile-time type checking and improved run-time performance (e.g., C# can use unboxed primatives in generics)

Re: The State of Go

#97

Post by throw2016 »

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…

I think simplicity is often the most difficult to achieve and requires deep technical expertise to deliver. It shows the creators have thought about the end user and usage scenarios. It would be a mistake to confuse complexity with quality or vice versa.

Re: The State of Go

#98

Post by Groxx »

skybrian wrote: post #83
MichaelGG wrote: post #65

Earlier quoted context omitted.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

I dunno, ruby has some nice tendencies here, like `out = [1,2,3].map(&:to_s)` which is small and descriptive[1].

Compare that to:

    out = []
    [1,2,3].each do |x|
      out.append(x.to_s)
    end
IMO that's not fad material - that's progress. Maps and folds can totally be abused to produce inscrutable nonsense, but for small, common operations they're often much more obviously-correct.

[1]: `&:method_name` is extremely-common shorthand for "call this method"

Re: The State of Go

#99

Post by camperman »

I shall be moving my codebase to Go this year. I'm very impressed at how readable it is, how much thought has gone in to the tooling and support environment and how fast the GC is now. I also must be one of the few people who likes the assembler :)

Re: The State of Go

#100

Post by tu7001 »

MichaelGG wrote: post #65
rpercy wrote: post #10

Earlier quoted context omitted.

Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

I don't know go, can't you write a map in it?
Post reply on HN