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

Go 1.6 is Released

blog.golang.org

Post reply on HN
Print view View original

291–300 of 367 posts

Re: Go 1.6 is Released

#291

Post by pjmlp »

autoreleasepool wrote: post #286
pjmlp wrote: post #230

Earlier quoted context omitted.

> For better or worse, CS departments across the US produce Java programmers more than anything else. That is real a problem of quality of those CS departments. My humble Portuguese CS department teached me about Pascal, C++, C, Prolog, Caml Light, Smalltalk, Java, Lisp, MIPS and x86 Assembly. Having a quick look at their current curriculum, now around 25 years later, they seem to still provide a good mix.

I have to admit I'm jealous you had such a diverse exposure to programming paradigms. I agree it's a problem. I've always found it odd that the AP test is in Java for example. I would imagine pseudo code would be a better choice for a conceptual test.

And I only listed the official ones.

Those of us, like myself, that opted into the compiler design classes had a quite a few more to play with.

I guess the problem are those universities that tend to be more focused on "languages to get a job" than doing the real work of an university.

Re: Go 1.6 is Released

#292

Post by autoreleasepool »

Myrmornis wrote: post #176
bmurphy1976 wrote: post #42

Earlier quoted context omitted.

You don't have to "get" anything. If Java works for you, great!! Go just works better for some of us, and that's all the justification we need.

This type of comment is common, but specious. It sounds nice: "what works for you; great! this works for me" but it undermines a large category of important discussions: e.g. analyzing which, out of several competing discussions, is a better fit for large classes of people, or on average. In other words, I think this sort of comment strays too far in the direction of niceness, and tends to undermine simple, and desir…

I didn't even interpret that as politie. That's the kind of "polite" comment I would make if I thought you were being an an aggressive idiot and I didn't care to help you.

i.e. You think Andoid apps have the same revenue potential as iOS apps? That swell! Good for you buddy, whatever works for you is fine with me :) (Now go back to your cubicle and stop bothering me me.)

Re: Go 1.6 is Released

#293

Post by twistedpair »

loudmax wrote: post #288
twistedpair wrote: post #284

Earlier quoted context omitted.

> When different code needs different JVMs With the JVM you can use HotSpot, Dalvik, WebSphere, or OpenJDK. The JVM is just a spec. With Go, you've only got one runtime to choose from. That said, if you code to the JVM spec, then you don't care what implementation you run on.

> With Go, you've only got one runtime to choose from. Since Go compiles to a binary, the concept of a runtime doesn't apply the same way it does for Java. You can compile a Go program with the Go project's compiler or with the GCC. The GCC Go compiler uses different optimizations and may produce faster binaries in some circumstances. Since the Go language is also a spec, other compilers may arise if there's a demand…

Correct. With Java I've got at least 4 compilers (JDK's) to choose from.

Re: Go 1.6 is Released

#294

Post by sigjuice »

golergka wrote: post #289
sigjuice wrote: post #175

Earlier quoted context omitted.

What is horrible about $GOPATH?

The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely. For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is an…

I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.

Re: Go 1.6 is Released

#295

Post by redtuesday »

masklinn wrote: post #270
iends wrote: post #201

Earlier quoted context omitted.

I've found that there is no real standard definition of what OOP is and people get very angry when you say Go is OOP but it doesn't have inheritance. YMMV though.

As far as Alan Kay is concerned (always a pretty good yardstick) > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late binding of all things.

Yeah, I like this posting from him http://c2.com/cgi/wiki?AlanKayOnMessaging

Re: Go 1.6 is Released

#296

Post by protomyth »

tumdum_ wrote: post #121
protomyth wrote: post #78

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled vers…

1) Was this static C library? Then you need to recompile. If it was dynamic then the question is did abi change? If yes, you need to recompile, otherwise you don't (but security updates usually don't break abi). 2) Always. 3) Yes, Go runtime is linked in to executables build with Go.

Does Go include external libraries (stuff not written in Go) as dynamic links or static?

Re: Go 1.6 is Released

#297

Post by randallsquared »

teh64 wrote: post #271
johan_larson wrote: post #70

Earlier quoted context omitted.

For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the com…

> JVM configuration This is the mother of all premature optimization. Other than maybe modifying heap size or setting client vs. server, most of the default JVM configurations work for almost everything. > build system configuration I actually find maven pretty easy to use, but maybe it's just that I am used to it. > IDE configuration I don't know what crazy IDE you are using, but both Intellij and Netbeans need very…

To combine the JVM configuration and IDE configuration points, out of the box on a new 16GB Macbook Pro Retina, Intellij (at least, as PHPStorm) will spend an enormous amount of time unresponsive at startup and periodically thereafter. Why? Because of two things: the default JVM settings it ships with starve it of resources, and the default validation settings have it trying to check everything under the sun.

There's also the initial indexing, but I can live with that, since it enables beautifully fast jump-to-definition, which is hard to live without.

Re: Go 1.6 is Released

#298

Post by protomyth »

skybrian wrote: post #99
protomyth wrote: post #78

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled vers…

Best to assume that you will need to recompile a Go program yourself. If you don't have the source and know how to build it, you're in trouble.

I am a bit worried about accepting software from vendors written in Go given those circumstances. For example, the recent OpenSSL patches would be an example. Are the Go programs fine if I update OpenSSL or did they include OpenSSL's libraries statically? If someone writes a Go replacement for OpenSSL does that change the scenario.

Given a lot of software makes it to my door written by government contractors for grant management / compliance, I don't have the source code.

Re: Go 1.6 is Released

#299

Post by protomyth »

spacey wrote: post #124
protomyth wrote: post #78

Can someone give a decent explanation of the following: 1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program. 2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled vers…

3) A compiled Go binary contains the import paths of all used libraries plus all variable names that they are using. Also the header of the binary contains a string like "Go" followed by a hash. If you open a binary in a Hex Editor you will see it yourself.

So I should be able to write a program or one already exists to check if its a Go program and what its dependencies are.

Re: Go 1.6 is Released

#300

Post by lobster_johnson »

infogulch wrote: post #227
lobster_johnson wrote: post #158

Earlier quoted context omitted.

As zenlikethat points out, "goimports" works around this weakness. For Atom, this package works great [1]. It's so damn arbitrary, though; it refuses to let you have unused imports (which is not a source of bugs) but will happily allow you to shadow variables (which is a serious source of bugs) without even warning you. Super weird. [1] https://github.com/abiosoft/atom-go-imports

You're looking for go-plus [0]. Set the Format Tool to goimports, check Run Lint Tool on Save, check Run Go Vet Tool on Save, and add these vet arguments: "-shadow=true -shadowstrict=true". You may have to leave off that last argument for your own sanity. I found that 'shadowstrict' drives you mad at first, but you end up making better code for it -- mirroring my general experience with all the things about go that a…

I was already using go-plus, but I think the addition of goimports is something recent — it wasn't there when I last looked. Thanks for the pointer.

I know that "go vet" can warn about this, my point was that it's amazing that Go refuses unused imports but allows shadowing. It reveals a very skewed idea of what is important when compiling.

Post reply on HN