4 ms·

I think it would be easier to take the best stuff in the node ecosystem and port it to Erlang than the other way around.

ebiester 14y ago
How do you bring code sharing between the server and client into Erlang? :) Edit: I should have given a little more value on the post. I left node for Scala because the advertised code sharing wasn't worth having to work around an event architecture that I found hard to debug (as I've mentioned elsewhere) and I too considered Erlang before settling on Scala due to our previous java experience and my co-founder's knowledge of people in the Scala community. But fundamentally, node.js isn't interesting if it's not in Javascript. Actors seem like a better model than futures tacked on to callbacks, and frankly javascript's quirks (like having to use require.js for modularization rather than a feature built into the language!) IMHO don't make for a compelling case. I'd use node.js on someone else's project, but I don't know if I'd pick it for my own.
- stuffihavemade 14y ago
  I wonder how hard it would be to make JS compile to Erlang like Elixir. I think the big problem would be some kind of actor model in the browser with everything callback based. Other than that, they're both dynamically typed, functional (Erlang obviously more) languages.
  - ebiester 14y ago
    It's possible, but you can also end up with monstrosities like GWT in the end. The best bet is to implement some Actor-like layer like https://github.com/Gozala/actor https://github.com/Gozala/actor upon which the "ErlangScript" depends. Oh wait, JS compile to Erlang? Wouldn't it make sense to do it the other way around?
    - stuffihavemade 14y ago
      I think it makes more sense to go JS -> Erlang, because the valuable thing about JS is the language itself (and trying to achieve code sharing), while the valuable thing about Erlang is the vm/concurrency model/OTP.
- javajosh 14y ago
  You are right on all points ebiester, but you missed the one compelling reason to use node anyway: the browser is well on it's way to being the dominant programming model (and for a good reason: application components and data are addressable by other applications via the DOM! this turns out to be necessary to have globe-spanning meta-programs like search, and also useful personal meta-programs like Evernote) and that model can and will extend into the server. JavaScript is a quirky language but can and will get's it's act together. "use strict" for example was a good step in the right direction. Even more than that, I think that the entire notion of what a server is for is changing rapidly away from "server-side MVC" to a far more rational (not to mention more efficient) dual role of "initially serve a client" and then "handle messages from the client". Server-side manipulation of client state is a horrible, terrible idea in any language, and right now node is suffering from cultural/technical momentum of wanting to do things that way. Once that impulse goes away and alternatives become more popular and well-understood, I think node will get even more popular.
  - stuffihavemade 14y ago
    Can you expand a bit on what you meant by "...and that model can and will extend into the server."?
    - javajosh 14y ago
      Sure. I think server software should be constructed, simulated and visualized in a browser. Server components can be sourced from around the net, pulled into a shared environment, inspected, tested, and connected, and then when you're ready, pushed onto the server. This approach has the added benefit that when get to client code, a lot of what the client needs to know about the server is available to it, either at build time or even at runtime.

ebiester 14y ago

How do you bring code sharing between the server and client into Erlang? :) Edit: I should have given a little more value on the post. I left node for Scala because the advertised code sharing wasn't worth having to work around an event architecture that I found hard to debug (as I've mentioned elsewhere) and I too considered Erlang before settling on Scala due to our previous java experience and my co-founder's knowledge of people in the Scala community. But fundamentally, node.js isn't interesting if it's not in Javascript. Actors seem like a better model than futures tacked on to callbacks, and frankly javascript's quirks (like having to use require.js for modularization rather than a feature built into the language!) IMHO don't make for a compelling case. I'd use node.js on someone else's project, but I don't know if I'd pick it for my own.

stuffihavemade 14y ago
I wonder how hard it would be to make JS compile to Erlang like Elixir. I think the big problem would be some kind of actor model in the browser with everything callback based. Other than that, they're both dynamically typed, functional (Erlang obviously more) languages.
- ebiester 14y ago
  It's possible, but you can also end up with monstrosities like GWT in the end. The best bet is to implement some Actor-like layer like https://github.com/Gozala/actor https://github.com/Gozala/actor upon which the "ErlangScript" depends. Oh wait, JS compile to Erlang? Wouldn't it make sense to do it the other way around?
  - stuffihavemade 14y ago
    I think it makes more sense to go JS -> Erlang, because the valuable thing about JS is the language itself (and trying to achieve code sharing), while the valuable thing about Erlang is the vm/concurrency model/OTP.
javajosh 14y ago
You are right on all points ebiester, but you missed the one compelling reason to use node anyway: the browser is well on it's way to being the dominant programming model (and for a good reason: application components and data are addressable by other applications via the DOM! this turns out to be necessary to have globe-spanning meta-programs like search, and also useful personal meta-programs like Evernote) and that model can and will extend into the server. JavaScript is a quirky language but can and will get's it's act together. "use strict" for example was a good step in the right direction. Even more than that, I think that the entire notion of what a server is for is changing rapidly away from "server-side MVC" to a far more rational (not to mention more efficient) dual role of "initially serve a client" and then "handle messages from the client". Server-side manipulation of client state is a horrible, terrible idea in any language, and right now node is suffering from cultural/technical momentum of wanting to do things that way. Once that impulse goes away and alternatives become more popular and well-understood, I think node will get even more popular.
- stuffihavemade 14y ago
  Can you expand a bit on what you meant by "...and that model can and will extend into the server."?
  - javajosh 14y ago
    Sure. I think server software should be constructed, simulated and visualized in a browser. Server components can be sourced from around the net, pulled into a shared environment, inspected, tested, and connected, and then when you're ready, pushed onto the server. This approach has the added benefit that when get to client code, a lot of what the client needs to know about the server is available to it, either at build time or even at runtime.