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

Why the Cool Kids Don't Use Erlang [video]

youtube.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Why the Cool Kids Don't Use Erlang [video]

#61

Post by hackles_raised »

RogerL wrote: post #24
themartorana wrote: post #9

Earlier quoted context omitted.

In an absolutely brilliant video[0] on Microsoft's Channel 9, called "Panel: Systems Programming in 2014 and Beyond" (with Charles Torre, Niko Matsakis, Andrei Alexandrescu, Rob Pike, and Bjarne Stroustrup), Rob Pike makes a comment (I'm paraphrasing) that in making Go, he realized that testing in general and the idea of TDD was due to dynamic languages not having any compile-time checking. The panel seemed to agree.…

Kent Beck invented TDD while programming in Smalltalk, having recalled reading a paper on using TDD with punched tape. I think Rob Pike is confused in his history/assertion.

He also pioneered XP while working on C3, a project shutdown in 99. As I recall the customer representative quit through burnout and stress and couldn't be replaced.

Look, most of us dig agile, but all you really need is the four tenets of the agile manifesto.

When someone says agile, consider the source, the best practitioners aren't publishing books, they are producing working systems every day.

I used to work at a company, let's call it Beutche Dank, I was part of a program that has spent millions of euro developing specifications, that amounted to little more than power point presentations. One of the Business analysts, nice chap, says to me, "Your going to deliver this using Agile right?". He didn't realize that they had already compromised the delivery, but they had followed every instruction of the 'agile consultant' they had hired, they just forgot to include the people that really add value, the development team. You either understand this stuff or you don't.

We need project managers, but they should not outnumber the engineers, we need engineering managers but they better be engineers. If you have directors of technical programs who are not technical, get rid of them.

It is the guys and gals writing the code that are of the most value to you, make everyone who deems themselves above these people justify themselves.

OK enough orthogonal ranting, got to go write me some tests, oops I mean compile my code.

Re: Why the Cool Kids Don't Use Erlang [video]

#62

Post by jeffdavis »

noelwelsh wrote: post #45
jallmann wrote: post #40

Earlier quoted context omitted.

> Are you sure that's even possible? No. Simon Marlow and Philip Wadler tried to make a type system for Erlang and couldn't do it [1]. And if they couldn't do it... well, it's a very hard problem, for many of the reasons you cited. From what I understand, the general consensus is that Erlang's dynamic types are a small price to pay for the flexibility and features afforded by the runtime. To be fair, what makes Erlan…

I don't believe that one should attempt to copy the Erlang model in a typed language (and this is one reason I don't particularly like Akka). There are many facilities, some noted in other comments, that make statically typing Erlang difficult but I don't believe most of these are necessary. Can send any message to any actor? Probably a bug. Hot code swapping? Never had a need for this. Restarts are fine. Any distrib…

> A restart is just another crash.

So let's say you restart, and the process comes up with new code, including new type signatures for the messages that the process is expecting to receive. How (and when) does the compiler check those new type signatures against already-running processes on another node?

Maybe there's some very sophisticated way of managing versions using subtyping to ensure that a new version always accepts a superset of the messages that the old version accepted. That sounds like a mess, and I doubt it would actually work.

Even if it did, it's solving the wrong problem. In a massively distributed system, message types are just one small part of a larger problem: protocol integrity. If you send the right message type at the wrong time, or are waiting for a message that never comes, a type system won't do you any good.

So to make this all actually work, you need to incorporate some high-level declarative protocol specification into your distributed versioning static type system (with subtypes). Perhaps not impossible, but wow, that would be some serious research effort; and then a lot of engineering effort to make it practical.

I could sum this up by saying that all static type systems seem to revolve around one very simple protocol: the function call. The erlang type system can handle that just fine. But erlang also brings a lot of other protocols to the forefront, and we don't know how to typecheck them all. Other languages punt on these problems so that they can call the type system "sound", but that doesn't make the problems go away.

Re: Why the Cool Kids Don't Use Erlang [video]

#64

Post by angersock »

jeffdavis wrote: post #62
noelwelsh wrote: post #45

Earlier quoted context omitted.

I don't believe that one should attempt to copy the Erlang model in a typed language (and this is one reason I don't particularly like Akka). There are many facilities, some noted in other comments, that make statically typing Erlang difficult but I don't believe most of these are necessary. Can send any message to any actor? Probably a bug. Hot code swapping? Never had a need for this. Restarts are fine. Any distrib…

> A restart is just another crash. So let's say you restart, and the process comes up with new code, including new type signatures for the messages that the process is expecting to receive. How (and when) does the compiler check those new type signatures against already-running processes on another node? Maybe there's some very sophisticated way of managing versions using subtyping to ensure that a new version always…

So, maybe that's an interesting thing you've got there, right?

Time-dependent type systems--and that kind of makes me think of state machines. Not sure if there's anything there, but maybe there is. Maybe we can prove that type systems that are time-dependent have certain computability properties?

Re: Why the Cool Kids Don't Use Erlang [video]

#65

Post by je42 »

wtetzner wrote: post #60
je42 wrote: post #19

Earlier quoted context omitted.

True, however. Test suits tests things that a type system never is able to test. In general, if you reach a non trivial size of code you have to have unit tests in order to stay productive and speedy at a high quality level. A type-system only speeds you up in the beginning.

Tests are code and need to be maintained. Type systems remove the need for certain classes of tests that would otherwise need to be written and maintained. Just because you need to write other unit tests doesn't mean it's free to write unit tests to check types.

I didn't say it is 'free'. I specifically talk about productivity.

Re: Why the Cool Kids Don't Use Erlang [video]

#67

Post by mafribe »

platz wrote: post #44
NotableAlamode wrote: post #38

Earlier quoted context omitted.

Typing a the message-passing part of a language like Erlang is very much an open research problem. I spoke about this at length with the session type community. They are thinking about this, but it's at least a decade away.

Isn't Akka planning to add types w/ typed akka? If they can pull that off some subset of Erlang should be doable as well

From a superficial reading I think what they are doing is quite simplistic. Basically they want to provide typed channels, e.g. ActorRef[T] that only accepts T messages. That's the easy part. What you really want is something like type-based guarantees that a the interaction between actors cannot get stuck. Achieving this is fraught with difficulties.

Re: Why the Cool Kids Don't Use Erlang [video]

#68

Post by platz »

mafribe wrote: post #67
platz wrote: post #44

Earlier quoted context omitted.

Isn't Akka planning to add types w/ typed akka? If they can pull that off some subset of Erlang should be doable as well

From a superficial reading I think what they are doing is quite simplistic. Basically they want to provide typed channels, e.g. ActorRef[T] that only accepts T messages. That's the easy part. What you really want is something like type-based guarantees that a the interaction between actors cannot get stuck. Achieving this is fraught with difficulties.

no true scottsman? This reminds me of arguments against STM, which efforts previously failed because they tried to enforce it across the whole system. The way forward was to demarcate clearly which vars were in STM and which weren't, and it is very useful - note doesn't solve the "hard theory cs" formulation of STM.

Just because typed ActorRef aren't as hard as implementing this other property which has some other "hard cs" property, does that really devaule the utility of typed ActorRefs?

I admit I'm not sure exactly if 'the interaction between actors cannot get stuck' property is something that is an existing pain point, or something that would be introduced as a result of typed ActorRefs

Re: Why the Cool Kids Don't Use Erlang [video]

#69

Post by mafribe »

platz wrote: post #68
mafribe wrote: post #67

Earlier quoted context omitted.

From a superficial reading I think what they are doing is quite simplistic. Basically they want to provide typed channels, e.g. ActorRef[T] that only accepts T messages. That's the easy part. What you really want is something like type-based guarantees that a the interaction between actors cannot get stuck. Achieving this is fraught with difficulties.

no true scottsman? This reminds me of arguments against STM, which efforts previously failed because they tried to enforce it across the whole system. The way forward was to demarcate clearly which vars were in STM and which weren't, and it is very useful - note doesn't solve the "hard theory cs" formulation of STM. Just because typed ActorRef aren't as hard as implementing this other property which has some other "h…

I didn't say it wasn't useful. It is. But it's checking essentially a sequential property: a sequential actor is using a channel in a consistent way. What e.g. the session type community is aiming at are properties of concurrent computation, such as linear channel usage which depends on the behaviour of multiple processes.
Post reply on HN