201–210 of 235 posts
Earlier quoted context omitted.
As a * nix geek it's beneath his station. Welcome to the flip side of the academic ivory tower , the scoff at academic stuff because it doesn't "get shit done" .
It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!
Earlier quoted context omitted.
> I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.
Have you ever worked on a large-scale C++ project?
Put another way, much of the problem is "modern compiler optimization takes a long time". Go's solution was "remove the modern optimizer". That doesn't actually solve my problem.
Earlier quoted context omitted.
"Let's also not forget that Java is significantly faster" Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.
As always, it depends on what you're measuring. I find it to be largely a wash http://benchmarksgame.alioth.debian.org/u64q/go.html Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.
It's amazing how Go caught on. It's not well designed -- lots of special cases reserved just for the compiler, some bizarro decisions, etc. It's not modern (with the possitive associates of modern, not fadish, and modern being "the last 30 years of experience" which is still like a millenium in IT years). It's implementation is not great either. Not a very good compiler, not a very good GC, not good tooling. My theor…
> It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types. What is wrong with this? Exposing people to pointers and static types might give them confidence when writing or reading in "real programmers" code in C I find the level of sneery nose turning in this thread quite abhorrent to be honest.
I don't see it as sneery nose-turning. Rather I see it as an acknowledgement that the real difficulty of C isn't pointers but rather is manual memory management, which Golang doesn't prepare you for.
Earlier quoted context omitted.
As a * nix geek it's beneath his station. Welcome to the flip side of the academic ivory tower , the scoff at academic stuff because it doesn't "get shit done" .
It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!
Earlier quoted context omitted.
As someone who used Go in the past for work and now uses Haskell, I can say that the advantages of Haskell over Go are more than "just theoretical". In my day job I use Haskell to "just get shit done". However when it comes time to refactor I can do it much faster and safer in Haskell. The ease of refactoring creates an incentive to improve code.
Seems like Go and other imperative languages are easier to start a project off with, but functional languages really shine when the code becomes really large and complex.
I think a lot of us miss the Go point. There is nothing special about Go. It's simple and just works. Every time I used Go for a project it just worked. No fuss. With very little effort. And that's the point.
But that doesn't answer any of the (very valid) points raised in the article? Go is interesting as a replacement for a scripting language, perhaps. But it seems very lacking in many other areas. All of the points in the article, plus what libraries are available. I think some of it could be explained by it being a young language, but if that's the case, why is it getting the adoption it has so far? Just because it ca…
Go is the poster child for Worse is Better. It's ugly, inconsistent, feels naughty at times (all those copy-pastes ! It's so un-DRY !) but it gets shit done.
Earlier quoted context omitted.
It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!
I read Dewie3's comment as agreeing with you, albeit via sarcasm and cynicism (and some negativity).
Earlier quoted context omitted.
It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!
Try building a package with Haskell dependencies for a linux distribution sometime. It is horrifying.
Building with vanilla cabal I might have some issues, but professional haskeller's use the tools mentioned above.
Earlier quoted context omitted.
I have never once seen anything approaching obfuscation in any "serious" Python code.
Depends on what you consider obfuscation. Consider the following python code: a.b = c In isolation, there is really no way to tell what that line of code will do. Maybe it will simply assign c to a.b. But because Python has property setters, it might also update some rows in a database[1], write a file, or make an HTTP request. One might call that abstraction, but I think it qualifies as obfuscation. A single line ca…