Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Erlang Shell

medium.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: The Erlang Shell

#41

Post by Veratyr »

Jacqued wrote: post #38
phamilton wrote: post #13

I'm another recent Erlang convert (though I'm still trying to get used to the paradigm and ecosystem). There are a few concepts that haven't quite clicked for me. I come from a Rails background. While Erlang's hot code reloading and the ability to attach to running nodes is cool, I am not quite able to connect the dots on how this is useful. In Rails, a process is short-lived by design (the lifecycle of a request). A…

Since you recently started out, may I ask you what good resources you found to get started with Erlang ?

http://learnyousomeerlang.com/ seems to be the standard reference. I find it most amusing in both style and name (Learn You Some Erlang -> LYSE -> Lies) as well as informative.

Re: The Erlang Shell

#42

Post by Luc »

Jacqued wrote: post #38
phamilton wrote: post #13

I'm another recent Erlang convert (though I'm still trying to get used to the paradigm and ecosystem). There are a few concepts that haven't quite clicked for me. I come from a Rails background. While Erlang's hot code reloading and the ability to attach to running nodes is cool, I am not quite able to connect the dots on how this is useful. In Rails, a process is short-lived by design (the lifecycle of a request). A…

Since you recently started out, may I ask you what good resources you found to get started with Erlang ?

Besides 'Learn You Some Erlang', Joe Armstrong's new 'Programming Erlang' is very good, too: www.amazon.com/dp/B00I9GR4TW/

Re: The Erlang Shell

#43

Post by logicchains »

bitwalker wrote: post #16
agentultra wrote: post #12

Earlier quoted context omitted.

> Is it actually possible to do hot code reloading while preserving the state of the running system in Common Lisp? Yes. > I'm genuinely curious, I kind of had this impression that it was a feature fairly unique to Erlang. It's not. iIRC there's even a version of the JVM with code reloading. What's interesting about Common Lisp is that not only can code be dynamically compiled into the running image but class definit…

> It's not. iIRC there's even a version of the JVM with code reloading. I've seen some info about the JVM implementation, but I could've sworn it wasn't able to preserve state while hot swapping. I haven't dug in to it though, so it's totally possible it handles that. > There are a tonne of features in Common Lisp like this that are geared towards robust, maintainable software. I'm a fan of Lisp in general, though my…

As someone who's written a bit of Common Lisp, I can say that the macros are a pretty awesome feature to use. Common Lisp has the advantage over Clojure and Scheme that the SBCL compiler is incredibly fast; it can come close to C#/F# on Mono for some tasks, in spite of Lisp being a dynamic language. It also compiles code and expands macros much faster. It's got more power than the other lisps, but it's also less elegant, so make of that what you will.

Re: The Erlang Shell

#44

Post by lispm »

bitwalker wrote: post #8
rurban wrote: post #4

Oh nice. They have now almost a Common Lisp environment. Getting closer to Greenspun's tenth rule.

Is it actually possible to do hot code reloading while preserving the state of the running system in Common Lisp? I'm genuinely curious, I kind of had this impression that it was a feature fairly unique to Erlang.

One loads and replaces incrementally in Lisp.

Re: The Erlang Shell

#45

Post by pron »

bitwalker wrote: post #16
agentultra wrote: post #12

Earlier quoted context omitted.

> Is it actually possible to do hot code reloading while preserving the state of the running system in Common Lisp? Yes. > I'm genuinely curious, I kind of had this impression that it was a feature fairly unique to Erlang. It's not. iIRC there's even a version of the JVM with code reloading. What's interesting about Common Lisp is that not only can code be dynamically compiled into the running image but class definit…

> It's not. iIRC there's even a version of the JVM with code reloading. I've seen some info about the JVM implementation, but I could've sworn it wasn't able to preserve state while hot swapping. I haven't dug in to it though, so it's totally possible it handles that. > There are a tonne of features in Common Lisp like this that are geared towards robust, maintainable software. I'm a fan of Lisp in general, though my…

BTW, a very Erlangish actor system, complete with hot code swapping (while preserving state), is available for Clojure and is called Pulsar (all open-source): http://docs.paralleluniverse.co/pulsar/

Re: The Erlang Shell

#46

Post by tel »

tel wrote: post #14
lostcolony wrote: post #10

Earlier quoted context omitted.

What were your thoughts re: Dialyzer?

It's nice and once I learned how to use it I tried to be very consistent with it. The success types provide good documentation, but I found that the types still felt very flat. The fundamental component of Erlang abstraction is the process and the process tree, so your types reflect that and don't end up composing well.

(To clarify: rather your types end up composing much like messages between actors. That's a very fine way to compose things, but it's still just one way)

Re: The Erlang Shell

#47

Post by klibertp »

e_proxus wrote: post #35
phamilton wrote: post #13

I'm another recent Erlang convert (though I'm still trying to get used to the paradigm and ecosystem). There are a few concepts that haven't quite clicked for me. I come from a Rails background. While Erlang's hot code reloading and the ability to attach to running nodes is cool, I am not quite able to connect the dots on how this is useful. In Rails, a process is short-lived by design (the lifecycle of a request). A…

If you want to develop web pages, don't do Erlang. If you want to do web services, do Erlang. I've used both Ruby (Rails) and Python (trying to do concurrency with tornado, greenlets, gevent) and they just fell flat. You can do it, but it is incredibly messy and unstable (because there's so much work involved). In Erlang, you would typically answer a web request in a new actor every time. Just as in Rails, running fo…

> If you want to develop web pages, don't do Erlang.

I'm not sure I agree. There's https://github.com/ChicagoBoss/ChicagoBoss and quite a few other frameworks (https://github.com/ChicagoBoss/ChicagoBoss/wiki/Comparison-o...) and there's also Elixir and some frameworks for it (https://github.com/dynamo/dynamo).

It's of course nowhere near the ease of development of simple web pages in Django or Rails, but it's not like you need to reinvent everything from scratch either. And you gain ability to scale almost without any effort. It's a tradeoff, of course, and using Erlang for every web page you build from now on would be probably an overkill. But there are web sites which are not services yet, which could still benefit from Erlang greatly. And I think (and hope) that the initial overhead of Erlang will get smaller and smaller over time as new frameworks emerge and that someday deploying your blog on top of Erlang will become viable choice :)

Re: The Erlang Shell

#48

Post by klibertp »

logicchains wrote: post #43
bitwalker wrote: post #16

Earlier quoted context omitted.

> It's not. iIRC there's even a version of the JVM with code reloading. I've seen some info about the JVM implementation, but I could've sworn it wasn't able to preserve state while hot swapping. I haven't dug in to it though, so it's totally possible it handles that. > There are a tonne of features in Common Lisp like this that are geared towards robust, maintainable software. I'm a fan of Lisp in general, though my…

As someone who's written a bit of Common Lisp, I can say that the macros are a pretty awesome feature to use. Common Lisp has the advantage over Clojure and Scheme that the SBCL compiler is incredibly fast; it can come close to C#/F# on Mono for some tasks, in spite of Lisp being a dynamic language. It also compiles code and expands macros much faster. It's got more power than the other lisps, but it's also less eleg…

> I can say that the macros are a pretty awesome feature to use

Erlang has them in the form of parse transforms and Elixir has them too and makes them easy to use. Not as easy as sexp based languages, but almost.

Re: The Erlang Shell

#49

Post by felixgallo »

alcari wrote: post #33
shanselman wrote: post #22

Earlier quoted context omitted.

Why should you not do it often?

If you find yourself often having to manually access the console on a production system, clearly something in your testing and deployment methodology is horribly wrong.

In erlang it's not idiomatic to do it super often, but when a bug does pop up in production, as they tend to do with every known program, it's pretty sweet to be able to look at it and fix it without dropping state or connections.

Re: The Erlang Shell

#50

Post by agentultra »

bitwalker wrote: post #16
agentultra wrote: post #12

Earlier quoted context omitted.

> Is it actually possible to do hot code reloading while preserving the state of the running system in Common Lisp? Yes. > I'm genuinely curious, I kind of had this impression that it was a feature fairly unique to Erlang. It's not. iIRC there's even a version of the JVM with code reloading. What's interesting about Common Lisp is that not only can code be dynamically compiled into the running image but class definit…

> It's not. iIRC there's even a version of the JVM with code reloading. I've seen some info about the JVM implementation, but I could've sworn it wasn't able to preserve state while hot swapping. I haven't dug in to it though, so it's totally possible it handles that. > There are a tonne of features in Common Lisp like this that are geared towards robust, maintainable software. I'm a fan of Lisp in general, though my…

In no specific order:

1. Configurable compiler. You can tell the compiler where it's safe to ignore types and where to be strict about types. For the battle-hardened critical sections of code turning off run-time type checking can be a pretty big win performance-wise.

2. Extensible compiler. Macros are like tiny compilers. It's possible to create DSLs for the programmer to work with a problem in terms of nouns and verbs that make sense for their task while still compiling to VHDL for your application. Common Lisp becomes the substrate on which you build the language you need to solve your problem.

3. The best error handling system I've seen in any language. Signals, handlers, and restarts allow higher-level code to choose an appropriate strategy for recovering from errors under various conditions without losing state and restarting the computation.

4. Top-class introspection tools. The JVM has been able to do some of this stuff for a while but with CLOS and the error handling facilities available Common Lisp makes this so much better. You can inspect any object, change values on slots, trace any function, step through the entire stack, and recompile code into the running image. There are nice tools written on top of these facilities which provide some of the most elegant debugging sessions I have ever encountered. Stop your program? Why? I can connect to a running image, inspect the running program interactively, and compile the fix into it without restarting. Even over SSH directly from my IDE.

And that's just the stuff in the specification. I'm a fan of the newer ASDF systems for defining systems and their dependencies (implicit file-system structure for defining module composition? No thank you). There are some really solid libraries available (iolib, bordeaux-threads) and a very nice FFI for interfacing with alien code. And various implementations provide interesting extensions depending on what you need. Clozure Common Lisp, for example, has really good native Cocoa bindings. SBCL has a very slick compiler for generating fast code. Most of them provide threading extensions and there are libraries which abstract away the differences if you're writing a library that depends on threads.

Post reply on HN