kmiroslav

Does any Go editor support that?

> Nothing about the language or its tooling prevents you from building such an IDE or a plugin to one of the existing IDEs. And there is absolutely nothing in Java that makes IntelliJ so awesome. These things are totally orthogonal.

No, they're not.

There are a few necessary conditions for this kind of symbiosis to work well:

- The language has to be statically typed. Without type information, the IDE is completely blind and can barely help you at all without human supervision.

- The IDE has to be written on top of the same runtime as the language it's editing. This is what makes Eclipse/IDEA and Visual Studio so spectacular: they understand the bytecode they are working with.

These are necessary conditions but they're not sufficient. You can still write crappy IDE's if these conditions are met, but thankfully, IDEA/Eclipse/Visual Studio are technical wonders that multiply the productivity of their users.

For example, in Go, the simple action of selecting the the surrounding expression simply doesn't exist anywhere. It's the most basic automatic action that's trivial to do with the proper language and IDE, and yet nonexistent in Go. Along with tens of others.

That's the price to pay when a language is designed without any consideration for its tooling nor basic things we learned about language design these past twenty years.

Everything is perfectly usable without an IDE, you are just more productive with one than without one. Regardless of the language.

In this particular case, the IDE could automatically remove the imports when you remove the corresponding symbol from your source, or automatically add the import when you introduce a new symbol.

The "can be supplied by any external tool" is a cop out that was acceptable in the 20th century but this is 2016, we have a higher bar for developer productivity.

It's a simple reflection of the fact that the Go creators have never used a modern IDE.

Anyone using a modern IDE pretty much never even thinks about imports, which are (and should be) automatically managed by the tool, not by the programmer.

This is like saying that if somebody leaves their door unlocked, it's their fault if they get robbed and the robber shouldn't be held responsible.

It's R&D expense. Nothing new here.

It only takes one of these moon shots to be successful to bring in extraordinary revenues, and Google has always been crystal clear that following such path was in their DNA.

Hard to imagine that R is more popular than Javascript.

But the information is not sent to the server, it's simply pasted in the text field.

There are still a lot of Javascript developers around :-)

Pretty sure that pendulum is never swinging back in the dynamically type side.

The simple truth is that today, statically typed languages have all the advantages that once used to be the exclusivity of dynamically typed languages, while the reverse is still not true.

In 2016, there is really very little reason to pick a dynamically typed language for any serious project.

Javascript is going to be around for a while because of inertia, but it's pretty much the last mainstream dynamically typed language we'll see.

Because if you like a language and that language is popular, you're more likely to find a job using that language, which in turn will make you happier.

> Dart is awesome. Just because currently the community is still small doesn't mean much.

Well, it does mean something. Go is evidence that languages can gain momentum very fast so the fact that Dart still hasn't should be a bit of a concern (and probably partially caused by Typescript's popularity).

Jonathan Schwartz?