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

171–180 of 291 posts

Re: Eight years of Go

#171

Post by krylon »

TheOtherHobbes wrote: post #95
nine_k wrote: post #42

Earlier quoted context omitted.

Go does have brilliant simplicity! It's the simplicity of Pascal I used in middle school, and of Modula-2 I used on my freshman year, with basically the same syntax. I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon. For writing toy programs to relax (can relate), I personally prefer Python, or maybe a Scheme. While also being simple at the core concepts, they have much more expressive power, a…

Go has human-sized simplicity. Programming language complexity is limited by human cognitive limitations, and Go has a small cognitive load. This makes it feel like a very intuitive language. That doesn't mean it is an intuitive language - just that it feels like one for a specific class of problems. Personally I enjoy using it for the same reasons as everyone else. But... I'm also aware it's quite an old-fashioned l…

There is a good chance you are right.

But as long as it is humans writing most/all Go code, fitting a human brain well is a valid design choice.

Yes, it has its fair share of problems. But for now, I find it preferable to anything else we have got.

Re: Eight years of Go

#172

Post by steveklabnik »

nine_k wrote: post #168
coldtea wrote: post #151

Earlier quoted context omitted.

> I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Many large users writing in company and project blogs have mentioned lack…

I suspect that Rob Pike's and Russ Cox's work is paid for by Google. But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.

We’ve actually worked a lot to ensure that Mozilla can’t dictate what happens with Rust; we run a consensus based process, and while Mozilla has the largest single group of people involved in leadership, it’s still a very stark minority.

As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.

Re: Eight years of Go

#173

Post by slrz »

dekhn wrote: post #38
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

Complaints about generics aren't coming from a minority group. It's a majority now.

Thank deity Go language design is not done by popular vote. If you want the Trump of programming languages, you probably have to look elsewhere.

Re: Eight years of Go

#174

Post by krylon »

insulanian wrote: post #129
krylon wrote: post #30

Earlier quoted context omitted.

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…

> sounds weird, I know No, it doesn't.

That is a relief.

I know other people meet a similar purose by knitting or solving crossword puzzles, but explaining to them the trancendetal nature of their favorite pastime is quite difficult.

Re: Eight years of Go

#175

Post by infogulch »

majewsky wrote: post #106
terminalcommand wrote: post #105

Earlier quoted context omitted.

Yes you could, but then you'd have to have both the declaration and the implementation of the interface in the same package. That would mean that if either of them is in a separate file, you'd have to import it. That in return, could easily call hellish compiler errors due to circular dependencies. In Go any circular dependency is an immediate compile error. Looking at the link, the second advice is that you could re…

A possible solution is to have a separate (otherwise unused) package in your codebase with just a test in it: //compile_test.go func TestThatThisModuleCompiles(t* testing.T) {} //list of "type implements interface" tests var _ mymodule.MyInterface = myothermodule.MyStruct{} ... Then you just ensure that `go test` is run, e.g. by the CI.

This can go even further.

All the go files in a directory have to declare the same package name (`package mypkg`), with one exception: a test file (filename ends with `_test.go`) that has a package name that's the same as the normal package but ends with `_test` (as in `package mypkg_test`) is allowed to be in the same directory.

These are actually completely separate packages and you have to import the main package if you want to actually use it. But when you run `go test` it automatically complies and runs tests in both packages. This means that you can import both your package and a dependent package to make sure interfaces are satisfied without any circular dependencies.

Re: Eight years of Go

#176

Post by slrz »

masklinn wrote: post #143
cannam wrote: post #121

Earlier quoted context omitted.

> - No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it This is the one thing in your list that I don't recognise. What is a supervision tree? Can you (or another Erlang programmer) point to your favourite reference?

A supervision tree would be a tree of goroutines where a "master" (supervisor) gets notified when children die (normally and more importantly abnormally). In Go, if a goroutine panics for some reason it just dies on its own and the world does not know unless you have some sort of ping service or you specifically send a notification from a defer. In Erlang, if a process faults and it has a supervisor, the supervisor g…

> In Go, if a goroutine panics for some reason it just dies on its own and the world does not know unless you have some sort of ping service

If a goroutine panics and is not recovered, it not only dies but tears down the whole process. This seems to be the more appropriate approach for a language with pervasive shared state (locks, etc.). Erlang is quite different here, as you say.

Restarting or otherwise dealing with the exiting process is best left to the service manager that started it.

Re: Eight years of Go

#177

Post by coldtea »

nine_k wrote: post #168
coldtea wrote: post #151

Earlier quoted context omitted.

> I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Many large users writing in company and project blogs have mentioned lack…

I suspect that Rob Pike's and Russ Cox's work is paid for by Google. But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.

>I suspect that Rob Pike's and Russ Cox's work is paid for by Google.

They are. The distinction I'm trying to make is they have not been tasked to "create an official Google language for Google scale projects", nor what the language officially adopted as "THE" google language the way e.g. Kotlin was officially adopted as a language for Android programming.

Some googlers (Pike and Cox among them) sat and designed a language that they thought would be good for Google scale programming (according to their ideas and experience) and they went and implemented it. Google paid their salaries the whole time, but at least at first, not for the purpose of creating such a language. After the language is out it paid, and even added more people, to keep it going --it gives good PR, and can be used internally here and there, so that's worth it to them.

It's just not "the Google language" in the way Obj-C/Swift are the Apple languages and C#/VC++ is the MS one (the company heavily investing in them, explicitly asking them to be built, suggesting their use everywhere, etc. For Google it's more of a side project than what e.g. Lars Bak worked on.

Re: Eight years of Go

#178

Post by ramchip »

cube2222 wrote: post #136
brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

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…

Idiomatic Erlang involves handling only errors that are expected (read: part of the program’s specification), and crashing on any other kind of error. This keeps the error handling out of the business logic and makes the app code simpler and more reliable.

For instance, you can’t forget to close a socket, release a lock, or log the actor state and stacktrace, since these things are handled by the VM and supervisors when an actor dies. These are nice properties to have even in a single-node system if you’re aiming for high reliability.

I do agree though that a supervision tree doesn’t make as much sense in Go, since the VM does not provide the cleanup guarantees and strong process isolation that make the Erlang model really workable.

Re: Eight years of Go

#179

Post by dozzie »

cube2222 wrote: post #136
brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

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…

> 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".

Supervision tree gives a structure to put whole subsystems somewhere, including their boot initialization and shutdown (not just restarting it at crash), allows to spawn workers while keeping usual logging/crash monitoring for free, gives a way to inspect the system at runtime (much easier debugging), and allows to run several different applications in the same VM space, which is a flexible way of combining code. I can, for instance, run a CouchDB instance with bolted on my own HTTP server that exposes monitoring data or an administrative interface. It cannot be done in Go (or any other language, barring maybe Lisps) without modifying source code.

And no, none of this "spans multiple machines", it all works and helps on just one single node. Maybe except for debugger, where you spawn a shell node from which you operate.

And yes, your goroutines will "just crash" in situations you haven't expected, as every non-trivial daemon experiences crashes on transient bugs. Though in Erlang transient bugs don't bring the whole daemon down. Saying `my goroutines won't "just crash"' means `my code and code I use as libraries doesn't have bugs, ever'.

Re: Eight years of Go

#180

Post by baby »

rdsubhas wrote: post #41
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

I'm not sure what you mean by vocal minority's complaints. Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac... (I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well) Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded a…

Thanks for pointing that out, I went there to downvote the issue.
Post reply on HN