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

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

281–290 of 291 posts

Re: Eight years of Go

#281

Post by hackerfromthefu »

coldtea wrote: post #209
kjksf wrote: post #159

Earlier quoted context omitted.

For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).

> Don't blame the language for your buggy code. No, DO blame the language if its the one that enables and allows for said buggy code when it could as well prevent it. Case in point: http://lambda-the-ultimate.org/node/3186

Fair enough, in that case.

However a common situation is that the language is supporting a wide range of uses, not just the use a particular developer has in mind at the time.

I've seen this most commonly where a developer operating at a higher level of abstraction, without understanding low level details, complains that the language doesn't match his high level needs exactly.

When in fact it supports lower level operations for maximum performance or flexibility, while allowing layering on top for higher level uses. In language design it's essential to support the lowest level use cases you are targeting, because you can build on top but not go lower than the language exposes (unless it supports embedded asm or another trick to go lower again). I'm using higher/lower here only to refer in the sense of the level of abstraction.

It's a really common trap for someone working usually at one level of abstraction and not deeply understand other levels, to not understanding why a language or library is the way it is because if needs to support others users needs that are different to ones own - I've done it myself enough to detect the pattern, and seen lots of other people do it. Lurking on design committee discussions can be eye opening!

Re: Eight years of Go

#282

Post by hackerfromthefu »

pjmlp wrote: post #227
nine_k wrote: post #202

Earlier quoted context omitted.

Would you rather have them use C++? In this regard, Go is a lesser evil.

Yes, as long as it was modern C++, not C compiled with C++ compiler. Or any modern natively compiled language.

That's kind of part of the problem - with C++, or Java, or C#, you can write in 15 different styles, syntactically valid but quite possibly unreadable to another programmer who is experienced in the language. That's because there isn't one idiomatic standard for the code, there's 15++, and the language has the complexity that enabled that mess.

If you want to work in a kitchen sink language (and I often do haha), just use one of the many available.

But perhaps you're missing the value of simplicity? It is after all the main strength of Go, and a rare commodity in software engineering these days.

Overall I think it's a shame to have less choice, and we lose something by making all languages too similar (in both features, and at the meta level in complexity).

Re: Eight years of Go

#283

Post by hackerfromthefu »

rifung wrote: post #75
weberc2 wrote: post #53

Earlier quoted context omitted.

> by far most of the Go developers still prefer to use the language without generics I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.

I write Go at work but have never heard anyone say this. Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?

Not OP, and this is only one aspect to consider, but it's from experience - when generics were added to C# the language became nicer to use, but it caused a lot of churn and added complexity. The base libraries have the original non-generic classes as well as newer generic ones.

As I've written above, there's huge potential to be the language that doesn't churn, when just about everything else does these days.

Re: Eight years of Go

#284

Post by hackerfromthefu »

jackmott wrote: post #157
weberc2 wrote: post #53

Earlier quoted context omitted.

> by far most of the Go developers still prefer to use the language without generics I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.

yes, but those of us who would desperately like to use Go because there are vanishingly few GC languages that compile to native exe AOT, won't because of no generics. So it is a bit of a tautology. How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much be…

Have a look at .NET Native with .NET core, it support AOT compilation with GC, and a very fully featured language and cross platform targets.

see https://blog.rendle.io/what-ive-learned-about-dotnet-native/ https://stackoverflow.com/questions/29609993/difference-betw... https://docs.microsoft.com/en-us/dotnet/framework/net-native...

Re: Eight years of Go

#285

Post by hackerfromthefu »

noncoml wrote: post #116
wheaties wrote: post #44

Earlier quoted context omitted.

The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.

Fair enough. I should have said one of the best. A bit of sensualism there.

Really love your language ;)

Sensationalism maybe?

Re: Eight years of Go

#286

Post by Vendan »

spc476 wrote: post #199
cube2222 wrote: post #136

Earlier quoted context omitted.

Why would you want a supervision tree? This would suggest using an actor-like model, which is pretty senseless for single-machine usage. It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash". I'm not sure, but I think this also ends up being good for modelling interactions with good performance…

Wow! My network daemon at work, written in Lua (which uses Lua coroutines for processing, which are similar enough to Go routines/channels for this comparison) has a supervision tree. It can log the unexpected death of Lua coroutines and keep going, which is nice for the unexpected bit of input [1]. It's also helpful when testing new code as unexpected errors are logged (stack dump, so the location of the crash is re…

Go can do almost the exact same thing, in fact, it's baked into the stock http server library.

Re: Eight years of Go

#287

Post by koffiezet »

coldtea wrote: post #153
freyir wrote: post #72

Earlier quoted context omitted.

It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that. But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.

> Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. And many more want Generics without having responded to the issue. Issues are representative as a sampling, not absolute numbers.

And then there are many Go users, who don't really care for generics, or like me, think generics could be nice, but could also make the language more complex than desirable.

If someone came up with a practical, clean, working proposal for Go - then absolutely. But so far I've only seen complaints and proposals where the conclusion starts with "this proposal will not be adopted" - mostly because it's somehow flawed.

Re: Eight years of Go

#288

Post by weberc2 »

peoplewindow wrote: post #258
jackmott wrote: post #157

Earlier quoted context omitted.

yes, but those of us who would desperately like to use Go because there are vanishingly few GC languages that compile to native exe AOT, won't because of no generics. So it is a bit of a tautology. How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much be…

What's the big need for an AOT native EXE for you? You just don't want to copy a directory tree instead of a single file?

Not OP, but I can't execute a directory tree. I always seem to need a runtime, and often additional libraries and a bunch of `$*PATH` munging so the compiler locates the _correct_ dependencies.

Re: Eight years of Go

#289

Post by nishs »

simon_o wrote: post #130
atmosx wrote: post #32

Earlier quoted context omitted.

I’ve read the first article. It was eye opening, cause I am writing a bot right now and using exceptions to control input flow. Made me think about my design. That said, it does not argue against exceptions. So, I am not sure what your argument is.

Exceptions are bad outside the "your computer just started burning" cases, but Go has replaced them with something even worse, "multiple return values". So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options: - ( value, no error) - (no value, error) - ( value, error) - (no value, no error) An…

The last case is rarely seen in Go (at least not in the standard library).

Accepting for the moment that Go has no exceptions and and error returns are the way to go, the first two cases make sense.

The third case ( value, error) is actually useful in several scenarios. For instance, considering you're writing bytes to a stream that fail partway. The value is the number of bytes return so far and the error is the error that was encountered. In fact, this is the signature that the ubiquitous io.Writer's Write method uses.

If all you had was single return values (aka "int or throw Exception"), how would you model the io.Writer?

Re: Eight years of Go

#290

Post by noncoml »

hackerfromthefu wrote: post #285
noncoml wrote: post #116

Earlier quoted context omitted.

Fair enough. I should have said one of the best. A bit of sensualism there.

Really love your language ;) Sensationalism maybe?

Yes, of course, thanks for correcting me!

WTF is wrong with me?? I should be banned from this forum for life!

Post reply on HN