9 ms·

Ryan Dahl addresses comments on his recent rant

60 points by collypops 15y ago

skrebbel 15y ago
His first point here really hit home for me. Indeed, people like Ryan Dahl hate software for us so we don't have to.
rphlx 15y ago
POSIX is beautiful. d-bus != POSIX.
- slaughterhaus 15y ago
  why does he keep mentioning dbus and glib? I havent been following node.js development and last time i checked in, node was written in c++.
losethos 15y ago
no posix in LoseThos. no standards--clean slate.
cageface 15y ago
Can you not imagine a world where one could operate in native code without the concept of volatile variables? Sometimes you want the compiler to do its best with register optimizations and code ordering etc and sometimes you have to explicitly tell it to go to memory every time. You could layer an abstraction over this but some people would still need to burrow under it. The point of working at the C/C++ systems layer is you have this control but also the responsibility that comes with it.
- rapala 15y ago
  Or maybe he is hoping for something more elegant than plain shared memory, at the hardware level.
  - bad_user 15y ago
    There are 3 problems with this statement that I can see. 1) people haven't even agreed on the best technique for utilizing multiple cores, or heck, on the difference between concurrency and parallelism, and quite the contrary, I think the x86 architecture is too smart and carries a lot of baggage compared to the elegance and simplicity of pure RISC processors 2) most of the time you're not really working directly with hardware -- like, for example modern kernels do not allow you to access the memory of another process directly, and that value that you wanted to save in RAM may end up in a swap file on your hard-disk. 3) what hardware does have is a separation between hard-disk, RAM, L2 cache, L1 cache and CPU registers. In a perfect world there would only be one type of memory, unfortunately that would be too expensive and without much benefit versus the current state of the art. For maximum performance (which is required in many instances) you do have to know about the difference between these multiple layers of memory and take appropriate action, even though many times this is abstracted away from you. The problem with "volatile" is different in nature - the behavior of volatile is not really portable and in practice it is also useless as higher-level APIs, like POSIX threads, do have better atomic and fence semantics that are more portable. Basically "volatile" was added in for good measure and it is now a legacy generating lots of problems.
    - cageface 15y ago
      Volatile is useful in implementing things like lock-free queues, at least on X86. For some real-time applications you can't afford to take a kernel lock or spin on a spinlock.
- rgbrgb 15y ago
  Is that a NO? I think Ryan is just saying that we should continue to question the standards and architectures that have become deeply rooted in our systems. Yeah, posix is the best we have but it's relatively young and there is so much room for new ideas. Real innovators learn current paradigms and limitations, then forget and destroy them.
antirez 15y ago
I agreed with the general ideas in its original rant, but IMHO the problem is not the POSIX API nor the C language (including "volatile"), those are both well designed and simple stuff, for the most part (the C standard library is horrid unfortunately). IMHO most of the problems are about the other layers: tricks you need to know about the operating system implementation of POSIX, or dynamic library loading, all the subtle things with different binaries formats, and so forth. A few of this things are easy to solve, for me it is impossible to understand how the libC can be in this sad state, and how the replacements and improvements to it like glib are also a mess. If one day I'll not hack on Redis anymore my mission will be, assuming I'll have another way to pay my bills, to create a replacement for the C standard library. While we are at it, not C++ nor Objective C are the final words on making C better and more comfortable to use (but I think the latter is much better than the former at it). This is surely an area where there is a lot to do. Unfortunately "D" is diverging so much form C that it should completely replacing it to get mainstream: very unlikely given the role C is playing today and the code base. A backward compatible improvement is still what we need I think.
- kmm 15y ago
  What is so bad about the C standard library? What would you change? I find it lacking a lot of essential features -- can you believe strdup isn't part of the C standard? -- but simplicity and minimalism has always been C's strongest point.
  - zeugma 15y ago
    Lack of real string type. String manipulation is a pain and you have to allocate everything by yourself which result in inefficient and dangerous code.
    - apaprocki 15y ago
      Any code can be inefficient if performance wasn't a concern while writing it. I'd say in that case C string manipulation is more efficient by design because you see how many times you are copying something around. When things are abstracted away in something like std::string then you can wind up with code that creates multiple unnecessary copies by accident (e.g. forgetting a '&' to take a reference). Yes, it is more dangerous, but that can be a tradeoff with performance. For example, assume you have a std::hash_map<std::string, int>. There is no way to insert into this without one string copy (C++11 changes this to make zero-copy possible).
sodiumphosphate 15y ago
"""We should program as if we were perched atop of 20 floors of bamboo scaffolding - because that's the state of the Unix userland.""" Genius.
- deleted 15y ago
  [deleted]
- polynomial 15y ago
  Bamboo has greater tensile strength than steel, and it withstands compression better than concrete.[1] Not that I'm trying to imply anything by that. [1] (Bamboo's tensile strength is roughly 28k/psi versus steel's 23k.)
MostAwesomeDude 15y ago
I wonder if perhaps he doesn't realize that Ted Dziuba is not a fan of Twisted either. He's generally recognized as a very belligerent, assertive personality, in the same vein as Zed Shaw, and you have to have a certain amount of thick skin when reading his commentary. That said, the fact that Node doesn't provide the tools necessary to defer blocking JS code to a thread does pose a problem for these sorts of situations. Apparently (and correct me if I'm wrong; I'm not a Node expert!) Node won't let you run JS in any thread which is not the main thread. Twisted does let you run Python in non-main threads with the deferToThread()/callFromThread()[1] functionality. I also agree with him about JS being a poor language for server-side work, but that's because I don't think JS's object model is well-suited to large, interface-driven/service-driven applications, and that isn't really a gripe with Node. [1] http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorThreads.html http://twistedmatrix.com/documents/current/api/twisted.inter... and http://twistedmatrix.com/documents/current/api/twisted.internet.threads.html http://twistedmatrix.com/documents/current/api/twisted.inter... document threading in Twisted.
- ehsanu1 15y ago
  What's wrong with JS's object model? It's certainly more flexible than say Java's. If the problem is the flexibility, do you feel the same way about Ruby?
  - MostAwesomeDude 15y ago
    Implicit coercion is always iffy, and JS's coercion rules are broken along the same lines as PHP's, where == and === have to be carefully managed. There's no actual identity check, only two different strengths of equality. Booleans coercing to strings instead of strings coercing to booleans is weird. There's no operator overloading. Sometimes this is useful, in languages which have it. Notably, there's no way to override how equality, coercion, and arithmetic are handled. There are no metaclass operations. The type model is incomplete; it's not possible to create new first-class types or query type information respecting inheritance. For that matter, there's no blessed way to have inheritance. Makes sense since the language doesn't have classes per se, but it's kinda annoying in an object-based language to not be able to actually examine objects in a unified way. Those are the ones off the top of my head. There are others, but they're matters of opinion.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]

60 points by collypops 15y ago

skrebbel 15y ago

His first point here really hit home for me. Indeed, people like Ryan Dahl hate software for us so we don't have to.

rphlx 15y ago

POSIX is beautiful. d-bus != POSIX.

slaughterhaus 15y ago
why does he keep mentioning dbus and glib? I havent been following node.js development and last time i checked in, node was written in c++.

losethos 15y ago

no posix in LoseThos. no standards--clean slate.

cageface 15y ago

Can you not imagine a world where one could operate in native code without the concept of volatile variables? Sometimes you want the compiler to do its best with register optimizations and code ordering etc and sometimes you have to explicitly tell it to go to memory every time. You could layer an abstraction over this but some people would still need to burrow under it. The point of working at the C/C++ systems layer is you have this control but also the responsibility that comes with it.

rapala 15y ago
Or maybe he is hoping for something more elegant than plain shared memory, at the hardware level.
- bad_user 15y ago
  There are 3 problems with this statement that I can see. 1) people haven't even agreed on the best technique for utilizing multiple cores, or heck, on the difference between concurrency and parallelism, and quite the contrary, I think the x86 architecture is too smart and carries a lot of baggage compared to the elegance and simplicity of pure RISC processors 2) most of the time you're not really working directly with hardware -- like, for example modern kernels do not allow you to access the memory of another process directly, and that value that you wanted to save in RAM may end up in a swap file on your hard-disk. 3) what hardware does have is a separation between hard-disk, RAM, L2 cache, L1 cache and CPU registers. In a perfect world there would only be one type of memory, unfortunately that would be too expensive and without much benefit versus the current state of the art. For maximum performance (which is required in many instances) you do have to know about the difference between these multiple layers of memory and take appropriate action, even though many times this is abstracted away from you. The problem with "volatile" is different in nature - the behavior of volatile is not really portable and in practice it is also useless as higher-level APIs, like POSIX threads, do have better atomic and fence semantics that are more portable. Basically "volatile" was added in for good measure and it is now a legacy generating lots of problems.
  - cageface 15y ago
    Volatile is useful in implementing things like lock-free queues, at least on X86. For some real-time applications you can't afford to take a kernel lock or spin on a spinlock.
rgbrgb 15y ago
Is that a NO? I think Ryan is just saying that we should continue to question the standards and architectures that have become deeply rooted in our systems. Yeah, posix is the best we have but it's relatively young and there is so much room for new ideas. Real innovators learn current paradigms and limitations, then forget and destroy them.

antirez 15y ago

I agreed with the general ideas in its original rant, but IMHO the problem is not the POSIX API nor the C language (including "volatile"), those are both well designed and simple stuff, for the most part (the C standard library is horrid unfortunately). IMHO most of the problems are about the other layers: tricks you need to know about the operating system implementation of POSIX, or dynamic library loading, all the subtle things with different binaries formats, and so forth. A few of this things are easy to solve, for me it is impossible to understand how the libC can be in this sad state, and how the replacements and improvements to it like glib are also a mess. If one day I'll not hack on Redis anymore my mission will be, assuming I'll have another way to pay my bills, to create a replacement for the C standard library. While we are at it, not C++ nor Objective C are the final words on making C better and more comfortable to use (but I think the latter is much better than the former at it). This is surely an area where there is a lot to do. Unfortunately "D" is diverging so much form C that it should completely replacing it to get mainstream: very unlikely given the role C is playing today and the code base. A backward compatible improvement is still what we need I think.

kmm 15y ago
What is so bad about the C standard library? What would you change? I find it lacking a lot of essential features -- can you believe strdup isn't part of the C standard? -- but simplicity and minimalism has always been C's strongest point.
- zeugma 15y ago
  Lack of real string type. String manipulation is a pain and you have to allocate everything by yourself which result in inefficient and dangerous code.
  - apaprocki 15y ago
    Any code can be inefficient if performance wasn't a concern while writing it. I'd say in that case C string manipulation is more efficient by design because you see how many times you are copying something around. When things are abstracted away in something like std::string then you can wind up with code that creates multiple unnecessary copies by accident (e.g. forgetting a '&' to take a reference). Yes, it is more dangerous, but that can be a tradeoff with performance. For example, assume you have a std::hash_map<std::string, int>. There is no way to insert into this without one string copy (C++11 changes this to make zero-copy possible).

sodiumphosphate 15y ago

"""We should program as if we were perched atop of 20 floors of bamboo scaffolding - because that's the state of the Unix userland.""" Genius.

deleted 15y ago
[deleted]
polynomial 15y ago
Bamboo has greater tensile strength than steel, and it withstands compression better than concrete.[1] Not that I'm trying to imply anything by that. [1] (Bamboo's tensile strength is roughly 28k/psi versus steel's 23k.)

MostAwesomeDude 15y ago

I wonder if perhaps he doesn't realize that Ted Dziuba is not a fan of Twisted either. He's generally recognized as a very belligerent, assertive personality, in the same vein as Zed Shaw, and you have to have a certain amount of thick skin when reading his commentary. That said, the fact that Node doesn't provide the tools necessary to defer blocking JS code to a thread does pose a problem for these sorts of situations. Apparently (and correct me if I'm wrong; I'm not a Node expert!) Node won't let you run JS in any thread which is not the main thread. Twisted does let you run Python in non-main threads with the deferToThread()/callFromThread()[1] functionality. I also agree with him about JS being a poor language for server-side work, but that's because I don't think JS's object model is well-suited to large, interface-driven/service-driven applications, and that isn't really a gripe with Node. [1] http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorThreads.html http://twistedmatrix.com/documents/current/api/twisted.inter... and http://twistedmatrix.com/documents/current/api/twisted.internet.threads.html http://twistedmatrix.com/documents/current/api/twisted.inter... document threading in Twisted.

ehsanu1 15y ago
What's wrong with JS's object model? It's certainly more flexible than say Java's. If the problem is the flexibility, do you feel the same way about Ruby?
- MostAwesomeDude 15y ago
  Implicit coercion is always iffy, and JS's coercion rules are broken along the same lines as PHP's, where == and === have to be carefully managed. There's no actual identity check, only two different strengths of equality. Booleans coercing to strings instead of strings coercing to booleans is weird. There's no operator overloading. Sometimes this is useful, in languages which have it. Notably, there's no way to override how equality, coercion, and arithmetic are handled. There are no metaclass operations. The type model is incomplete; it's not possible to create new first-class types or query type information respecting inheritance. For that matter, there's no blessed way to have inheritance. Makes sense since the language doesn't have classes per se, but it's kinda annoying in an object-based language to not be able to actually examine objects in a unified way. Those are the ones off the top of my head. There are others, but they're matters of opinion.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]