I thought GO was dead... just like googlevideos and igoogle...
Go as an alternative to Node.js for Very Fast Servers
121–130 of 147 posts
Re: Go as an alternative to Node.js for Very Fast Servers
#122Earlier quoted context omitted.
Unlike C++, Go enforces that its dependency graph be a DAG. In C++ header dependencies are also a DAG, since include guards prevent cycles (and multiple includes). What makes Go faster are a few things: (1) C++ headers contain templates, which are slot to compile; (2) Go only looks at direct imports and uses the compiled form of those imports, rather than recursing over their imports (again); (3) Go is simpler to par…
Compilation units can rely on each other through forward declarations, so the dependency graph is not acyclic. Header exclusion does form a DAG within a compilation unit, I guess.
A forward declaration is not really a compile time dependency.
If you are forward declaring a function, you are just promising that it is present during linking. So, during compilation it is not an edge in the graph.
If you are forward declaring a data type such as a class, a full definition needs to be visible at its first use or you are using the type as a pointer:
class A;
class B {
A *d_a;
[...]
};
Could you give an example where C++ dependencies are not a DAG during compilation?
Re: Go as an alternative to Node.js for Very Fast Servers
#123I wonder how Go compares to SilkJS, since SilkJS is much faster than Node.
Re: Go as an alternative to Node.js for Very Fast Servers
#124Earlier quoted context omitted.
> I think this is due to the go runtime allocating an OS thread for each goro as it goes through the socket close() blocking call. I think it has to do this to maintain concurrency I highly doubt that it is creating a thread per goro on client disconnect. If you have a minimalish example of this, the golang mailing list would be very interested in working with you to identify what went wrong and create a patch if it…
Blocking system calls spawn OS threads in Go, which can be cached and recycled for new goroutines. You don't see this if you code to pkg/net because it multiplexes i/o with a select/kqueue goroutine, but you'll see it right away if you code directly to the syscalls. Close isn't a blocking call, though.
Close is annotated as a blocking syscall in http://golang.org/src/pkg/syscall/syscall_linux.go#L810
Is there a guarantee on Linux that close can't block? (I suppose it depends on the file type and the definition of blocking.)
Re: Go as an alternative to Node.js for Very Fast Servers
#125Earlier quoted context omitted.
Yes, but at what point does go transition from obscurity to PG's "python paradox"? http://www.paulgraham.com/pypar.html It sure seems Scala's in this "python paradox" land now. My guess is that you need some startups make it big using Go to evangelize it. Google using it is interesting, but I'm not sure it makes it "cool". Though, I'm not sure Java was ever a language you could use as a skillset filter. Hm.
I think a lot of the "coolness" factor of Go comes not from its parent company, but from some of its core developers, namely Rob Pike & Ken Thompson. That gives Go a serious Bell Labs/Unix/Plan 9 pedigree. I don't follow the mailing list anymore, so I don't know if it already led to the same "cargo cult" fanboyship that Plan 9 sometimes evokes, where a lot of the idiosyncratic opinions of its developers (e.g. "shared…
Yes!
Re: Go as an alternative to Node.js for Very Fast Servers
#126Earlier quoted context omitted.
I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests. I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ -- nodejs completed in 160 sec…
Because this isn't the same benchmark, did you compile with -O2? The Go version allocates a 1MB slice once and sends it to every user. The Haskell version literally states that it should make a bytestring during every request. The compiler might optimize it away with the right flags.
No, I didn't (see my other comment). I expect (especially Haskell) to be correct without -O2 -- being slower isn't a problem - crashing - not so much.
Tried it now -- both haskell versions crash with -O2 as well (and ab -n 100000 -c 1000 -- so not the same benchmark as the original -- and a rather silly test).
Re: Go as an alternative to Node.js for Very Fast Servers
#127Earlier quoted context omitted.
Go's package manager does have version control. It looks for specially named branches (different ones depending on the version of go you have). The upstream authors can provide a different version of the software for different releases of Go. If you want to lock down the versions of all the software you're deploying in your organization, that's easy to do too. Just "git clone" all of the libraries you use to some int…
The go import tool does version go std lib packages, but I think the worry is more about external packages - later when the go ecosystem matures, and I'm relying on lots of packages from different sources (say for a web app), with interdependencies, and I must update them regularly for security updates, but don't necessarily want the latest master for all, I have no way to specify versions without rolling my own pers…
Great having one bringing a balanced view on Go and showing that Go is still not ready for production when used with external libs. A refreshing take in this overhyped thread.
Re: Go as an alternative to Node.js for Very Fast Servers
#128Earlier quoted context omitted.
The go import tool does version go std lib packages, but I think the worry is more about external packages - later when the go ecosystem matures, and I'm relying on lots of packages from different sources (say for a web app), with interdependencies, and I must update them regularly for security updates, but don't necessarily want the latest master for all, I have no way to specify versions without rolling my own pers…
Great having one bringing a balanced view on Go and showing that Go is still not ready for production when used with external libs. A refreshing take in this overhyped thread.
I'm not sure I'd agree that it is not ready for production, but there are some kinks (relatively minor I feel) which will become more apparent when it is used more widely than it is currently in production. Just as Ruby (for example) has gone through a trial of fire since becoming popular because of Rails, and has been much improved because of it.
Re: Go as an alternative to Node.js for Very Fast Servers
#129Earlier quoted context omitted.
Blocking system calls spawn OS threads in Go, which can be cached and recycled for new goroutines. You don't see this if you code to pkg/net because it multiplexes i/o with a select/kqueue goroutine, but you'll see it right away if you code directly to the syscalls. Close isn't a blocking call, though.
Close is annotated as a blocking syscall in http://golang.org/src/pkg/syscall/syscall_linux.go#L810 Is there a guarantee on Linux that close can't block? (I suppose it depends on the file type and the definition of blocking.)
Only if SO_LINGER is set.
Re: Go as an alternative to Node.js for Very Fast Servers
#130Earlier quoted context omitted.
I've done Java, PHP, Objective Caml (in college for a few years), some basic C, Ruby and Javascript before and I concur. Go is a real breath of fresh air. I have the same feeling I have when I code with Ruby: that sense that the language works WITH me, that the whole experience is smooth and seamless. I wish Go stays on that path for a long time. And it never gets TOO big, which makes for awful communities.
Maybe you didn't do much OCaml? I've found it to be mostly significantly better than Go, especially with it's type system. Go's type system is relatively limited and ad-hoc where OCaml's is extremely elegant, simple and consistent. In particular, OCaml has an awesome module system and a great take on structural sub-typing combined with proper type inference and sane parametric polymorphism. Having actual algebraic da…
I find this recommendation interesting because I am developing an OpenPGP keyserver in Go, called Hockeypuck (https://launchpad.net/hockeypuck). I started the project because of problems I ran into with SKS in a very specialized, write-heavy use case. SKS is developed in OCaml.
I've been porting the reconciliation algorithm in SKS to Golang so Hockeypuck can peer with SKS servers. I think it will be very useful in other applications beyond keyservers. The mathematical definitions of finite fields and polynomials are elegant in OCaml, and I definitely understand the choice of language from that point-of-view.
If you want to see a comparison of finite-field arithmetic and polynomial factoring in Go vs OCaml, my recon port is in a separate project called conflux (https://github.com/cmars/conflux). It's an incomplete work in progress, needs tightening up, tail-call elimination, etc. but early feedback is welcome.
As a developer unfamiliar with OCaml & without much formal mathematics background, I had a hard time understanding some of the intent of the SKS sources -- in those cases, conflux is a straight-up port from OCaml with unit-tests also ported from SKS to back it up. Some of it, I understood the math concept, but not the OCaml, so I ported from SymPy instead.
Wolfram Alpha was also helpful to validate my work and create test cases -- it does polynomial factoring over finite fields!