https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
But shared libraries aren't the only way or even (often) the best way to share code. Especially when we're talking about UNIX tools, it's pretty easy to have one process run another process. Go has a really quick startup time which makes that practical.
I am looking forward to go someday being suitable for producing native shared libraries. If they ever prioritize and complete that work, that's something I'll absolutely be taking advantage of, and will extend the situations where I'm able to reasonably use go.
I guess I'm happy importing everything into monster huge static binaries and not worrying :)
Mono always supported static linking.
http://www.mono-project.com/docs/tools+libraries/tools/linke...
http://www.mono-project.com/docs/advanced/aot/
Sometimes I wish people would not mix toolchains with languages.
Whereas the go toolchain is very much a part of the language. The go team don't tell you whether tabs or spaces are canonical, they tell you to run go fmt on your code.
Go needs to support shared libraries if it wants to move to the next level of adoption.
So far my view is that I really like the language but I'm finding the tooling pretty unappealing. Wonder if I'm missing a trick?
I use GoConvey to automagically run my tests and tell me what I broke. I keep this running in a terminal window (so I can CTRL-C stop it) and a browser window.
I have another terminal tab on the same window for godoc, and that's serving another browser window.
I have a terminal tab for git commands and file manipulation (this is the one the terminal window is normally on).
I moved away from SublimeText to Atom (with go-plus) because while the load times suck, the go language support in the tooling is way better. Not that GoSublime is bad, it's not, but Atom just works better for me. I tried vim, and loved it, but the support for the go tools was never quite there, and configuring the bloody thing was a nightmare.
So every time I save a file it automagically runs gofmt, goimports, compiles and runs my tests in goconvey (and tells me what I broke), and colours my test coverage right in the editor.
It's not quite the integrated experience that Visual Studio is, but it's incredibly powerful, and conforms to the unix philosophy of lots of good, small programs working together.
And just for comparison; today I spent 20 mins trying to get a dark theme on VS2010 and had to give up (or hand-pick every colour in what looked like around 100 options)... whereas I have dark themes galore on everything else ;)
actually it's because I have a 2010 licence, but none for 2013. Another advantage of Go...
- DLLs are distributed with applications
- Dependencies to GAC libraries are enforced with full version
- we make use of application manifests when needed
> actually it's because I have a 2010 licence, but none for 2013.
Express and Community editions?
We just use MSDN subscriptions.
> Another advantage of Go...
I see some good uses for Go as an improved C, but tooling when compared with JVM and .NET eco-systems is not one of them.
On the other hand, on top of the JDK I have to install, eg, Eclipse, maven, etc. Not to mention all the crazy frameworks I would need to get any real project off the ground.
Similarly with .NET I have to install a whole host of stuff with Nuget, LINQPad, etc.
I rather use RAD tooling for GUI design, not spending hours doing design by code.
I also prefer to have visual representation of DB schemas and generate code from it.
I could go on with lots of other examples, Go tooling will get there some day when the language gets enterprise adoption.
An IDE is an integrated development environment; emphasis on integrated. Having to, by yourself, put together a mixed assortment of tools for your development environment doesn't seem to qualify as being integrated. Though of course someone could come and make a program that bundles a lot of tools together and present them as a coherent, integrated package.
(Personally I'm sceptical of IDEs myself and tend to believe more in being able to make your own work-flow and programming environment, which a lot of loosely coupled (ideally not coupled at all) tools makes simpler.)