61–70 of 171 posts
I want to try out Go...but I have to make one initial observation...It can be somewhat hard to Google (ironically) for Go programming examples. I'm sure there's some tinkering you can do in your search query to get slightly better results, but "Go" is a difficult proper pronoun to facet a search around. https://www.google.com/search?q=go+facial+recognition https://www.google.com/search?q=python+facial+recognition
go ogle Earlier quoted context omitted.
Oh, I don't doubt many things can be done much better in other languages than Java, only why stop at Go? Clojure pretty much hits every single one of your requirements, it's more modern and expressive than Go, gets concurrency better, and it's about as slower than Go as Go is slower than Java -- and getting faster. Also, you don't have to give up the monitoring and instrumentation the JVM gives you, as well as the va…
> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages. This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think imm…
I don't want to join into a language war, but I wanted to point out two things with this statement:
1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.
2- Rich Hickey worked on massive telephone systems and created Clojure, at least in (large) part, out of frustration of dealing with mutation.
So there's a long line of research backed by "real world" experience showing mutation not holding up well for concurrency. Erlang is another example.
Regardless, I do agree that immutability may not be what it is hyped up to be, especially if you are looking for the mythical silver bullet, but it most certainly isn't over-hyped if you compare it to mutation, and the ideas are still quite young and being tested. Give it 20 years and I suspect there will be another paradigm shift at some point.
For the life of me I can't understand why anyone would give up the power (in terms of profiling, monitoring and ecosystem, and somewhat better performance, too) of the JVM, for a language marginally more convenient than Java, and arguably less expressive than other JVM languages. The only thing I could think of is a smaller RAM footprint, if you care about that sort of thing. Whenever Go is compared to Java, the argu…
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
Earlier quoted context omitted.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
You need to be commended for defending Go. I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries... Funny thing about Go is that as a compiled language, folks often need to sen…
This is what systems administrators with grey beards thought in the 1990s. A moment's thought about what an attacker who can run a compiler can do instead of running a compiler should be enough to inform you about how silly the idea is in practice.
Earlier quoted context omitted.
You claim (as I understand): (Java + Clojure) > Go && (Java + Scala) > Go That stance seems to require a low weight on the cost of conceptual and tool-chain overhead. I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages. Edit: Fix spelling of "Clojure".
My claim is that Go's advantages are far, far too small to outweigh not running on the JVM. (also, I think Clojure > Go -- no need for Java in the equation -- but that's not my main point)
And programmers in the New Jersey school (see Worse is Better) are unlikely to ever stomach Clojure.
These differences are more in the realm of deep allegiances and HN comments will probably be limited to revealing allegiances--they have little chance to sway the reader one way or the other.
Might as well say, "MIT type with love for the JVM? Choose Clojure. New Jersey type with love for native code? Choose Go".
For the life of me I can't understand why anyone would give up the power (in terms of profiling, monitoring and ecosystem, and somewhat better performance, too) of the JVM, for a language marginally more convenient than Java, and arguably less expressive than other JVM languages. The only thing I could think of is a smaller RAM footprint, if you care about that sort of thing. Whenever Go is compared to Java, the argu…
Earlier quoted context omitted.
> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages. This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think imm…
>> * I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.* I don't want to join into a language war, but I wanted to point out two things with this statement: 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this…
Earlier quoted context omitted.
I don't see anything special in Go for commanding the GC, can you point me to these APIs?
Go's memory model has similarities to C. For instance you can use the heap or the stack. Go figures out which one an allocation should live in by doing escape analysis. If it never leaves the function it goes on the stack. If it does it goes on the heap. GC ensures anything on the heap gets cleaned up. It's not an API.
The programmer explicitly specifies when to use pointers. Whenever pointers are not used, the object is stored in-place (for example, on the stack, in the array or slice, or in the struct).
Earlier quoted context omitted.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
You need to be commended for defending Go. I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries... Funny thing about Go is that as a compiled language, folks often need to sen…
But when someone says they don't understand why someone else would want to do things differently I just naturally want to help them understand :-)
Earlier quoted context omitted.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
You need to be commended for defending Go. I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries... Funny thing about Go is that as a compiled language, folks often need to sen…
Doesn't seem like a situation precipitated by something in Go. I've found cross-compilation to be very easy and effective. Having your build setup on the deployment servers would negate the advantage of the dependency free single-binary deployment.