121–130 of 235 posts
Earlier quoted context omitted.
Depends. For me, creating an uberjar with my default project/package manager is easier than to setup cross-compilation with Go. YMMW.
Why don't they just combine the JRE and JAR file? Then I can be sure it works when I download it.
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.
Earlier quoted context omitted.
As I get older and I gain more perspective, I can't stress enough how true this is. Listening to younger programmers bemoan Ruby and Rails is humorous to me because they don't remember the world of Java web dev before Rails. Miles of XML configs everywhere, factories, impls, proxies, beans. So. Much. Boilerplate. It's easy to bitch about things the way they are now, but understand there are people and technologies wh…
Now I'm confused. I've heard that we should learn and appreciate that nothing is new under the sun and most interesting concepts and technologies have already been invented in the past and not newly by newer technologies. Now you're saying that newer technology consistently improve things? I'm getting confused as to how the older hive mind is telling me to feel.
Earlier quoted context omitted.
As I get older and I gain more perspective, I can't stress enough how true this is. Listening to younger programmers bemoan Ruby and Rails is humorous to me because they don't remember the world of Java web dev before Rails. Miles of XML configs everywhere, factories, impls, proxies, beans. So. Much. Boilerplate. It's easy to bitch about things the way they are now, but understand there are people and technologies wh…
Now I'm confused. I've heard that we should learn and appreciate that nothing is new under the sun and most interesting concepts and technologies have already been invented in the past and not newly by newer technologies. Now you're saying that newer technology consistently improve things? I'm getting confused as to how the older hive mind is telling me to feel.
Maybe that means it's not a hive mind? Different people have different views, I suppose.
> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is st…
> But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. If there's any benchmark more pointless than the alioth benchmarks game, it's the 'what can a novice programmer do with the language in the course of 8 hours' benchmark. There are zero businesses that operate by giving novice programmers 8-hour tasks in unfamiliar l…
Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…
At least this guy actually used it for more than an afternoon... Though anyone who says they don't understand go's pointers after that length of time is a somewhat questionable source.
I've been using go full time for two years and love it.
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…
Isn't that true of any language with even the simplest mechanism for abstraction?
How about this go code?
doStuff(1, 2)
Earlier quoted context omitted.
> You deploy. You're done. Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then... Yeah.
Yeah. But you don't have to, you're literally complaint that the user has options. It's not like Go doesn't have a GC either.
I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…
> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…