Live data from Hacker News

I’m joining the Go team at Google

spf13.com

11–20 of 211 posts

Re: I’m joining the Go team at Google

#11
post #4

Why do people find the need to write about themselves in third person? https://stevefrancia.com/

As a habit it is bad, but this is actually standard for short bios. It allows it to be dropped in place directly for conferences, PR shots, news articles, etc without any rewrite.

Re: I’m joining the Go team at Google

#12
* Interfaces which can have fields would be really, really great.

* A rust-style borrow checker would make dealing with channels and pointers a lot safer.

* Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should).

* Closed enum sets: some ability to setup an enum type which can be "complete" when used in a switch statement without needing a "default" and which will only panic/fail when a bad type conversion is made. Let me sanitize out a whole bunch of possible errors at one point in my code when I want to use constants (and be warned when I break the guarantees).

Re: I’m joining the Go team at Google

#16
post #3

> What is missing from the Go ecosystem? Personally, golang "IDE" experience is not as good as Java or even C++. For example, ycmd only supports subset of functions for golang. I miss ycmd-goto-references the most.

JetBrains WebStorm with the free Go plug-in provides an excellent Go IDE experience. There are some free community editions of JetBrains IDEs that are supposed to work with the Go plug-in (e.g. PyCharm, if I’m not wrong), so you do not even have to pay anything.

https://www.jetbrains.com/products.html?fromMenu#type=ide

Re: I’m joining the Go team at Google

#17
post #10

> Go has the nearly perfect balance of readability, expressibility and simplicity Is Go really expressive?

No, it's verbose and recommends bad and repetitive code style which affects both readability and simplicity. The only people who'll find this language "simple" are those who never understood any more "complexities" than functions and loops:

" The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike "

+article: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

Re: I’m joining the Go team at Google

#18
post #10

> Go has the nearly perfect balance of readability, expressibility and simplicity Is Go really expressive?

It is pretty readable, but really non-functional too. Eg, they still don't have math.round and you wind up writing a lot of code because it can be a little bare bones or does things in a way that isn't quit usable.

I wouldn't say it is very expressive either. Go can be very wordy and verbose at times, and some things are downright a pain or poorly thought out (e.g, while Java has finally and C++/Rust have RIAA for dealing with resource deallocation Go has defer and it doesn't work really well when you encounter an error in the dealloc logic).

Simplicity is about Java 1.0. Give Go some time to add some technical debt before you get too excited about it simplicity.

It isn't a bad language. This is my second run thought the language, and I'm neither excited nor turned off by it.

Re: I’m joining the Go team at Google

#19
post #12

* Interfaces which can have fields would be really, really great. * A rust-style borrow checker would make dealing with channels and pointers a lot safer. * Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should). * Closed enum sets: some ability to setup an enum type which can be "complete" when used in…

My two Golang pet peeves, not very important either:

-still no math.round WTF?

-make() should be syntax and not this quasi-function that takes this vast array of argument types, and while you're at it, you should just rename it `new`, because that's what it is.

Re: I’m joining the Go team at Google

#20
post #12

* Interfaces which can have fields would be really, really great. * A rust-style borrow checker would make dealing with channels and pointers a lot safer. * Equality operations for slices would clean up some ugly parts of the standard net library (addresses are []byte, so a direct x == y doesn't work but seems like it should). * Closed enum sets: some ability to setup an enum type which can be "complete" when used in…

My two Golang pet peeves, not very important either: -still no math.round WTF? -make() should be syntax and not this quasi-function that takes this vast array of argument types, and while you're at it, you should just rename it `new`, because that's what it is.

note that new() already exists in the language.
Post reply on HN