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

Go 1.4 is released

blog.golang.org

Post reply on HN
Print view View original

211–220 of 265 posts

Re: Go 1.4 is released

#211

Post by codemac »

bradfitz wrote: post #30
codemac wrote: post #21

And they actually stuck with their go generate design? What an unfortunate mis-step. Let the makefile's continue. I've seriously thought about moving to gccgo just to try and get a build system where I can actually inject dependencies on .go files builds again.

You seem to be confusing compilers and build systems. You can use whatever build system you'd like and with whichever compiler.

I'm not sure what you define as a build system, but it's even in the description of the go build tool (https://golang.org/doc/articles/go_command.html):

> An explicit goal for Go from the beginning was to be able to build Go code using only the information found in the source itself, not needing to write a makefile or one of the many modern replacements for makefiles. If Go needed a configuration file to explain how to build your program, then Go would have failed.

And the hope is that go generate would be a hook into the dependency graph of go build. Much like the architecture switches, the naming conventions, etc, it seemed like it really could have solved my project's protobuf problem.

But it's not, and for reasons that rob pike's doc and the mailing list did not make clear. It looks like a mis-step to me, and I don't think it's due to my misunderstanding of what `go build` and 6g/gccgo are

Re: Go 1.4 is released

#212

Post by bsaul »

jud_white wrote: post #185
bsaul wrote: post #85

Earlier quoted context omitted.

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are used to such a different type of programming, i don't expect them to accept banging their heads on so many walls for such little gains. Ps : my stand is the opposite for server side dev.

> no good IDE LiteIDE is open source, cross-platform and pretty enjoyable. https://code.google.com/p/liteide/

It's the one i'm currently using, but calling it enjoyable is really excessiv. You can't compile or get any kind of completion while running your program, you can't define a script to be called when hitting "run" ( it always tries to launch your current file). It doesn't have any kind of macro or refactoring features, etc..

Coming from xcode and pycharm, it still feels a decade younger.

Re: Go 1.4 is released

#213

Post by jksmith »

rivo wrote: post #74
_RPM wrote: post #5

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

It's Go's simplicity that really struck a nerve with me. I've been coding for over 30 years now (Basic, ASM, C/C++, Java, Python, PHP, JS, Clojure) and with Go, I just love how everything is laid out for you: idiomatic Go, formatting, commenting, unit testing, concurrence, standard libraries etc. I don't have to research the basic tools. It keeps me focused on the task at hand. I'm very productive with Go. We have it…

Preach it! Been using Go for a while now, and I haven't been able to keep this much of the problem domain in my head since my days coding in M2. IMO, that's the point of Go.

Re: Go 1.4 is released

#214

Post by spopejoy »

jrockway wrote: post #172
NateDad wrote: post #156

Earlier quoted context omitted.

There is almost never code that requires inheritance.

Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste. "Give me an object like Foo, but with this one little thing changed."

More than just "in practice", it might be worse than copy/paste. Richard Gabriel nailed it in the 90s when he identified inheritance as a form of compression, not reuse, forcing the programmer to have to understand every class under inheritance to understand any part of it:

Compression is a little dangerous because it requires the programmer to understand a fair amount about the context from which compressed code will take its meaning. Not only does this require available source code or excellent documentation, but the nature of inherited language also forces the programmer to understand the source or documentation. If a programmer needs a lot of context to understand a program he needs to extend, he may make mistake because of misunderstandings.

(from Patterns in Software, which is a really deep if long-winded book)

Re: Go 1.4 is released

#215

Post by jimbokun »

pjmlp wrote: post #105
pjc50 wrote: post #101

Earlier quoted context omitted.

Sort of. On Linux, libstdc++ depends on the NSS system which dynamically loads libraries to implement things like getpwent(). Last time I had to actually make a portable static executable (admittedly some years ago) this was a real problem, and it was easier to statically link everything except libstdc++, then ship a copy which was loaded using RPATH in the linker settings.

This is however a tooling issue, not a programming language one.

And Go's tools have a great reputation.

(Disclaimer: Not a Go programmer, just read articles about it.)

Re: Go 1.4 is released

#216

Post by gillianseed »

bsdetector wrote: post #203
lazyjones wrote: post #176

Earlier quoted context omitted.

- garbage collection - safe and easy programming (really!) - no more shooting yourself in the knee with hard to debug problems - lean but quite complete standard library - native strings (proper unicode/utf-8 handling) - very little boilerplate, sane defaults - concurrency primitives (no tacked-on libraries) - high performance - not far behind C/C++ - extremely easy and practical documentation features (via comments)

Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall. Really, things like concurrency primitives as a point in Go's favor? Running code on several processors at once is where it's good to have a library because there are tons of knobs like priority and scheduling policy for instance; it's been trivial to deadlock or a…

>Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall.

C# on Mono certainly isn't significantly better performing than Go from my experience, which is substantiated by Go winning all but one of the 'Benchmark Game' benches, typically by quite a wide margin:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

And Go is not doing that bad against Java either:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Re: Go 1.4 is released

#217

Post by jacques_chester »

bradfitz wrote: post #7
_RPM wrote: post #5

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

You can also add numbers on an abacus. It _works_. Put in a less snarky way, C is often way more low-level and tedious than you need. The great thing about Go is that it lets you blend high-level and low-level programming in the same program, only getting low when you need to. It feels like a great mix of C and Pythonubyerlhphavascript. I've given many talks on this, e.g. http://talks.golang.org/2014/gocon-tokyo.slid…

> The great thing about Go is that it lets you blend high-level and low-level programming in the same program

Where are map, reduce, select, filter, fold, zip ...?

I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too.

And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I could tell, trying to tug on my leg.

Re: Go 1.4 is released

#218

Post by fit2rule »

mholt wrote: post #10
_RPM wrote: post #5

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

Once Go is installed, I can make a simple web app from scratch that displays parameters from the URL or request body in just over 95 seconds with Go, using only the standard library. I can cross-compile it for another OS and architecture, then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults. Try doing that in C/C++. Maybe a better comparison is to more systems-level appl…

>>>>Try doing that in C/C++.

Lua.

Re: Go 1.4 is released

#219

Post by slm_HN »

teddyh wrote: post #54

This relatively recent trend of company-specific languages annoys and disturbs me. I don’t ever want to be tied to a language and library ecosystem under the thumb of a single (large) corporation. Not Visual Basic, not .NET, not C#, not Objective C, not Go (It’s even named after the company, for crying out loud! Yes it is. Don’t try to claim otherwise). I’ve used Basic, I’ve used Pascal, I’ve used C, I’ve used Python…

>but the language was not “owned” by a single company which would loom in everyone’s mind, always the unspoken fear being “what if doesn’t like it?”. >I will not use tools which make me afraid. I will not live a life in fear.

This is a very emotional response. It uses the language of emotion: fear, afraid, even the odd emphasis of the words owned and loom. Unfortunately for you Hacker News tends to be logical and analytical.

Personally I don't fear any tools, except for table saws, which combine extreme sharpness with a dangerous axis of rotation that can lop off fingers or propel a 2x4 through your abdomen with ease.

Oh, I also fear C++, which is the table saw of the mind.

Re: Go 1.4 is released

#220

Post by SEJeff »

bsaul wrote: post #85
alfiedotwtf wrote: post #6

Earlier quoted context omitted.

And now things just got interesting. I'll put my money on the availability of Go on Android being the catalyst for its future hockey stick growth.

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are used to such a different type of programming, i don't expect them to accept banging their heads on so many walls for such little gains. Ps : my stand is the opposite for server side dev.

Got has inheritance, or at least the same idea, just done a bit differently:

http://golangtutorials.blogspot.com/2011/06/inheritance-and-...

I'd also argue that by being designed to be machine refactored and parsed (unlike some dynamically typed languages), go is easier to wrap with an IDE for refactoring stuff.

Post reply on HN