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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

371–380 of 402 posts

Re: The State of Go

#371

Post by geoka9 »

josteink wrote: post #356
ovidnis wrote: post #307

Earlier quoted context omitted.

In my Emacs I've got 1) eldoc (displaying signature of function at point), 2) function source lookup, 3) function documentation lookup, 4) flycheck (display compiler err/warn on save), 5) auto-completion. Among a few other things like go-guru integration which I haven't used much yet but I can see its use. All of those features come from editor agnostic golang tools.

Typescript has thee same. Ditto with C#. Python is pretty close. Same with most LISPs. In Emacs too. I'd hardly say this is a unique selling point of Go.

Do they do static analysis of code? The problem is that with other languages they all work "sort of". For example, for Elpy:

"the backends can not always identify what kind of symbol is at point. Especially after a few indirections, they have basically no hope of guessing right, so they don’t"

With go guru it just works, always, no matter how deep you drill into the graph (that's what I meant by "first class").

Re: The State of Go

#372

Post by josteink »

geoka9 wrote: post #371
josteink wrote: post #356

Earlier quoted context omitted.

Typescript has thee same. Ditto with C#. Python is pretty close. Same with most LISPs. In Emacs too. I'd hardly say this is a unique selling point of Go.

Do they do static analysis of code? The problem is that with other languages they all work "sort of". For example, for Elpy: "the backends can not always identify what kind of symbol is at point. Especially after a few indirections, they have basically no hope of guessing right, so they don’t" With go guru it just works, always, no matter how deep you drill into the graph (that's what I meant by "first class").

With C# and TypeScript and all LISPs I've worked with, they work hand in hand with the compiler/runtime to provide absolute correctness at all levels. Absolutely first class. (And I agree Elpy does not qualify for that term)

And while we're on the subject: Only Microsoft had the foresight (or hindsight, insight, whatever) to realize this was a general problem and propose a solution which applies to all editors and all languages:

https://github.com/Microsoft/language-server-protocol

https://github.com/Microsoft/language-server-protocol/wiki/P...

You'd think Google, with their tons of resources could put together a few resources and join a new, future-proof non-NIH standard for Go, but so far they seems to be lagging.

Re: The State of Go

#373

Post by geoka9 »

josteink wrote: post #372
geoka9 wrote: post #371

Earlier quoted context omitted.

Do they do static analysis of code? The problem is that with other languages they all work "sort of". For example, for Elpy: "the backends can not always identify what kind of symbol is at point. Especially after a few indirections, they have basically no hope of guessing right, so they don’t" With go guru it just works, always, no matter how deep you drill into the graph (that's what I meant by "first class").

With C# and TypeScript and all LISPs I've worked with, they work hand in hand with the compiler/runtime to provide absolute correctness at all levels. Absolutely first class. (And I agree Elpy does not qualify for that term) And while we're on the subject: Only Microsoft had the foresight (or hindsight, insight, whatever) to realize this was a general problem and propose a solution which applies to all editors and al…

I agree, a common standard would be good. That said, experience taught me to distrust any proposed standard that comes out of Microsoft. Besides, I find that with the programming editor communities, such standards are not that important - as long as a language has the tooling, it'll be integrated, standard or no standard.

Re: The State of Go

#374

Post by josteink »

geoka9 wrote: post #373
josteink wrote: post #372

Earlier quoted context omitted.

With C# and TypeScript and all LISPs I've worked with, they work hand in hand with the compiler/runtime to provide absolute correctness at all levels. Absolutely first class. (And I agree Elpy does not qualify for that term) And while we're on the subject: Only Microsoft had the foresight (or hindsight, insight, whatever) to realize this was a general problem and propose a solution which applies to all editors and al…

I agree, a common standard would be good. That said, experience taught me to distrust any proposed standard that comes out of Microsoft. Besides, I find that with the programming editor communities, such standards are not that important - as long as a language has the tooling, it'll be integrated, standard or no standard.

This protocol is about reducing the N languages and M editors = N*M client/server implementations with a much better N+M solution, where we don't have to reinvent 200 wheels every time someone makes a new editor or language.

And the protocol is open. Seriously what do you have to lose, besides a shit-ton of redundant work?

Distrust? Distrust exactly what? Are you sure you aren't being your own worst enemy?

See here for a list of fully open source and MS-independent implementations: http://langserver.org/

Re: The State of Go

#376

Post by Hydraulix989 »

4ad wrote: post #369
Hydraulix989 wrote: post #268

Earlier quoted context omitted.

I guess I am a bit more upset about ARM6. How were you testing before? Have you considered using an emulator? Even Linux still supports ARM6.

You can't test properly against emulators like QEMU. Emulators are written to be fast, not accurate (although in absolute terms they are pretty slow), e.g. they execute correct code quickly, but they don't fail to run incorrect code the same way real hardware would do. For example, when I wrote the arm64 Go port, I quickly discovered that the emulator would not cause a trap on unaligned memory access! Incorrect code…

Coming from the silicon chip validation world, I mean the actual definition of "emulator," not the abused version of the word that actually means "simulator."

Sorry, I thought it would have been more obvious in this context -- it wasn't clear that by "even Linux still supports ARM6," I meant even the Linux OS kernel supports the architecture, not that QEMU for Linux supports it for running guest OSes.

EDIT: The official one from ARM was the one I was thinking of: https://en.wikipedia.org/wiki/ARMulator

Re: The State of Go

#377

Post by 4ad »

Hydraulix989 wrote: post #376
4ad wrote: post #369

Earlier quoted context omitted.

You can't test properly against emulators like QEMU. Emulators are written to be fast, not accurate (although in absolute terms they are pretty slow), e.g. they execute correct code quickly, but they don't fail to run incorrect code the same way real hardware would do. For example, when I wrote the arm64 Go port, I quickly discovered that the emulator would not cause a trap on unaligned memory access! Incorrect code…

Coming from the silicon chip validation world, I mean the actual definition of "emulator," not the abused version of the word that actually means "simulator." Sorry, I thought it would have been more obvious in this context -- it wasn't clear that by "even Linux still supports ARM6," I meant even the Linux OS kernel supports the architecture, not that QEMU for Linux supports it for running guest OSes. EDIT: The offic…

I did use that, but it is orders of magnitude too slow (not to mention unavailable for the Go team at large).

Re: The State of Go

#378

Post by Hydraulix989 »

4ad wrote: post #370
enneff wrote: post #250

Earlier quoted context omitted.

Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.

> Well Apple stopped supporting 10.8, so why should Go continue to support it? I don't know, but Microsoft stopped supporting Windows XP many years ago, and it's still supported by Go. (Not that I care about Go on Darwin 10.8; just making an observation...)

Right, it's a weak argument. Apple tends to pull the plug rather quickly, as well, but that's tangential.

Re: The State of Go

#379

Post by Hydraulix989 »

4ad wrote: post #377
Hydraulix989 wrote: post #376

Earlier quoted context omitted.

Coming from the silicon chip validation world, I mean the actual definition of "emulator," not the abused version of the word that actually means "simulator." Sorry, I thought it would have been more obvious in this context -- it wasn't clear that by "even Linux still supports ARM6," I meant even the Linux OS kernel supports the architecture, not that QEMU for Linux supports it for running guest OSes. EDIT: The offic…

I did use that, but it is orders of magnitude too slow (not to mention unavailable for the Go team at large).

Generally, compiler development is the intended use case of these emulators. I'm pretty unsympathetic when you say that; yeah, it's slow, it's an emulator, and using it is part of your job description.

I wasn't aware the Go team at large all had or needed hardware for all targets? I've done Linux kernel dev without a SPARC, Alpha, etc.

Google and first-class contributors to the ARM6 target (I'm sure a relatively small percentage of the Go community touches each individual, specific compiler target) should have no problem getting free or extremely-discounted licenses from ARM (and even test hardware) -- after all, it's in ARM's best interest to have lots of end users writing code that targets their platforms.

Re: The State of Go

#380

Post by josteink »

josteink wrote: post #374
geoka9 wrote: post #373

Earlier quoted context omitted.

I agree, a common standard would be good. That said, experience taught me to distrust any proposed standard that comes out of Microsoft. Besides, I find that with the programming editor communities, such standards are not that important - as long as a language has the tooling, it'll be integrated, standard or no standard.

This protocol is about reducing the N languages and M editors = N*M client/server implementations with a much better N+M solution, where we don't have to reinvent 200 wheels every time someone makes a new editor or language. And the protocol is open. Seriously what do you have to lose, besides a shit-ton of redundant work? Distrust? Distrust exactly what? Are you sure you aren't being your own worst enemy? See here f…

Too late to edit, so replying to self.

Looking at that list, I see Go is actually doing pretty well these days. I retract my criticism.

That said, as the page shows, having full editor support these days is getting pretty common.

Post reply on HN