[deleted]
I’m joining the Go team at Google
41–50 of 211 posts
Re: I’m joining the Go team at Google
#42> What is missing from the Go ecosystem? Personally, golang "IDE" experience is not as good as Java or even C++. For example, ycmd only supports subset of functions for golang. I miss ycmd-goto-references the most.
JetBrains WebStorm with the free Go plug-in provides an excellent Go IDE experience. There are some free community editions of JetBrains IDEs that are supposed to work with the Go plug-in (e.g. PyCharm, if I’m not wrong), so you do not even have to pay anything. https://www.jetbrains.com/products.html?fromMenu#type=ide
It is not excellent.
All other editors I used autoformat Go code after save.
There are two types of format provided by IDEA - IDE Format & go fmt. Both not ideal. IDE Format does not format code according go guidelines. It can delete unused imports if you go through options.
go fmt does not delete unused imports, and as result code is not compileble.
Refactorings are missing in IDEA. It is not excellent, it is something you can work with.
Re: I’m joining the Go team at Google
#43I'm using C# mainly because of debugger integration in Visual Studio. Make decent visual debugger and devs will come.
In general make good tooling and others will come. Look at Java/Eclipse
Re: I’m joining the Go team at Google
#44I'm using C# mainly because of debugger integration in Visual Studio. Make decent visual debugger and devs will come.
What are you developing with C#? I see Go more for server-side stuff, and C# for Unity/Desktop development...
Interesting. I've used C# heavily at my last couple of jobs and it has all been server side web work - mostly back ends of web apps, but also services and microservices of various kinds.
From talks with coworkers, the impression I've gotten is that most C# in the wild is running server side, though there's obviously a lot of it in desktop apps, and on mobile with Xamarin.
Re: I’m joining the Go team at Google
#45I'm using C# mainly because of debugger integration in Visual Studio. Make decent visual debugger and devs will come.
Make decent unit test coverage and you'll hardly ever see a debugger again. Neither will you need a fancy code editor.
Re: I’m joining the Go team at Google
#46I'm sorry to hear that. Go is not revolutionary (unless you count "completely ignoring runtime errors" to be revolutionary). If anything, functional languages are the new, old, revolutionary thing.
Re: I’m joining the Go team at Google
#47Earlier quoted context omitted.
It is pretty readable, but really non-functional too. Eg, they still don't have math.round and you wind up writing a lot of code because it can be a little bare bones or does things in a way that isn't quit usable. I wouldn't say it is very expressive either. Go can be very wordy and verbose at times, and some things are downright a pain or poorly thought out (e.g, while Java has finally and C++/Rust have RIAA for de…
> It is pretty readable, but really non-functional too There are projects starting to fix that: https://github.com/asteris-llc/gofpher
[deleted]
Re: I’m joining the Go team at Google
#48The one request I make is, please do not give in to complexity in order to accommodate to all users' requests.
Re: I’m joining the Go team at Google
#49I'm using C# mainly because of debugger integration in Visual Studio. Make decent visual debugger and devs will come.
Make decent unit test coverage and you'll hardly ever see a debugger again. Neither will you need a fancy code editor.
Nope. It is absolutely false. You will always need a debugger and there are some problems that are not unit testable at all.
How do you unit test a random WPF bug?
And you'll always need a fancy code editor unless you're masochist.
Re: I’m joining the Go team at Google
#50I'm using C# mainly because of debugger integration in Visual Studio. Make decent visual debugger and devs will come.
Make decent unit test coverage and you'll hardly ever see a debugger again. Neither will you need a fancy code editor.
That is true, I used to work in legacy Java code base and the debugger was my Lord and Saviour.
I am now working in fresh, well tested (both unit and integration) Go codebase and I yet to have to use debugger. Usually adding few debug logs (which usually just stay there for future) and writing test case for new discovered edge case is enough.