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 statement is probably true but that's kind of irrelevant. IMO it is actually a virtue of the language if it is perfectly usable without a modern IDE. Contrast that with Java and you'll see what I mean. Go follows the Unix philosophy where things like imports or formatting can be supplied by any external tool. If you wish to bundle all these small tools into a single IDE you can do it, too.

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.

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. What I like about Go's tooling is that it allows good plugins for various text editors (eg. Sublime or Atom) to be implemented with relatively little effort.

> 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.

> The language has to be statically typed

Go is statically typed.

> the simple action of selecting the the surrounding expression simply doesn't exist anywhere

How so? It's trivial with the `go/ast` package.

Does any Go editor support that?

Is it relevant to the question at hand? Languages != their IDEs.

Assuming emacs doesn't qualify as a "modern" IDE. I have a hook that calls go imports to remove and add imports.

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.

If what you hide there is a dead body and the robbers tell the cops anonymously, you're guilty of murder :) and then, I don't care if you got robbed.

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.

I don't see it that way exactly. R&D is an investment. Hell, I'd consider calling it a pure capital investment, if not simply enhancing goodwill. If even one of those moonshots become successful those "sunk costs" will likely start streaming back.

Hard to imagine that R is more popular than Javascript.

A bug that tricks the secure password management tool into revealing your Twitter password to a website that is not Twitter! That's a pretty major security vulnerability due to a bug in URL parsing.

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

Yes, but some JavaScript can detect that the text field has been filled, and then send the information back to the attacker's server. An (innocent) example of this is when you type something into Google's search field, and you already see suggestions, even though you haven't clicked anywhere or hit Enter yet.

An attacker could fool the extension to autofill a form on a domain they control with credentials from another domain and send the credentials to their server.

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.

>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.

Python's still pretty popular too

> it's pretty much the last mainstream dynamically typed language we'll see

I partially agree. I think as type inferencing gets smarter, we're going to end up with languages that are statically typed by the compiler or interpreter, but that there will be few-to-no type annotations in the code. So yes, I think the future is static typing, but I think it's going to end up a compiler feature and not part of the language at all.

Curious to hear why this is being downvoted.

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

Subtyping combined with paramtericity is still a problem with good (I.e. doesn't suck) type inference. Unless you are will to live without either, it isn't true that static thong has all the advantages of dynamic, yet.

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

I wish this were true. I wholeheartedly agree that, all other things being equal, static typing is better than dynamic typing. If there were no other factors, I would choose static typing without a second thought. But there are other factors, and all other things are not equal.

I write ClojureScript every day. Its lack of static typing is a genuine source of pain. Every day. But when I compare it to Elm, which I'm quite interested in:

- JS interop. Maybe I suck at google, but it looks like it's not a first-class concern of the language or the community.

- Macros. Defining language features is great. It's the reason that a lisp can be small in terms of core language constructs (even if its standard library is enormous cough Clojure). In 2016, there is really very little reason to design a language without metaprogramming in mind.

- Community, which admittedly could and should and will grow in size and sophistication for Elm.

When I compare it to TypeScript?

- State. Welp.

- No seriously, why is everything mutable? It's 2016 and a language that was designed with concurrency and functional programming in mind from the start still hasn't caught on to mutability by default as a serious problem, and TypeScript inherits all this baggage.

- There's no simple clear path to even set up a TypeScript project. There's a million different ways with different tooling choices, and that fractured environment is evident whenever searching for answers. The world of JavaScript constantly bleeds through. If I want to know how to use TS, I need to know WebPack and NPM and Bower and who knows how many other things that are not even for TS.

- Forget metaprogramming.

- What is the TS community? Microsoft and a weird has-been cult team at Google? (Sorry guys, I did the Angular thing, and I watched it become a circus from the time Angular 2 was announced to the time your weird conference was more like a dance club than a tech conference.)

I could simplify this by calling out your last line. JavaScript rules the roost. You better play nicely with it, if you want to build a web app.

Honestly the web is going to be an increasingly fractured thing for many years. There's just too many ways to do things and they're all compromised in awful ways.

Postscript: I'm sorry this is so ranty. I mean no harm and I mean none of my criticisms to be taken as attacks. I want very much to do good work as a web dev and I'm just heartbroken that it's such a pain.

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.

Maybe if the job is in a field you like. Used to be learning COBOL guaranteed a job. As a drone in a bank. Very popular at the time.

> 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).

Dart does have some momentum as well and it's younger than Go. Go's 1.0 release was at 28 of March 2012, whereas Dart's was November 14, 2013.

- https://blog.golang.org/go-version-1-is-released - http://news.dartlang.org/2013/11/dart-10-stable-sdk-for-stru...

Jonathan Schwartz?

Worst hair for sure.

Groovy and Kotlin use the implicit "it" parameter for lambdas that take just one parameter, which is very convenient:

    listOf(1, 2, 3, 4).filter { it % 2 == 0 }

Scala allows underscores, and sequential underscores refer to the next element, so you can do e.g.

    list(1, 2, 3, 4).reduce(_ + _) == 10

Doesn't that make the parameter anonymous, though? Can you println that _ and see the value of the current element?

Use a function that prints then returns its parameter:

  list(1, 2, 3, 4).reduce{print(_) + _} == 10

Use it if you or your language hasn't defined such a function:

  list(1, 2, 3, 4).reduce{it:= _; println(it); it + _} == 10

In fact, any name for it will do.

Yeah, that's the tradeoff–gain the ability to work with multiple parameters but lose the ability to reuse a single one.

And Haskell uses operator sections: (==0) would be similar to { it == 0 }. Alas, the section syntax get a bit cumbersome when you want to compose two or more of them, like in this translation of your example:

    filter ((0==) . (%2)) [1, 2, 3, 4]

so does LiveScript