I went through Aliaksei's article and found all his negative points about Go and addressed them in my previous response.
Keep in mind when I respond, that this is not my field. I spent my career writing advance 3D modeling desktop applications for geologists, geophysicists. I am just a tourist in Java server land, making some observations as an outsider.
Not everything you mention here will be stuff I am intimate with. You mention IoC, is this related to dependency injection? If so, what specifically about the Go language puts it at a disadvantage? Anything about the Go language which makes these disadvantages hard to fix?
I think you might have some misunderstandings of how Go works.
- Go supports exceptions, but they are used to exit failing Go routines, not for general error handling. That is a good choice IMHO. I think Java makes a mistake of using exceptions even for errors which are not exceptional.
- Go does not do error handling through error codes. It uses error objects. These can be nested.
- Go allows you to annote fields, but the system is quite different form what Java uses.
Whether Java has flexible OOP and functional programming features and whether those are better than that of Go are debatable. Personally I would argue Go is better in this area, not worse.
I have been recently working with IO stuff in Go and compared with the Java solution. I find the Go approach far more elegant and flexible. The OO heavy design choices taken in Java seems to have made the solution more inflexible and complicated.
In Go e.g. you can define interface after the fact. Hence I can have to existing classes A and B from different vendors. I can identify similarities and create an interface describing those similarities. There is not need to modify source code to make A and B adhere to my new interface.
Small vs Large Apps:
As for the size of applications suitable for Go, I think you got that backwards. Go was designed for large scale application development. As a language it makes no sense for making small applications. You don't need high speed compilation and minimal feature set if you are making small apps.
For small apps I would also question the value of static typing. You are far more productive with a dynamic language. Static typing primarily pays dividends as programs grow larger.
Also simplicity is of less value for a small app. One developer can keep track of everything in a small app. When you grow very large applications and hire lots of junior developers to work on it, then you need something you can train people on quickly. You need clearly written code with minimal magic.
About JNI:
Yes you can call native code through JNI, but that was not what I asked. I asked for Java native code.
What is your view on Spring Native? I am trying to understand what the Java story is. If Spring Native is so awesome, then why use the JVM at all?
Sure there are trade-offs. When would you use Spring Native and when would you deploy to the JVM? What factors decides your choice?
