251–260 of 271 posts
Earlier quoted context omitted.
Java is also compiled to native code, but only after it runs for a bit.
Android does AOT compiling with ART, it became the default in Lollipop.
Earlier quoted context omitted.
Are you aware that Java already has value types? Do you realize that the JVM has primitive collections, which completely ignore all of the boxed types that are, yes, a performance suck, via Trove? Nobody writing perf-conscious Java is using bleeping HashMap or even ArrayList . They're using Trove's TIntIntMap, TLongSet, etc. and getting the. exact. same. thing you're saying they're not. Or they're using arrays. And h…
Thanks for the tip on the Trove library. Even though I hate the JavaXML language , the JVM is really hard to beat for long running processes on a dedicated server. And the kids gotta eat, so JavaXML it is... (have an upvote from an otherwise Java lang hater for being convincing) Aside: I propose renaming the primary language for enterprise apps to just one word, "JavaXML" (zha VOX em el), since the two are essentiall…
Though, food for thought: I have written a fairly decent amount of Java in the past, and in what I would consider "modern practice" it has very little to do with XML. With Play, Dropwizard, and similar, you have no obligation to put up with something like Spring herpderp anymore. Or even Maven; SBT or Gradle are fine.
.
Anyway--what grinds my gears, and why I posted at all, is that I have noticed in the Go community--not, I hasten to mention, enneff, as he said I think he and I are probably more in the space place than not--a really weird unwillingness to credit other environments for anything, whether from stubbornness or ignorance. If I can speculate--and I can--I think that comes from two places. I think one is the origination of many Go advocates being Python and Ruby, which are both former new-hotness ecosystems that themselves don't encourage breadth or depth in the programming languages space; in the Ruby community at least Java is often held as this inscrutable "enterprise" thing that can't possibly have any real benefits, and I feel like that's leaked into Go. The other is the cultural origination of Go in Plan 9--Keith Wesolowski's views on the second-system effects of Plan 9 and the epistemic closure and cult-of-personality effect of its developers and community are good ones and I don't need to repeat them here.
Right now, to me, Go is a mishmash of Java 1.3 and Java 1.4, right down to the overuse of green threads and the too-simple type system that forces you to trade safety when you want code reuse. And that's totally fine for people who like it. But it's nothing special, and the breathless hype around it from people who plainly haven't gotten their hands dirty with what came before makes me want to boil my head. Or their heads. After all, I like my head.
Earlier quoted context omitted.
> What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version co…
Honest curiosity here. Given that there's nothing stopping you from deleting your fork after the PR is done, what reasons can you name for this: There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all
There are lots of reasons why I may not want my github
fork to be public or I don't want to have a github fork
at all
They said if people saw what they were doing in real time, it would probably cause mass panic among the community. (Oh no! You're removing feature X?)
Earlier quoted context omitted.
JNI is un-fun, so JVM developers are working on the solution. I think Panama will arrive sooner than Go making any inroads. http://openjdk.java.net/projects/panama/
Good thing. Though Go made inroads in all kids of Web / Cloud infrastructure considering Java should be the first(only?) choice with production grade application servers etc already present. I think Panama shows Java was late to realize that native code easy access is getting more important for Java even with better hardware. Where I work ~16GB Java heap makes gc pauses huge and unpredictable. I think Java performanc…
Lets be honest here, seeing the popularity of Ruby a few years ago we know that performance is not all either. And knowing were Java was in 2000 we know the same ;) First languages need to be used and then they get fast (even if it takes quite a while before that is true).
Earlier quoted context omitted.
> Don't use the merge button, just add the requester's repo as a remote to yours Actually, you don't need to do that. GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so: [remote "upstream"] url = https://github.com/neovim/neovim.git fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/pull/upstream/* Then wh…
is this documented somewhere on github?
Earlier quoted context omitted.
Doesn't Go have the potential to be faster than Java since it's compiled to native code (rather than compiled to byte code)?
JIT has potential to be faster than compiled native code. Better runtime information. Compiled code needs to cover all potential options and this means more instructions to execute. Say a variable value is set through a command line option to be a certain value. Compiled native code has to assume the value to be dynamic, but a JIT can optimize it away, effectively hardcoding it for that particular invocation. Same ap…
One other aspect that has become increasingly important is power consumption and heat. Huge data centers now have to worry about enormous electricity consumption and keeping all the equipment cool. JIT code must do more work to compile (and recompile to optimize) on the fly which means more power and more heat.
On the consumer end, Android just switched to Ahead of Time compilation instead of JIT because its JIT performance wasn't that good and it required more power thus sucking battery life.
Go binary size is a non-issue for most software. The java-rewrite I mentioned above went from a 80MB or so binary, to a 8MB executable. That said, there's been a few occasions when I've really wanted to use go for an embedded project, but couldn't due to it's size.
I read somewhere, someone said of go, "you'll come for the concurrency, but you'll stay for the interfaces. This is very true for me.
Generics. Go's red herring. Sure, there's been a handful of occasions where generics would have saved me some boiler-plate, but it's not been a pain point for me.
Tooling, from fmt, vet, to unit testing are all first rate. However, I wish there was a better debugger option for go. I know that gdb works with go (and with a great deal of difficulty if you develop with OSX) but I'm probably not alone when I say I really dislike GDB.
Overall, I've found the community to be friendly both online and in person.
As an aside, I've noticed much of the recent vitriol towards Go seems to come from the Rust crowd which I think is too bad. I enjoy both. Languages are not a zero-sum game. Who knows, the hate means Go has finally arrived.
Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…
> What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version co…
I think go is failed, compare to rust. 1. not memory safe on multi-thread 2. no generic support 3. error handle is full of pain compare to rust's Result , Option and try! 4. gc can't be disable 5. no RAII support, defer can be forgot light-weight thread (spawn) and channel (thread safe FIFO) already exist in rust that make golang more meanless. If you think still any advantage of go please tell me.
Go is stable, wheras Rust is not. Go also targets other use cases than Rust, and so the two are not directly comparable. 1. Rust cannot guarantee multi-threaded memory safety in all cases. Care, as in Go, must still be taken. 2. I agree with you here, I think Go would be better with generics. But apparently, most people don't have a problem with this. 3. Rust and Go's error handling is based on the same principle: fo…