6 ms·

There are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's sti

by tene 12y ago

There are absolutely some scenarios that can be adequately (or better) handled by communicating with another process! I completely agree with you. There's still a large volume of use cases where linking code in-process is a very good fit for the problem. 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.

marcus_holmes 12y ago
I moved from C# to Go, and one of the things I really loved is the sudden absence of DLL-Hell. I never have to worry that installing my program on another machine would suddenly cause it to bork. I guess I'm happy importing everything into monster huge static binaries and not worrying :)
- johnny_reilly 12y ago
  Marcus, I'm also giving Go a try at the moment (C# is my day job). What are you using tooling-wise? I'm trying out Lite IDE at the moment and that's the best experience I've had yet. 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?
  - okatsu 12y ago
    I find that Sublime Text with the GoSublime plugin works pretty well. There's "Intellisense" for imported packages and GsLint actively detects syntax errors. Gofmt also takes care of indentation and formatting for you at every save.
    - bkeroack 12y ago
      ++ to Sublime Text and GoSublime. It's what I use and anecdotally appears to be the most popular Go dev environment.
      - johnny_reilly 12y ago
        Thanks both of you - I haven't had a go with GoSublime yet. Now I will!
        marcus_holmes 12y ago
        My experience: you kinda have to rethink what an IDE is. Go comes from the *nix tradition where the "coding environment" is a text editor and a few terminal windows. 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 ;)
        pjmlp 12y ago
        VS2010 ?!? We are already on 2013 with 2015 around the corner.
        vetinari 12y ago
        Tell that to Oracle, who hasn't bothered with OCI libs for VS2013 yet ;)
- pjmlp 12y ago
  Coming to C# in the form of .NET Native and vCore on Windows. Mono always supported static linking. http://www.mono-project.com/docs/tools+libraries/tools/linker/ http://www.mono-project.com/docs/tools+libraries/tools/linke... http://www.mono-project.com/docs/advanced/aot/ http://www.mono-project.com/docs/advanced/aot/ Sometimes I wish people would not mix toolchains with languages.
  - marcus_holmes 12y ago
    yeah, I get that. But my actual lived experience of working with C# is Visual Studio, Windows, and DLL-Hell. 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.
    - pjmlp 12y ago
      While I like Go as a better C, I wouldn't use it instead of C#.
- zak_mc_kracken 12y ago
  DLL hell was solved in .net a decade ago. If you need specific versions, ship with your own version in the local directory. Otherwise, .net assemblies solve the problem elegantly. Go needs to support shared libraries if it wants to move to the next level of adoption.

by tene 12y ago

marcus_holmes 12y ago

I moved from C# to Go, and one of the things I really loved is the sudden absence of DLL-Hell. I never have to worry that installing my program on another machine would suddenly cause it to bork. I guess I'm happy importing everything into monster huge static binaries and not worrying :)

johnny_reilly 12y ago
Marcus, I'm also giving Go a try at the moment (C# is my day job). What are you using tooling-wise? I'm trying out Lite IDE at the moment and that's the best experience I've had yet. 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?
- okatsu 12y ago
  I find that Sublime Text with the GoSublime plugin works pretty well. There's "Intellisense" for imported packages and GsLint actively detects syntax errors. Gofmt also takes care of indentation and formatting for you at every save.
  - bkeroack 12y ago
    ++ to Sublime Text and GoSublime. It's what I use and anecdotally appears to be the most popular Go dev environment.
    - johnny_reilly 12y ago
      Thanks both of you - I haven't had a go with GoSublime yet. Now I will!
      - marcus_holmes 12y ago
        My experience: you kinda have to rethink what an IDE is. Go comes from the *nix tradition where the "coding environment" is a text editor and a few terminal windows. 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 ;)
        pjmlp 12y ago
        VS2010 ?!? We are already on 2013 with 2015 around the corner.
        vetinari 12y ago
        Tell that to Oracle, who hasn't bothered with OCI libs for VS2013 yet ;)
pjmlp 12y ago
Coming to C# in the form of .NET Native and vCore on Windows. Mono always supported static linking. http://www.mono-project.com/docs/tools+libraries/tools/linker/ http://www.mono-project.com/docs/tools+libraries/tools/linke... http://www.mono-project.com/docs/advanced/aot/ http://www.mono-project.com/docs/advanced/aot/ Sometimes I wish people would not mix toolchains with languages.
- marcus_holmes 12y ago
  yeah, I get that. But my actual lived experience of working with C# is Visual Studio, Windows, and DLL-Hell. 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.
  - pjmlp 12y ago
    While I like Go as a better C, I wouldn't use it instead of C#.
zak_mc_kracken 12y ago
DLL hell was solved in .net a decade ago. If you need specific versions, ship with your own version in the local directory. Otherwise, .net assemblies solve the problem elegantly. Go needs to support shared libraries if it wants to move to the next level of adoption.