3 ms·

I'm just starting to listen to this particular talk, but I want to comment now so this talk doesn't get buried. I have to say that I'm very impressed with the

I'm just starting to listen to this particular talk, but I want to comment now so this talk doesn't get buried. I have to say that I'm very impressed with the Clojure community's eagerness to engage the real world in a way that most of my favorite languages haven't, while at the same time holding fairly firm on the things that matter (e.g. code readability and simplicity, referential transparency as a default, avoidance of OO traps).

swah 13y ago
Would you say the Go community is similar in that regard?
- michaelochurch 13y ago
  I don't follow it much. The language is very good for its purpose (a compiled production language for large codebases that isn't painful to use) and the implementation is great, but I don't know much about the community itself. When I worked at Google, I talked to a couple of the Go developers and they were really sharp guys, so that's a strong signal.
  - pjmlp 13y ago
    The thing is most modern languages we use can be compiled to native code ahead of time. The fact that most people tend to use VM based implementations, tends to be related to: - not having the knowledge that implementation != language - not willing to pay for third parties native compilers - AOT compilation in some cases does not provide a proper optimizing compiler and ends up providing lesser experience than the JIT. Finally being compiled to native code, instead of relying on a JIT, tends to be more beneficial to client and embedded environments. Not so much for server side, except for the initial startup time. I was also using it in the beginning given its Oberon influence, but nowadays I am back to more CS friendly languages, given my background. But I miss the fact that most strong typed languages nowadays don't compile directly to native code in their canonical implementations. As for the community, yes they may have some strong opinions, specially in the most polemic areas around Go, but they are nice guys.
    - swah 13y ago
      What about being able to instrument applications? That seems to be a big thing that VMs should naturally handle better... (http://metrics.codahale.com/ http://metrics.codahale.com/)
      - pjmlp 13y ago
        True, but you can also produce instrumented binaries for the same purpose. http://software.intel.com/en-us/intel-vtune-amplifier-xe http://software.intel.com/en-us/intel-vtune-amplifier-xe The thing is many developers don't want to pay for such tooling in the age of free.
- coolsunglasses 13y ago
  Golang developers follow the suckless/plan9 (cf. Uriel) aesthetic which isn't concerned with immutability, referential transparency, or anything else from the FP world. Fairly practical people though. I used to write Go but found it intensely tedious, so I went back to Clojure. Been happily clojuring since '08.
  - michaelochurch 13y ago
    Where do you work that you use Clojure? It's a great language.
    - coolsunglasses 13y ago
      Self-employed, I'm the one working on that fashion thing.

swah 13y ago

Would you say the Go community is similar in that regard?

michaelochurch 13y ago
I don't follow it much. The language is very good for its purpose (a compiled production language for large codebases that isn't painful to use) and the implementation is great, but I don't know much about the community itself. When I worked at Google, I talked to a couple of the Go developers and they were really sharp guys, so that's a strong signal.
- pjmlp 13y ago
  The thing is most modern languages we use can be compiled to native code ahead of time. The fact that most people tend to use VM based implementations, tends to be related to: - not having the knowledge that implementation != language - not willing to pay for third parties native compilers - AOT compilation in some cases does not provide a proper optimizing compiler and ends up providing lesser experience than the JIT. Finally being compiled to native code, instead of relying on a JIT, tends to be more beneficial to client and embedded environments. Not so much for server side, except for the initial startup time. I was also using it in the beginning given its Oberon influence, but nowadays I am back to more CS friendly languages, given my background. But I miss the fact that most strong typed languages nowadays don't compile directly to native code in their canonical implementations. As for the community, yes they may have some strong opinions, specially in the most polemic areas around Go, but they are nice guys.
  - swah 13y ago
    What about being able to instrument applications? That seems to be a big thing that VMs should naturally handle better... (http://metrics.codahale.com/ http://metrics.codahale.com/)
    - pjmlp 13y ago
      True, but you can also produce instrumented binaries for the same purpose. http://software.intel.com/en-us/intel-vtune-amplifier-xe http://software.intel.com/en-us/intel-vtune-amplifier-xe The thing is many developers don't want to pay for such tooling in the age of free.
coolsunglasses 13y ago
Golang developers follow the suckless/plan9 (cf. Uriel) aesthetic which isn't concerned with immutability, referential transparency, or anything else from the FP world. Fairly practical people though. I used to write Go but found it intensely tedious, so I went back to Clojure. Been happily clojuring since '08.
- michaelochurch 13y ago
  Where do you work that you use Clojure? It's a great language.
  - coolsunglasses 13y ago
    Self-employed, I'm the one working on that fashion thing.