Live data from Hacker News

The State of Go: Where we are in February 2016

talks.golang.org

181–190 of 224 posts

Re: The State of Go: Where we are in February 2016

#181

I develop a lot of command line tools for Linux using shell scripting. The scripts are getting huge and ugly, so I have been looking at Go and it seems I can do so many things by just using the standard library and in general a big improvement over using scripting. However, everytime Go is discussed at HN I see many posts criticizing the language for various reasons and this has put me off getting started learning Go…

I'm doing much the same as you. command line tools for linux, windows and os x and really like go for that use case. the incredibly easy distribution of the final tools make life awesomely easy.

Re: The State of Go: Where we are in February 2016

#182
post #157

Earlier quoted context omitted.

Great tooling? Does Go have any quality IDEs with integrated debuggers yet? I feel that open source developers mean something entirely different with the phrase "great tooling" than developers used to Visual Studio would mean. :)

Absolutely! They do not mean big GUI based IDE when they say tooling. Infact this is why Go will remain unviable option to .net developers. Go is likely to be much more popular among dynamic languages users and even some Java developers who are tired of enterprisey bloat.

Does go even have any good command-line debuggers? All of the things I've seen either involve insanity like preprocessing your source to inject hooks in between each line of code, or don't actually work.

Re: The State of Go: Where we are in February 2016

#183

Earlier quoted context omitted.

GC changes is a big one in the JVM, but not so much in Go (so far) as Go offers basically no GC tunables. So while your awesome CMS tweaks from JDK7 become worthless once you switch to G1 on JDK8, with Go all you can do to optimize the GC is to create less garbage to begin with. Not trying to say one approach is better than the other: Go's approach is operationally simpler but far less sophisticated than the JVM's.

>as Go offers basically no GC tunables. This isn't actually true, Go has a single tunable: "GOGC" https://golang.org/pkg/runtime/

I consider that "basically no" compared to Java's daunting array of options.

Re: The State of Go: Where we are in February 2016

#186
How about adding a flag to the bloody compiler to allow me to compile my code with unused bits?

I refuse to touch Go until that happens. Go is the asshole of programming languages. It forces you to put code in deeply nested annoying directories

    vim foo.go
    vim ../../../github.com/blahblah/moreblahblah/blah.go
    sigh
But that I could live with. But constantly commenting the code out (which of course leads to commenting out even more code!) is the real PITA.

All said and done it looks like a useful, if uninspired, language. Can avoid it so may as well use it. But this nonsense has to stop!

Re: The State of Go: Where we are in February 2016

#187
post #178
post #175

Earlier quoted context omitted.

The default behavior has to be backwards compatible, so there was only one serious option.

What? They could have done any number of things. They could have added a parameter "-trim" that's more clear than the "-" alone. They could have made it "8<" that looks like a little pair of scissors. Or they could have actually spent some time thinking of a good idea instead of those ones that are about as a bad as the one they went with.

The idea they went with, which was one of the ones I proposed, is used in a variety of open source projects, so it had the advantage of being somewhat familiar and vetted. And what I meant to say is that they had to modify things in a backward compatible way, which means keep whitespace by default and trim with new syntax.

Re: The State of Go: Where we are in February 2016

#188
post #4

{{range . -}} {{.}} {{end -}} This seems like a bit of a hack to be honest. Would anything break if {{range .}} {{.}} {{end}} worked as expected?

That ticket was created by me, and yes, treating whitespace like that would obviously break plain text templates and anything else where whitespace is significant. Remember that Go templates are for more than just html. What about generating CSV files for example? Plaintext emails? I use it for generating Go code, so the whitespace is sometimes significant (to terminate a line of code) but moreover careful control of whitespace is necessary to get readable code.

Re: The State of Go: Where we are in February 2016

#190

I develop a lot of command line tools for Linux using shell scripting. The scripts are getting huge and ugly, so I have been looking at Go and it seems I can do so many things by just using the standard library and in general a big improvement over using scripting. However, everytime Go is discussed at HN I see many posts criticizing the language for various reasons and this has put me off getting started learning Go…

I'll never use Go personally myself, but criticisms on a forum are a bad reason for not using a language, if you think it will be a good tool (as you seem to do) for your purposes
Post reply on HN