
Go team adding a Go language server to core - sqs
https://go-review.googlesource.com/c/tools/+/136676#message-11c783bc9a9f6adf6119bbb85c89510fda25abe9
======
dev_dull
> _Tooling is so important to the developer experience for any language, and a
> language server is one of the most important kinds of tooling there is
> (because the user interacts with it on virtually every keystroke in their
> editor)._

Here’s how languages backed by large corporations win. They have the resources
and the optics to know why these non-fun features are important.

~~~
stcredzero
Since when is tooling non-fun? This depends on a lot of factors.

~~~
asdkhadsj
Exactly. Hell, I consider tooling to be some of the most fun _(and often
difficult)_ things I work on in my free time.

If I can make something easier for my normal dev environment I see huge gains
~40 hours a week. That's pretty damn awesome and flashy to me. It's definitely
not easy, but imo it's well worth my time.

------
flaque
Possibly dumb question: what is a language server in this context and what’s
it used for outside of the AST package?

~~~
blcArmadillo
Look at [https://microsoft.github.io/language-server-
protocol/](https://microsoft.github.io/language-server-protocol/) for more
info. It's a standard interface IDEs can use for things such as autocomplete
rather than every IDE having to reinvent the wheel.

~~~
justaj
Interesting, I wonder if Vim is able to use this protocol as well.

~~~
int_19h
[https://github.com/prabirshrestha/vim-
lsp](https://github.com/prabirshrestha/vim-lsp)

[https://github.com/autozimu/LanguageClient-
neovim](https://github.com/autozimu/LanguageClient-neovim)

------
shabbyrobe
I'm not sure I fully understand the provenance of the code here, but I could
just be being a bit thick. The files in the change request show the copyright
as "2018 The Go Authors", but some of the commentary hints that this is code
donated from the Sourcegraph implementation. If this is the case, does that
mean Sourcegraph has transferred the copyright to the Go authors?

------
pokstad
I’m going to guess this is in response to many community supported dev tools
breaking in v1.11 when modules are turned on. Specifically tools like gocode,
godef, and gogetdoc.

------
asdkhadsj
Does anyone know if this is introducing more features than the existing Go
LSP[1]? I'm all in favor of tooling support - I'm just curious if this
actually adds anything to those of us already using a Go LSP. Thoughts?

[1]: [https://github.com/sourcegraph/go-
langserver](https://github.com/sourcegraph/go-langserver)

~~~
sqs
Sourcegraph CEO here (and author of a comment in the link + contributor to
[https://github.com/sourcegraph/go-
langserver](https://github.com/sourcegraph/go-langserver)). The idea is that
with a Go language server becoming a core part of Go, it will have a lot more
resources invested into it and it will surpass where
[https://github.com/sourcegraph/go-
langserver](https://github.com/sourcegraph/go-langserver) is now.

------
vbezhenar
It's interesting that Jetbrains refuses to leverage those language servers and
writes their own parsers for every supported language.

~~~
gameswithgo
very few languages implement the RLS well. For instance Rust does it, but its
incomplete and very slow. I bought a quieter CPU fan specifically because of
it!

~~~
int_19h
It's more a function of language complexity than anything else. LSP for
something like C, Java or TypeScript is not that hard, because the language is
fairly straightforward to parse, and not ambiguous. But something like C++ or
Rust, where you have to deal with templates/generics/traits/... and type
inference starts getting gnarly. And something like JS or Python is hard
because there are no static types at all, and you have to do inference.

But LSP itself doesn't really make it easier or harder. If you look at other
code completion implementations (in IDEs that don't use LSP), they're usually
at a comparable level, if they exist.

------
adiusmus
Every language has support ... except the ones that don’t.

[https://langserver.org/](https://langserver.org/)

------
wasd
I wish every language would do this.

------
lobo42
Cool! We wrapped the VS Code extension in the protocol to support it in
gitpod.io. See here [https://github.com/theia-ide/go-language-
server](https://github.com/theia-ide/go-language-server)

Would be really awesome to use something maintained by the people who know Go
best :)

------
wenc
Curious about language servers (especially those implementing LSP): how do
they achieve low-latency responses?

My understanding is that JSON-RPC is used, which is relatively high overhead.
Are there lighter weight alternatives? (gRPC?)

~~~
tragic
Because they're typically running locally they're quick, or at least as quick
as your hardware will allow. The json-related latency is typically dwarfed by
the latency from actually doing the functionality (parsing the code for code
completion, etc).

So the real work is in having a good story for incremental compilation and a
generally quick and robust compile toolchain. I guess that Go is in a good
position here ...

------
mark_l_watson
Good idea. Languages like Haskell benefit by having a language server that
Emacs, VisualCode, etc. can all use. It just make good sense to do the work
once and let all editors and IDEs use it.

------
fithisux
This is great news. Hopefully we will see others follow.

------
logicallee
2 unrelated questions. (tl;dr at bottom)

    
    
       Background
       ----------
    

The two major advantages of Go are its clear, unambiguous and explicit syntax
(unfortunately ugly) and very small (minimal) feature set, so that it is
possible to reason about anything without any high context.

The former means it is possible to pick up Go in a day or two and the latter
means that there are no real tricks after a few months. That's it.

All this has been done in an excellent way. There is no class system.
Everything is simple. Explicit typing works.

These design trade-offs have led to a language that is VERY easy to go back to
after working in any other language. Almost all simple syntax mistakes by the
programmer are caught before something successfully compiles. Once a
programmer is used to it, which happens quickly, Go is the only language
people write pages of code in that compiles on the first pass and does
everything they hoped. "Less is exponentially more."

    
    
       History
       -------
    

Due to the history of Go it was _meant_ to be a systems language. It didn't
really succeed at replacing C anywhere, except the web server: I consider Go
like a web-safe C. (In no small part due to Google's work meeting its own
needs.)

    
    
       Question 1
       ----------
    

What I don't understand is that since speed and being a systems language were
_explicit_ design goals, why the Go syntax is not suitable for tiny, embedded
microcontrollers.

If the answer is something about garbage collection, this doesn't really make
sense for me, as good algorithms should scale from 0 upward. I don't see why
there should be a huge jump from "not running Go yet" to "now you're running a
Go runtime" that suddenly requires a large amount of free memory. Here is a
post about this:

[https://medium.com/samsara-engineering/running-go-on-low-
mem...](https://medium.com/samsara-engineering/running-go-on-low-memory-
devices-536e1ca2fe8f)

It seems this is high.

I don't understand why Go doesn't take its core, primary strengths outlined in
the "background" section above and expand it into the lowest of the low-end
devices.

Why can't I compile a Go program targeting a microcontroller with 2-8 MB of
RAM without issue? Go was designed as a compiled systems language, to replace
C. Not as a scripting language to replace Python.

    
    
       Question 2
       ----------
    

Since explicit (if very ugly) syntax that keeps people from making mistakes,
and whose specifications can be kept in mind all at once, is a strength of the
language and syntax, why can't I develop desktop GUI's in Go? It is a fast,
compiled language.

You might say the answer to that is that a windowing system _needs_ a class
system but I disagree - that can't possibly be any more true than the idea
that a web app needs a class system. Clearly people make web apps in Go
without a class hierarchy.

Nobody makes desktop apps (I mean the class of applications that web browsers,
IDE's, photo editing software, basically everything on a list like this -
[https://helpdeskgeek.com/free-tools-review/best-freeware-
pro...](https://helpdeskgeek.com/free-tools-review/best-freeware-programs-for-
windows/) ) in Go.

Of course, when it debuted you could say, "That's just not what the team
focused on", since it was backed by Google they needed it on the server. But
at some point you'd expect first someone to make a make-do GUI toolkit, then
other people to add on and make something better, and by now it should be an
obvious language for making a Winzip or Winrar competitor. Or an antivirus. Or
an Audacity or VLC-type program. Or an OpenOffice clone.

But nobody does these things. _Any_ of these things.

Why not? The simple language has nothing missing that languages which are used
for these applications have.

I don't buy the idea of the ecosystem entirely lacking these.

Why don't people make GUI stuff in Go? I don't understand why it shouldn't be
an obvious language choice. I just wouldn't reach for Go when it comes to
scripting a GUI application. Why not?

    
    
       Summary / tl;dr
       ---------------
    

1\. I would like to know what it would take to make the simple specifications
behind Go, which are protected by knights in shining armor, an obvious choice
for embedded microcontroller applications in 2018.

2\. I would like to know what it would take to make the simple specifications
behind Go, which are protected by knights in shining armor, an obvious choice
for desktop applications in 2018.

~~~
logicallee
Not going to edit the above but people clearly hate it (many downvotes without
minutes of posting).

At the moment I think most Go programmers who also program tiny
microcontrollers with a few hundred KB or up to a couple of MB of RAM, do so
in languages like C or Rust, not in Go. Why not? It's a fair question.

For those of you reading this on a laptop or desktop, how many desktop
applications are you all running at the moment or have as an installed
application? How many are written in Go? Why so few or none?

I mean desktop applications like Audacity for audio, or VLC, or Open Office,
or your web browser, and so forth.

The downvotes came pretty fast so you clearly have some ideas. I'd like to
hear them.

~~~
striking
>people clearly hate it

Maybe because it's overlong, almost completely unrelated to the article, and
might just be flamebait?

But I'll toss in a few cents anyway.

>Why can't I compile a Go program targeting a microcontroller with 2-8 MB of
RAM without issue?

Microcontroller toolchains are pretty controller-specific. It takes work to
make things compile for them. There are other languages that fare better.
Additionally, one of the more useful features of Go (concurrent goroutines)
would simply be unavailable (and even with concurrency disabled, you still get
unpredictable latencies from deciding which task should run when, the GC,
etc).

Just use C.

>why can't I develop desktop GUI's in Go

You can. [https://github.com/andlabs/ui](https://github.com/andlabs/ui) is an
example of how you can (and I'm sure it's not the only one.)

>Why don't people make GUI stuff in Go?

It's common to write apps using whatever the OS provides or using well-known
libraries, so that's something Go's offerings don't offer. It's so much work
already to build a GUI app that most people doing so probably don't want to
concurrently write a GUI library too. I don't think there's anything stopping
you, though.

Next time, avoid writing so much to ask two (three?) simple questions. You
come off as having an attitude when you use phrases like "Not going to edit
the above", "knights in shining armor", and so on. You also build up and tear
down many bales worth of strawmen, which is pointless. It would have been a
better use of your time to actually look into either of those fields and
discover the answers for yourself.

~~~
logicallee
Thanks for your responses, which I read carefully. I hope we can get a bit
more out of this conversation.

"Just use C" is odd to me given that Go was originally developed to be an
alternative to C (a "systems language") - this was an explicit design goal,
and mentioned in the first main sentence of its specification[1]: "Go is a
general-purpose language designed with systems programming in mind."

So when you then glance at the adoption for those uses, you would come to the
(wrong) conclusion that it must have failed to meet its original design goal
of being better for those general use cases. (Or people would be using it).
According to its designers, C and C++ programmers don't transition to Go (as
its designers had thought they would), but Python programmers do.

So I'd like to understand what it lacks that is holding that back. I see it as
clearly superior. Looking at the design, it looks like it met its design goal.
So I see it as successful in its bid to be design that is a viable replacement
for C as a "systems language", and then despite this successful design now
nobody uses it as a systems language.

It would be as though someone set out to make a better bicycle wheel,
succeeded, and then nobody uses it as a bicycle wheel (despite its being a
better bicycle wheel), while meanwhile the design is being used to haul
thousands of tons of freight per year (server microservices). I'm asking, "so
why don't we use it as bicycle wheels" and am told "just use a wheel". But I
want to understand why, because it seems to me it met its design goal of being
a better bicycle wheel.

For the second statement, your statement about "common to write apps using
whatever the OS provides or using well-known libraries," makes sense and
explains why these libraries didn't exist when Go was made. I don't understand
why they are still not a big part of the ecosystem nearly a decade later.

The "knights in shining armor" is a serious statement: the biggest benefit of
the Go language is its gatekeepers keeping things out of it, and its extremely
orthogonal, tiny syntax, which can be kept in mind along with state. The
results of code can be reasoned about without a lot of gotchas. I am therefore
wondering what, if anything, these gatekeepers are keeping out which prevents
the two parts of the ecosystem which I mentioned, from flourishing.

I don't think Go programmers who are also C and C++ programmers who are used
to writing for embedded microcontrollers or for Windows in C and C++
respectively, require deep (or any) changes to the language before _as a
language_ it would be suitable to those two cases. You haven't mentioned any.

So I still welcome more viewpoints. I don't see why Go can't replace C and C++
applications across all of the use cases I mentioned, with minimal first-party
support by the language developers and maintainers. Doesn't Go also have
alternative Go compilers based on the specification?

I did a Google search for alternative Go compilers and the top result is from
2014: [https://groups.google.com/forum/#!topic/golang-
nuts/EwDS15Ew...](https://groups.google.com/forum/#!topic/golang-
nuts/EwDS15Ewfs0)

As a followup, why is this the case? I mean, the Specification is quite clear,
and it's a tiny language, so in the past 9 years I don't see why there aren't
at least a few dozen independent implementations. Is it just not enough time,
and we should wait a few decades? Is the issue that Google doesn't need Go for
its desktop or mobile development stuff, and doens't need it for
microcontrollers, and Go is not really an "independent" entity that is quite
independent of Google as a company?

Basically I am wondering why Go in 2018 isn't where C and C++ were by 1998,
for example. Despite your detailed answers I don't see the missing pieces.

Go as a syntax is better than C or C++ as a syntax. Its syntax and small and
stable language features set are Go's primary advantages, which allows it run
on the metal using clearly written standard Go libraries to serve web apps. To
me, a microcontroller program running with next to no memory just has to not
leak memory or crash, unlike Go running microservices, which have to withstand
highly targeted and sophisticated attacks.

Basically, given how I see Go (which is the reason for my very lengthy
introduction, so that people could correct me if I'm wrong) I don't see why
the language is not very far along where C and C++ blossomed as languages for
embedded microcontrollers, and for Desktop applications.

In a way you could say I don't really get what's preventing this. I can't
think of any showstoppers.

[1] Go language specification:
[https://golang.org/ref/spec](https://golang.org/ref/spec)

~~~
striking
I tried to find a succinct question to respond to for your first section, and
couldn't. My answer is the same as before: no one has bothered to write a Go
runtime that can run on microcontrollers. This is because Go does not do
anything fundamentally different from C at that level, except things that are
less suitable for low-memory and low-CPU environments; and because it takes a
lot of work to write a compiler and runtime for these devices. Note that there
are very few compilers for each individual microcontroller. They generally
only have one or two.

>I see it as clearly superior.

You are not looking hard enough. Go has flaws, as does any language or tool.
It is almost a rule of thumb that not understanding the flaws of a tool is a
sign of inexperience with it or alternatives to it. I think if you actually
tried to learn and use C and C++, you might better understand the difference.

>I don't see why Go can't replace C and C++ applications

My answer is the same as before: it can, except that C/C++ apps already have
that territory, and Go doesn't provide a fundamentally different experience
except in lacking libraries for most GUI applications. There are still places
it shines, though. For example, it is doing a fine job of replacing C/C++ for
cloud orchestration tools; static linking is important to those users, and Go
provides it easily.

>Basically I am wondering why Go in 2018 isn't where C and C++ were by 1998,
for example.

This is a mathematical error. The C programming language was developed in
1972, and C++ piggy-backed off of C's ecosystem very effectively.

>Go as a syntax is better than C or C++ as a syntax

I don't think I can come up with a better example of a "skin-deep" comparison,
nor do I think anyone has actually argued for C/C++'s syntax being actually
good.

>stable language features

Didn't Go 1.11 break all of the community's tools? Isn't that why the story
we're posting on the comments on exists?

>To me, a microcontroller program running with next to no memory just has to
not leak memory or crash,

Some microcontroller programs need to have very low latencies, or the physical
things they are connected to will break (the GC defeats this). Some
microcontroller programs are only allowed a couple of KB of RAM (Go can't
handle that). Most microcontroller programs are compiled without a standard
library (and Go would have to provide its own impls of basic Go stuff in order
to function). Some microcontroller programs never allocate memory, cannot
allocate memory, or must allocate all memory up front. And so on. You can
solve these things by having more expensive and fault-tolerant gear, or buying
more RAM, or paying people to write more Go compilers/runtimes, etc., but
these things get expensive fast; that is often incompatible with the design
goals of what microcontrollers are used for. You're welcome to write Go and
slap it on a Raspberry Pi, though.

>In a way you could say I don't really get what's preventing this.

Try writing a microcontroller program and GUI app, both in C or C++ and in Go.
I very strongly doubt you will succeed faster in Go than in C/C++, in either
kind of project, because of multiple factors: ecosystem, communities, example
code, language features, existing toolchains and compilers... But if you don't
believe me, try it out for yourself.

~~~
logicallee
I read this several times hours apart. Lots of information, thanks. I don't
have many questions except this:

"Some microcontroller programs are only allowed a couple of KB of RAM (Go
can't handle that)."

What in here...

[https://golang.org/ref/spec](https://golang.org/ref/spec)

...can't you possibly implement in only a couple of KB of RAM? (For what
required feature or features can we say for sure that a couple of KB of RAM is
insufficient to implement as specified?)

~~~
striking
As it turns out, the only mention of the feature is in that link's
introduction. The garbage collector
([https://github.com/golang/go/blob/master/src/runtime/mgc.go](https://github.com/golang/go/blob/master/src/runtime/mgc.go))
makes many references to 4KB pages and 1MB arenas. This (the code and the user
of the technique) would need some serious reconsideration for small devices.

~~~
logicallee
Isn't the specification the actual language, and Google's compiler just one
implementation? (That's true for C/C++.)

Is the specification underspecified or something? We're not talking about a
syntactically huge language...

