There are two levels to power that I've identified in anti-authoritarian groups. The first is the making and enforcement of the rules, and the second is the meta-game in which people get into positions of making our enforcing rules.
It sounds like your community has figured out the first kind of power somewhat, but I urge you to consider carefully the second form of power.
It's likely that your community, like many, is currently run by its founders, people who are successful leaders because they enforce rules that people want to follow anyway--people have voted them into power with their feet (if they didn't like you as a leader, they would leave).
But what happens to the community when you leave or die? Often a member of the community steps up to take the reins, and while that person might understand the goals of the organization, they might not understand how to implement those goals, especially when implementing those goals requires setting aside their own basic human urges and ego. Almost no organization survives the first few changes of leadership in a positive form. You may think you're okay with this, that your organization can end with you, but keep in mind that it may live on and cause more damage than it ever did good.
The solution is to create rules which limit your own power and give the community the ability to enforce those rules on you. That way your community has the power to survive a transition of power.
I agree, but only because questions so often go bad in titles that I now avoid them on principle. This is a rare situation where the question asked in the title is answered in a non-obvious way, so I can't actually point to anything wrong with titling this with a question.
If you came to that conclusion within a few seconds at the beginning of this article, your diagnostic criteria is basically "uses drugs -> has drug problem". A stopped clock is right twice a day, but is never useful.
I didn't have a plan for replacing the social contact of Facebook when I quit. I lost contact with a lot of people. But it turned out that most were acquaintances, not friends, and I could do without them. My acquaintances now are the people I see every day, the doormen and baristas I meet but don't become close with, and I find this means my acquaintances include more variety of people as a result. And the real friends, I've kept in contact with; there are only maybe 10, so it's not hard to text them occasionally.
Yes. Your experience might be different, but I have a limited capacity for the number of people I can remember basic facts about to be polite, so when I was keeping track of 100+ people on Facebook I didn't have the mental space to keep track of people who I met in my day-to-day.
>> Your Erlang program should just run N times faster on an N core processor
> But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever.
You've made two claims, one irrelevant and one false:
1. only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.
2. it's trivial to write a program that's faster in X language I'm not sure how toot define trivial, but I've yet to find a language that can communicate between threads as performant-ly. Even languages like Clojure which use similar thread semantics can't do what Erlang can because the underlying threads aren't as lightweight. Spinning up a million threads in Erlang isn't even unusual, whereas in any of the languages you mention it's either crippling-ly slow (Python or Java) or very difficult to synchronize (C most, but Python and Java aren't easy).
I've shipped Erlang code and spoken at Erlang events and even I don't believe that every program in Erlang is embarrassingly parallel. There are very real limits on what you can do.
Erlang has never been a language about amazing performance. It's been about an environment and library that delivers amazing distributed concurrency with shockingly little effort.
This is an amazing accomplishment and should not be undersold. In making unsupported claims about how Erlang has magical parallelism sauce that somehow ignores Ahmdal's law we ignore the real benefits for a fiction.
>only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized.
OK. Not an Erlang user, but I can't let this statement go.
I've studied parallel numerical algorithms. Many/most of them will involve blocking because you're waiting for results from other nodes.
If you're saying Erlang has somehow found a way to do those numerical algorithms without having to wait, then I'd love to see all those textbooks rewritten.
I'm not devishard, but I parsed his statement slightly differently. He's not saying that Erlang makes things parallel magically. Rather, he's saying that Erlang forces tasks that /could/ be parallel to be parallel by default. Thus, Erlang will tend to maximize the sections of your program that are run in parallel compared to other languages.
Not really. Think about every object you'd have in Java that's being passed around your system. Now imagine each of those objects are their own processes and you're passing around references to them.
Just on that one case, you've taken huge chunks of a linear execution pattern and parallelized it. Now make that your norm and amplify it to everything. Now realize that the message passing allows this mode of operation to spread each part of this workload over not only more cores but more machines across the network.
And then realize that you can deploy updates to this codes individual parts while other parts continue running without taking down the whole system.
None of what you said will prevent the need for waiting for the majority of numerical algorithms.
No one's disputing Erlang's prowess at parallelism. What the critic in this thread was saying was that you can only get Nx speedup on an N core processor for a limited set of algorithms. Most parallel algorithms will not fall in this category. Amdahl's law is a general truth - it doesn't matter what your architecture/language is. There is nothing special about Erlang that will make any parallel algorithm scale linearly with nodes.
I'm interpreting "embarrassingly parallel" to mean that it's obvious the task can be parallelized, and I'm saying that many tasks where this isn't obvious in a more serial language are obvious in Erlang.
No, I'm not claiming Erlang breaks Amdahl's Law. I'm claiming that Amdahl's Law applies less often than people think it does.
The prescheduler caps the execution window for anything that would block. If one piece of the system would take a long time to finish, it doesn't interfere with the other parts of the system completing their work on schedule. That one blocking piece will finish more slowly, but ever other moving part in the system will keep responding as expected.
>If one piece of the system would take a long time to finish, it doesn't interfere with the other parts of the system completing their work on schedule. That one blocking piece will finish more slowly, but ever other moving part in the system will keep responding as expected.
That's how it works in pretty much any language that supports message passing. I used to do MPI programming in C. Nothing you said is not true for MPI in C. Later I did some MPI in Python. True there as well. If you have MPI in any language, it is true for that language.
My understanding is that those languages rely on cooperative scheduling within a thread, meaning that the running code has to relinquish control to the scheduler. Threads themselves are prescheduled at the OS layer but OS threads are much heavier and limited in how many can be running. A Java thread is 1024kb for example, compared to an Erlang process that's 0.5kb.
> almost every program is embarrassingly parallel in Erlang
I can't agree with that, and it's key to my point. There are some problems which we just don't know how to make embarrassingly parallel. Take something classic like mesh triangulation or mesh refinement. Nobody knows how to make those embarrassingly parallel. If you write it in Erlang, it's still not going to be embarrassingly parallel. And it won't scale linearly to N times faster on N cores no matter which language you write it in.
So it's just not true to say that any Erlang program should scale linearly. If nobody on earth knows how to make mesh refinement scale linearly, how will Erlang do it?
Maybe you mean you wouldn't choose to write those programs in Erlang? Well then I think it's a meaningless claim to say Erlang will linearly scale your program, but only if it is a program which is naturally linearly scalable anyway. Erlang hasn't helped you do anything there so why make a claim about it?
WTF. How do you turn a problem which cannot be reduced into parallel sub-components into an Erlang program then? Are there just a huge class of computations that cannot be done with Erlang? Of course not.
> I've yet to find a language that can communicate between threads as performant-ly.
Minor nitpick: Erlang uses processes, not threads. Your comment doesn't explicitly say that Erlang uses threads though, so perhaps I'm being overly pedantic.
It's not "removing a possible value from your map", it's having your type system explicitly check that you're handling the edge case at compile time. This works in practice in a wide variety of languages.
Instead of responding to the fact that JavaScript:
1. Has no adequate threading model.
2. Has no reasonable type system.
3. Has better alternatives on the server side.
...you're making it personal, and about the people. Look at your post; you're just accusing the critics of Node of feeling "intellectually superior". That's just an ad hominem attack. And you think that critics want you to rage quit the internet and give up? No, that's not what critics of Node want. Or at least, that's not what I want.
What I want is for people to either acknowledge the problems with Node and fix them (unlikely), or start using better alternatives on the server side, and start investing more in WebAssembly and langauges targeting WebAssembly, so we don't have to use JavaScript any more. I want this because as long as Node/JavaScript are around, I have to either deal with those horrible tools, or not take those jobs.
This isn't about feeling superior, it's about improving my life by using tools that aren't godawful.
1. For an async-first environment, which node mostly is, lack of threading is hardly an issue. Only threading node should ever have is the web worker w/ shared memory & atomic ops that’s already going into the Web Platform[1]. I say this is an advantage.
2. Typescript is great, it even has strict null checking via union types. Way better than the half-hearted attempt at optional typing you’ll find in Python 3. So if you think Python is a good ecosystem, then node is miles better. Sure, it’s not Scala, but on the other hand interop w/ Javascript and Web Platform is seamless. It’s a trade-off, but one that I think is very much worth taking. Also it compiles in seconds, not hours.
3. You can share code w/ client which is actually useful considering web app logic is moving client-side. See: React.
4. WebAssembly is nowhere ready. No idea if using it/tooling/debugging will be any good for anything other than what emscripten enables right now. It’s a very risky investment to be considering that early.
Even if you think WebAssembly will pan out, the languages that will target it already target Javascript. It’s just alternative bytecode, really.
2. JS's duck typing is thought to be a "feature" to some and a
"bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]"
Process spawning and threading are two different but related mechanisms. The former is much more expensive and hard to use with optimization techniques like pooling. It also forces message passing for IPC rather than shared memory.
> 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]"
Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer.
Not that this should be necessary, but it'd actually be pretty simple for a compiler to fix #2: transform `const i: int = 3;` into `var i = new Int32Array([3]);` and change future references from `i` to `i[0]`.
No clue what the performance implications would be for really heavy uses of this, but it'd at least be a workable solution if you absolutely required a true integer type at run-time.
asm.js has valid, correctly-behaving integers, and asm.js works correctly on non-asm.js-aware implementations, so the lack of a native integer doesn't seem like a problem.
The emitted code might have lots of "|0"s in it, but I don't see many people complaining about the beauty of their C compiler's generated object code and the lack of native anything-other-than-integers.
> The emitted code might have lots of "|0"s in it, but I don't see many people complaining about the beauty of their C compiler's generated object code
What are the performance implications of that? It's basically adding an extra operation. Also, having been one to dive into intermediate assembly from time to time, there certainly are people who complain about the obtuseness of object code. Particularly since the generated object code is (out-of-order execution notwithstanding) how the CPU is going to actually execute the instructions.
> the lack of native anything-other-than-integers
Um, what? C has native floating-point types on every platform with an IEEE-754-compliant FPU, and probably on some that don't as well. Pointers are also not integers, though bad programmers frequently coerce them into such because most compilers will let them.
Regarding "|0", there are absolutely no performance implications. An ASM.js optimising compiler will recognize these code patterns and interpret them completely differently (it will not execute a bit OR operation, and instead will only treat |0 as a type hint)
There are certain classes of programming and mathematics that really need integers such as cryptography and fields that would need big number libraries.
That's totally valid, but they shouldn't use Node.js if that's a mission critical part of the project. Nobody is saying that Node.js is the holy grail, but I see that expectations are that high.
I'll bite on this. Javascript's type system is with no question my favorite part of it! JS's object model is incredibly powerful, which is why ES6 classes are implemented basically as syntax sugar, and why so many languages can be transpiled to Javascript.
I also don't think that the lack of threading is as much of a problem as you might think it is. For one, it means you can sidestep a lot of the data ordering problems that you get in a threaded environment.
There's no question that Javascript has shortcomings, but so many of the problems that happen in Javascript come from people treating it like Java, when it's a lot more like Lisp. In many ways, the architecture of Javascript revolves around a very simple, powerful object model in a way that's tough to parallel in most other languages.
I'm guessing he mean't static type system. This is the formal meaning of "type" in programming language theory. What you describe is a system of runtime tags.
> Look at all this horrible code! So sad that all these people are not as smart as me. Look at this horrible language! So sad the people that created it are not as intelligent as me!
It's not about being smarter; smart people are a dime a dozen. It's about the fact that what happens in the industry happens to all of us. When a large chunk of the industry adopts callbacks as their threading model, that means I have to either work with their horrible threading models, or not take those jobs.
Don't psychoanalyze people who you disagree with; that's just an ad hominem attack.
> Really? There is no more "problem" with Node.js than there is a "problem" with any other platform. There is no more problem with JavaScript/ES-(name your flavor) than there is with any programming language. Different languages are different. Different platforms are different. Of course every system has its own problems. Sometimes people who appreciate them call these "tradeoffs" or the superior types call them idiotic.
This is the favored defense of people whose favored languages/tools are under attack. But this is absolutely not a tradeoff. A tradeoff is when you make a choice that has some downsides, but you get something for it.
With JavaScript in the browser, the tradeoff is clear--you use this shitty awful language and you get to run your code on the browser, because that's pretty much the only reasonable way to run your code in the browser right now. There are alternatives (TypeScript, CoffeeScript) but then you're limited to a smaller community with fewer resources.
But with JavaScript on the server, there's no tradeoff. You use this shitty awful language and you get... a shitty awful language. You don't get a reasonable threading model, you don't get a reasonable type system. You don't get anything you couldn't get from another language.
It's not a tradeoff, it's just a bad choice.
> As much of a pile of hot steaming code as it is, Babel as an idea (AKA transpiling one language to another) is pretty cool. Of course you can do this in other places but its featuring prominently in the JS community leading to an interesting result. The language and its features become configurable, easy to adapt and change and evolve over time and suit to your liking. This is interesting!
Interesting, yes, and useful. But there's really no reason this had to be written in JavaScript, and the code would likely be a lot less of a "pile of hot steaming code" if it were written in a more reasonable ecosystem.
> Of course there are lots of negatives, lots of horrible code, lots of mistakes happening.
The problem isn't that there is bad code, it's that there isn't any good code. If you needed to write a server-side program and you chose JavaScript, your code is bad and you should feel bad. It's literally impossible to write good server code in JavaScript because it doesn't provide adequate types or threading primitives. It would be different if there weren't alternatives (like in the browser), but there are alternatives which are better.
