51–60 of 211 posts
Earlier quoted context omitted.
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.
I'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...
I'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.
> As I had before, I recognized that this technology had the potential to revolutionize how software was written at a fundamental level. Congrats and all, and I love Hugo (use it all the time). That said, I think the kool-aid was spiked with something. Sorry, but in what way is Go "revolutionizing"? I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly revolutionary, even in its most touted f…
Earlier quoted context omitted.
As a habit it is bad, but this is actually standard for short bios. It allows it to be dropped in place directly for conferences, PR shots, news articles, etc without any rewrite.
Great to make it look like someone took the time to do a bio about you because you're important, while it's just you writing. Lack of self-confidence if you ask me.
e.g. top hit on google: http://smallbusiness.chron.com/write-short-bio-yourself-5728...
I'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.
I'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
I'm using C# mainly because of debugger integration in Visual Studio. Make decent visual debugger and devs will come.
I'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.
How does Go completely ignore run-time errors? For all I know it forces you to deal with them by treating them as values instead of exceptions.
> As I had before, I recognized that this technology had the potential to revolutionize how software was written at a fundamental level. Congrats and all, and I love Hugo (use it all the time). That said, I think the kool-aid was spiked with something. Sorry, but in what way is Go "revolutionizing"? I'd buy "refreshing simplicity" and "yay, static builds again" but it's hardly revolutionary, even in its most touted f…
Some of the harder more time consuming things in high level programming include abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java. Think about how many hours you have to invest to learn any of these things in either language.
Really? A lot of copy/pasted code, generics replaced with casts on empty interfaces, poor support for collections, only very primitive concurrency tools, and so on...
I can understand that simplicity is good for small CLI/network tools, but it is hardly an alternative for really big applications where Java is vastly used