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

I’m joining the Go team at Google

spf13.com

Post reply on HN
Print view View original

181–190 of 211 posts

Re: I’m joining the Go team at Google

#181

Post by tqkxzugoaupvwqr »

powerslave85 wrote: post #42
tqkxzugoaupvwqr wrote: post #16

Earlier quoted context omitted.

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

It is not excellent. All other editors I used autoformat Go code after save. There are two types of format provided by IDEA - IDE Format & go fmt. Both not ideal. IDE Format does not format code according go guidelines. It can delete unused imports if you go through options. go fmt does not delete unused imports, and as result code is not compileble. Refactorings are missing in IDEA. It is not excellent, it is someth…

You can create a macro to gofmt when you save. If you desire removing unused imports, you can add “Optimize Imports” to the macro.

Re: I’m joining the Go team at Google

#182

Post by bsdetector »

echlebek wrote: post #180
bsdetector wrote: post #88

Earlier quoted context omitted.

> functions which are known to never be checked for their errors, like fmt.Println In Java println is checked for errors, as it should be. Every Java program that does println either aborts or deals with the error in some way. It matters. Take any program that writes to stdout and run it with ">&-" to close stdout. Because of unix, the next file it opens will be file descriptor 1 and the program will start writing th…

I tried your example, and observed an error: write /dev/stdout: bad file descriptor What "next file it opens" are you talking about exactly? How does what you're describing work?

In unix when you open a file it gets the lowest available file descriptor number. So if you run a program with no stdout (file descriptor 1) then it gets a "bad file descriptor" error anytime it prints something until a file is opened, gets file descriptor 1, then it starts writing to the file.

Example:

    #include 
    int main(int argc, char **argv) {
      printf("first message\n");
      fflush(stdout);
    
      fopen("output", "w");
    
      printf("second message\n");
      fflush(stdout);
    }
Output:

    # ./a.out
    first message
    second message
    # ./a.out 1>&-
    # cat output
    second message
By ignoring the error, the program continued on and then wrote console output messages to the file after it was opened. There have been exploits due to this bug, but the real point is that you could never predict this failure without good knowledge of unix and careful consideration. This is why error codes should not be cavalierly ignored, because it's really hard to know what might happen if you do.

Last I checked, Go operates the same way as this C example. Java fails on the "first message" if stdout is closed so it doesn't trash the file, not because they even specifically thought of this scenario but just because errors are not ignored by default and are not easy to ignore.

Re: I’m joining the Go team at Google

#183

Post by johncolanduoni »

vvanders wrote: post #131
dragonwriter wrote: post #118

Earlier quoted context omitted.

> Go is not a C replacement/better C. Its not a replacement for C in most of the places where C is far and away the best existing choice for a whole project, it is a replacement for C in the zone where C's performance and static typing are attractive and would decided the choice in its favor, but Python's expressiveness, batteries-included stdlib, etc. also make it attractive and make it a little bit painful that the…

Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages. If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.

Re: I’m joining the Go team at Google

#184

Post by gravypod »

sdegutis wrote: post #162
gravypod wrote: post #158

Earlier quoted context omitted.

I'm assuming Lombok and using the new Lambdas. Maybe even a fibers library.

Yep, mostly Lombok (especially @Data for immutable typed objects with automatic constructors without boilerplate), streams, and lambdas.

Personally I think Lombok should be mainlined at some point. It's just so perfect in everything I've tried.

Re: I’m joining the Go team at Google

#185

Post by johncolanduoni »

sdegutis wrote: post #167
pmarreck wrote: post #152

Earlier quoted context omitted.

I watched this, and what I saw was a heck of a lot of information about how to extract information from error values and percolate them together up to a handler, all of which would automatically be present in your everyday stack trace in a language that actually threw unexpected runtime errors. ;) I frankly don't see how this is OK, nor better. Errors are real in the sense that they are evidence that the programmer's…

I don't think the original Go authors ever truly thought that exceptions are "bad" per se. I think they just took it off the table because of the complexity it added to the language, both conceptually and implementation wise. A (the?) primary main goal of Go from the beginning has always been to make implementation as obvious as possible; in other words, to make it a slightly thicker layer on top of assembly than C w…

To whom is the implementation of a generational, concurrent GC obvious? It requires a lot of compiler infrastructure and complex runtime support, much more than stack unwinding. I'm not a fan of, say C#'s, exception model, but it's far from the complexity of features Go already has in either implementation or programmer understanding.

On top of that, unwinding isn't the only way to get something where errors have to be handled or the program dies. Look at Swift's error handling for example: it's basically sugar over returned errors with correctness checks. Dead simple implementation, and dead simple to explain to users.

What I don't buy about the justifications for Go's design is that they were driven by the pure guiding hand of simplicity. It looks more to me like the designers simply treated language features they had seen done badly before as anathema and didn't try to think about how the mistakes could be corrected.

Re: I’m joining the Go team at Google

#186

Post by aurelianito »

cbHXBY1D wrote: post #173
aurelianito wrote: post #30

Earlier quoted context omitted.

If someone makes an alternative go implementation, they should name it baduk or weiqi.

At least it would make the language and ecosystem [slightly] more Google-able.

It would collide with the game. It should be worst in the beginning.

Re: I’m joining the Go team at Google

#187

Post by sandGorgon »

sdegutis wrote: post #162
gravypod wrote: post #158

Earlier quoted context omitted.

I'm assuming Lombok and using the new Lambdas. Maybe even a fibers library.

Yep, mostly Lombok (especially @Data for immutable typed objects with automatic constructors without boilerplate), streams, and lambdas.

are there any opensource github projects that illustrate the use of this infrastructure (java 8 + lombok + streams + lambda) in a very clojure-ish way ?

its hard to find good examples of this style of coding. For example, it is hard to figure out which app server (Spring Boot, undertow, dropwizard, wildfly). I'm sure you can use any... but it would be nice to learn from your experiences.

Re: I’m joining the Go team at Google

#188

Post by pjmlp »

johncolanduoni wrote: post #183
vvanders wrote: post #131

Earlier quoted context omitted.

Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages. If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.

Not .NET Native, which uses the same backend as Visual C++.

Re: I’m joining the Go team at Google

#189

Post by maleck13 »

pmarreck wrote: post #152
javajavaj wrote: post #110

Earlier quoted context omitted.

Dave Cheney gave a talk about error handling in Go that sheds some light on how the Go community thinks about errors: https://www.youtube.com/watch?v=lsBF58Q-DnY

I watched this, and what I saw was a heck of a lot of information about how to extract information from error values and percolate them together up to a handler, all of which would automatically be present in your everyday stack trace in a language that actually threw unexpected runtime errors. ;) I frankly don't see how this is OK, nor better. Errors are real in the sense that they are evidence that the programmer's…

You do also have panic available which is for exceptional cases

Re: I’m joining the Go team at Google

#190

Post by aws_ls »

coldtea wrote: post #170
aws_ls wrote: post #98

Earlier quoted context omitted.

>Sorry, but in what way is Go "revolutionizing"? By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need ? Ideal for minimalists. That's its beauty. Programs are very stable. Takes less memory than Java (some amount more than C/C++). Faster compilation time compared to C…

> By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need? Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start. Due to t…

My question was more rhetorical. But thanks.

After posting, I realized its concurrent programming model, is another thing which I (and many others) am a fan of. I found the channel and go based approach, much better compared to explicit spawning of threads in languages like Java and C++.

Post reply on HN