It's just a smell, it's not disqualifying, because, as you correctly state, rare are the times when you can't just run the IDE. But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE.
The funny thing is that this feature also explains what Go is. Go relies heavily on the various tooling just to overcome the deficiencies of the language. It's just that they didn't choose IDE as a primary target, but instead various ad hoc tools.
For example, when I find the unused imports being a hard error inconvenient, a typical suggestion from Gophers is "just use an editor plugin that automatically handles that". This is exactly the same attitude that can be found in the IDE lovers.
And that's why I don't like Go anymore. In the name of the simplicity of the language, they concentrate on building more and more tools, rather than fixing the language. I'm pretty sure if Go acquires generics someday, it will have the form of code generation, which is proven to be awkward. (I heard "go generate" already does a part of that?)
Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the most basic of which involves printing.
Having to add, remove, then re-add "fmt" or "log" just to keep the compiler happy is not a Unix-philosophical issue around language design, it's just an unnecessary strictness.
Go is "opinionated", but it tends to err on the side of impracticality, a kind of distorted, prematurely-optimized YAGNI that disrupts developer efficiency in the name of simplicity. "go get"'s obstinate simplicity is firmly in this category.
Go gets a lot of stuff right, of course. And the tools — the "go" tool, compiler toolchain, gofmt, debugger, godoc etc. — are clearly good Unix citizens, of course.
I think this statement makes both points simultaneously.
This sentence has baked into it a context which is not universal. Namely that "during developing" you are "work[ing] with a lot of tentative code". That's simply not how I, nor many others, develop. Even on the very first sketch of a program, I'm writing complete, valid types and functions. I code all of the error paths completely as I encounter them. For very large first drafts, I'll often stub methods or types, but I never leave the program in an invalid state and "try it out". (Tangentially, for what I suspect are similar reasons, I never quite understood why anyone would care so much about REPLs.)
All of the tentativity, so to speak, has been expressed and explored in my head and on paper beforehand. Go is a language that rewards, perhaps even demands, this style of development. If that's not how you operate, Go will feel like it's fighting you. But that's not a universal critique of the language, that's a very specific critique of your specific operating context.
Sometimes I write code like you do. At other times I'm "feeling out" a solution and want the language to not fight my half-baked, messy (but syntactically valid!) program. At other times I'm writing a quick and dirty script I will use today and never after; it doesn't need to be pretty, only functional. But Go wants your code to always be fully realized and clean, which just doesn't mesh with reality.
We don't need "universal critiques". Everyone has a style, and a good, mainstream programming language needs to be receptive to those styles.
It certainly meshes with my reality.
Otherwise, you get terrible products that are nothing more than the lesser sum of their features, like JIRA, or Scala.
If a piece of software can give my team a 1% speedup, it'd be worth $40k a year. Multiply that by lots of teams, we can see there is a big market on making engineers more productive.
Meh. People say the same thing right before starting a Node project with Sublime. Then they proceed to write an unmaintainable mess of JavaScript. With only the original author knowing who calls what, what gets returned, interface definitions, etc.
I have yet to find a language that doesn't benefit from a capable, intelligent IDE.
Also note that a carpenter building a house probably wouldn't choose the most powerful tools (tower crane, etc) even if financials were taken out of the equation.
It doesn't make much sense to compare go's standard toolchain to building a house without power tools. What an IDE gets you over a more unix-like toolchain is integration, nothing more. They have all the same capabilities, but an IDE is designed to make a specific prescribed workflow seamless. There simply is no good analogy for this, carpenters don't have a universal tool that acts as a nailgun, drill, power screwdriver, wrench and saw at the same time.
EDIT: Other stuff that's often gotten wrong are short variable/function names and spacing.
> But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE.
I would have to disagree with this point as well. To me, it feels like suggesting that computing is better with punch cards. Because, it is then also a fair point that a way of computing that can be done without a computer and editor is -- all other things being equal -- better than the way of computing that requires a computer and editor.
I think that thinking this way will also help numb the next leap in methods of instructing computers, and performing computation. Whether that involves a programming language or not.
Maybe its just the code I've read, but its generally much longer than other languages to accomplish the same thing. A bunch of little things add up, such as "extends" instead of ":" for inheritance. Naming things is often longer - maybe its not the language core itself, but a counter example is python coding standards keeps them much shorter. With Go, there's duck typing to not have to declare obvious types (such as for strings).
The goals of the programs in enterprise java apps probably differ by an emphasis on readability and not writing speed. I.e. lambdas are written quicker to write, but maybe a reader would understand a strategy pattern's goal quicker.
Not a Go developer, but I think you mean type inference, not duck typing.
Imagine you're refactoring a code written by employee #12340 that was written 10 years ago. With Go, you'd go file after file decomposing the program to finally figure out that if he just used a word to implement an interface, you only had to read that file and a javadoc. Long class names are still easier to look than signatures of functions.
Java emphasises abstraction. Go emphasises composition. Both have its uses, but what I was refuting was people claiming that Go is better than Java which I think is extremely uninformed conclusion.
This is not my experience with Java programs.
Enterprise Java programs often have many layers of magic abstraction, like Aspect-Oriented Programming, dependency injection, IOC.
Furthermore, people love using configuration files over code to determine program behaviour (see servlet configs, etc).
You call it a smell I call it functionality. Get back to me when Go is at version 9 with decades of features added and then you can talk about verbosity.
And this idea that you need an IDE to code Java is pure and utter rubbish.