4 ms·

Author here. Indeed! The very first version of websocketd was actually written in Node. It's great for this kind of stuff. The reason I switched to Go was to m

Author here. Indeed! The very first version of websocketd was actually written in Node. It's great for this kind of stuff. The reason I switched to Go was to make distribution/installation for end users easier.

AsymetricCom 13y ago
Of course, Perl has been doing this for over a decade. Nobody thought it was remarkable enough to write an article about it though.
- deleted 13y ago
  [deleted]
- huhtenberg 13y ago
  Not just Perl. This is basically inetd re-invented. [0] http://en.wikipedia.org/wiki/Inetd http://en.wikipedia.org/wiki/Inetd
  - joewalnes 13y ago
    huhtenberg: I believe AsymetricCom was referring to being able to compile an executable using perlcc. He wasn't referring to the networking aspects of it (WebSockets have not been around 10 years). huhtenberg: You're right. It's very similar to inetd - that's why the first sentence in the websocketd description is "Like inetd, but for WebSockets". The thing it adds on top of inetd is it takes care of the protocol so the underlying app doesn't need to. Namely HTTP WebSocket handshaking and data framing.
bsg75 13y ago
Curious as to the approach of pulling a project local Go distribution instead of using the default. Is this to ensure Go version compatibility?
- chimeracoder 13y ago
  > Is this to ensure Go version compatibility Huh? There are no version compatibility issues with Go. Just use the most recent version of the compiler to compiler your code. Anything written since Go 1.0 is compatible with all the 1.x compilers. Anything written before that (which is truly ancient code at this point) can be updated automatically with the 'go fix' command.
  - bsg75 13y ago
    The Makefile in the project pulls a copy of Go v1.1.2 into the local tree, builds, and uses that to build websockets: # Self contained Go build file that will download and install (locally) the correct # version of Go, and build our programs. Go does not need to be installed on the # system (and if it already is, it will be ignored). I wondering why.
    - joewalnes 13y ago
      Author here. 2 reasons. 1. So developers can do a clean checkout and it will just work. No external dependencies needed (e.g. manually installing Go, setting GOPATH etc). 2. To ensure that anyone who builds and releases it always uses the exact same version of Go.
      - chimeracoder 13y ago
        > 2. To ensure that anyone who builds and releases it always uses the exact same version of Go. Please don't do this! It's attempting to solve a problem that doesn't exist. As I mentioned above, Go does not have compatibility issues with different version of the compiler. This is a huge strength of Go, and spreading the idea that using the same version of Go is somehow beneficial creates misunderstanding for new developers. I challenge anyone to find an example of Go 1.x code in which using the most recent version of the compiler will build an incorrect binary. Seriously, if you find one, please let me (or better yet, the Go mailing list) know, because the Go team has made a dedicated effort to make sure that this doesn't happen. (Such cases exist, but I am fairly certain without even looking that this program doesn't run into any, whereas it's clear (below) that the Makefile for this project doesn't handle cases that the standard build tools do.) I didn't understand this when I started using Go over a year ago - at the time, I also used Makefiles over Go's built-in build tools, and did a number of other non-idiomatic things surrounding the build process. More experienced Go programmers told me I was wrong, and I didn't listen at first. In the end, I finally realized that they were right: it added complexity for literally zero value. Please don't make the same mistakes that I did.

AsymetricCom 13y ago

Of course, Perl has been doing this for over a decade. Nobody thought it was remarkable enough to write an article about it though.

deleted 13y ago
[deleted]
huhtenberg 13y ago
Not just Perl. This is basically inetd re-invented. [0] http://en.wikipedia.org/wiki/Inetd http://en.wikipedia.org/wiki/Inetd
- joewalnes 13y ago
  huhtenberg: I believe AsymetricCom was referring to being able to compile an executable using perlcc. He wasn't referring to the networking aspects of it (WebSockets have not been around 10 years). huhtenberg: You're right. It's very similar to inetd - that's why the first sentence in the websocketd description is "Like inetd, but for WebSockets". The thing it adds on top of inetd is it takes care of the protocol so the underlying app doesn't need to. Namely HTTP WebSocket handshaking and data framing.

bsg75 13y ago

Curious as to the approach of pulling a project local Go distribution instead of using the default. Is this to ensure Go version compatibility?

chimeracoder 13y ago
> Is this to ensure Go version compatibility Huh? There are no version compatibility issues with Go. Just use the most recent version of the compiler to compiler your code. Anything written since Go 1.0 is compatible with all the 1.x compilers. Anything written before that (which is truly ancient code at this point) can be updated automatically with the 'go fix' command.
- bsg75 13y ago
  The Makefile in the project pulls a copy of Go v1.1.2 into the local tree, builds, and uses that to build websockets: # Self contained Go build file that will download and install (locally) the correct # version of Go, and build our programs. Go does not need to be installed on the # system (and if it already is, it will be ignored). I wondering why.
  - joewalnes 13y ago
    Author here. 2 reasons. 1. So developers can do a clean checkout and it will just work. No external dependencies needed (e.g. manually installing Go, setting GOPATH etc). 2. To ensure that anyone who builds and releases it always uses the exact same version of Go.
    - chimeracoder 13y ago
      > 2. To ensure that anyone who builds and releases it always uses the exact same version of Go. Please don't do this! It's attempting to solve a problem that doesn't exist. As I mentioned above, Go does not have compatibility issues with different version of the compiler. This is a huge strength of Go, and spreading the idea that using the same version of Go is somehow beneficial creates misunderstanding for new developers. I challenge anyone to find an example of Go 1.x code in which using the most recent version of the compiler will build an incorrect binary. Seriously, if you find one, please let me (or better yet, the Go mailing list) know, because the Go team has made a dedicated effort to make sure that this doesn't happen. (Such cases exist, but I am fairly certain without even looking that this program doesn't run into any, whereas it's clear (below) that the Makefile for this project doesn't handle cases that the standard build tools do.) I didn't understand this when I started using Go over a year ago - at the time, I also used Makefiles over Go's built-in build tools, and did a number of other non-idiomatic things surrounding the build process. More experienced Go programmers told me I was wrong, and I didn't listen at first. In the end, I finally realized that they were right: it added complexity for literally zero value. Please don't make the same mistakes that I did.