5 ms·

Watch the video and you will understand that/why google chooses sync. development. As to why it's important, you will see eventually, or you can try to figure

by bullen 10y ago

Watch the video and you will understand that/why google chooses sync. development. As to why it's important, you will see eventually, or you can try to figure it out by reading the link again in a couple of months. The brain needs time to understand things that are hidden by self preservation, like how money is created f.ex.

icebraining 10y ago
I understand why Google chooses a synchronous model of development, that wasn't what I said you should explain. If you believe your explanation is crystal clear and complete, and people just need time, then good luck. But I suggest you try reformulating it. By the way, "Money creation in the modern economy" wasn't hard to understand. In my experience, most things aren't, if they're well explained and you have the foundation knowledge. "The brain needs time to adjust" tends to be an excuse used by people selling perpetual motion machines.
- bullen 10y ago
  Ok, so if you understand the creation of money and you understand that google is super good at engineering, can you see the link between those two things? Below is the answer, tip no. 2 to YC: add spoiler tag. They are using their monopoly and benefits (their clients borrowed money at low interest) to build data centers that use lots of cheap finite energy instead of actually trying to innovate. The only energy added to the planet is sunrays, the only way that energy is stored is by photosyntesis, we have consumed millions of years of sunshine in 200 years. If all internet systems where async-to-async you could probably close 10 nuclear power plants immediately. (btw we only have 50 years of uranium left at this rate) Solar and wind to electrivity are net energy negative and require more fossil energy to manufacture than they deliver in their lifetime. Talk about "doing no evil".
  - icebraining 10y ago
    Like I said, you're yet to explain what "async-to-async" actually means in this context. I say this, because I don't think you actually understand what Google means when you write that they're using a synchronous model of development. What they're doing is, quoting from the article, "shifting the burden of managing asynchronous events away from the programmer to the operating system or the thread library". The programs themselves are still asynchronous, it's just that the programmer doesn't have to care. So if you're going to claim that using a synchronous programming model over an asynchronous runtime wastes a lot of energy, you're going to have to (1) explain very well the differences between that model and the one you're proposing and (2) explain how your model wastes less energy. You're also going to have to support the rather extraordinary claim that "[s]olar and wind to electrivity are net energy negative". That myth was already false back in the late 90s, it's quite absurd nowadays. The Energy Payback time of a current solar panel is just a couple of years, depending on how sunny the place you put it is.
    - bullen 10y ago
      You can't move the async without the developer touching it if you want the async to save you IO-wait = be on the socket. You need the async. to be in the network. Async-to-async means your CPU only touches your work when it has to and when the instance is waiting the work is in transit on the network so the CPU can do other things. > In practice, you need two small pools of threads with the same amount of threads as the CPU has cores. And those will pass the "work" back and forth between incoming requests -> outgoing requests and then incoming response -> outgoing response, both arrows indicating a thread to thread handover that will make most programmers faint. (but once the platform is built developers just need to wrap their head around the philosophy and not making that handover work) Async-to-async is the solution for zero IO-wait without context switching problems and scalable to millions of concurrent sockets per machine, not that that's what you want, what you want is a distributed model where many small machines co-operate on a larger task, but that requires async-to-async too. An here you have to try and use any SQL database to see why that fails in a distributed system. etc. etc. I need to write a book and I rather write software to prove my point instead. (if yc had edit after longer duration I would explain this here too later 3rd tip) When a thread is stuck in IO-wait that is pure loss, eventually all sync. systems break due to IO-wait and that means you need overcapacity. The advantage with Async. is that 100% CPU means little to no problem and you can have the system appropriately powered at all times by sharing resources in a distributed sandbox instead of sharding them in virtualboxes/containers. > Sidenote: you need to be able to share memory across threads so forget about programming languages that don't have "real" threads (PHP, Javascript, ruby, python, etc.) Overloads are fun in a async. system, because the CPU just keeps working on the queue that it fundamentally needs (that sync systems have between everything to avoid crashing) and watching the latency go up a bit when the system is overloaded is so much fun when you see the system does not grind to a halt but just churns right through the overload. > Async. is inherently anti-fragile. About solar, you need to remove money and add all energy required to build everything around the solar panel, including the energy required for the person assembling it and even that persons cat food, transport, mining, etc. Otherwise you're only seeing "the tree and not the forest". Energy has no dollar price, you should not be able to buy energy with "nothing". > The dollar does not exist. As an exercise you can read the source, and then when you feel confident enough google: async. processor. My next and last project is to apply async. to a 3D engine, where the rendering/physics is done in two c++ threads, and the scripting in java asynchronously modifies the state for those threads from a third thread.

by bullen 10y ago

icebraining 10y ago

I understand why Google chooses a synchronous model of development, that wasn't what I said you should explain. If you believe your explanation is crystal clear and complete, and people just need time, then good luck. But I suggest you try reformulating it. By the way, "Money creation in the modern economy" wasn't hard to understand. In my experience, most things aren't, if they're well explained and you have the foundation knowledge. "The brain needs time to adjust" tends to be an excuse used by people selling perpetual motion machines.

bullen 10y ago
Ok, so if you understand the creation of money and you understand that google is super good at engineering, can you see the link between those two things? Below is the answer, tip no. 2 to YC: add spoiler tag. They are using their monopoly and benefits (their clients borrowed money at low interest) to build data centers that use lots of cheap finite energy instead of actually trying to innovate. The only energy added to the planet is sunrays, the only way that energy is stored is by photosyntesis, we have consumed millions of years of sunshine in 200 years. If all internet systems where async-to-async you could probably close 10 nuclear power plants immediately. (btw we only have 50 years of uranium left at this rate) Solar and wind to electrivity are net energy negative and require more fossil energy to manufacture than they deliver in their lifetime. Talk about "doing no evil".
- icebraining 10y ago
  Like I said, you're yet to explain what "async-to-async" actually means in this context. I say this, because I don't think you actually understand what Google means when you write that they're using a synchronous model of development. What they're doing is, quoting from the article, "shifting the burden of managing asynchronous events away from the programmer to the operating system or the thread library". The programs themselves are still asynchronous, it's just that the programmer doesn't have to care. So if you're going to claim that using a synchronous programming model over an asynchronous runtime wastes a lot of energy, you're going to have to (1) explain very well the differences between that model and the one you're proposing and (2) explain how your model wastes less energy. You're also going to have to support the rather extraordinary claim that "[s]olar and wind to electrivity are net energy negative". That myth was already false back in the late 90s, it's quite absurd nowadays. The Energy Payback time of a current solar panel is just a couple of years, depending on how sunny the place you put it is.
  - bullen 10y ago
    You can't move the async without the developer touching it if you want the async to save you IO-wait = be on the socket. You need the async. to be in the network. Async-to-async means your CPU only touches your work when it has to and when the instance is waiting the work is in transit on the network so the CPU can do other things. > In practice, you need two small pools of threads with the same amount of threads as the CPU has cores. And those will pass the "work" back and forth between incoming requests -> outgoing requests and then incoming response -> outgoing response, both arrows indicating a thread to thread handover that will make most programmers faint. (but once the platform is built developers just need to wrap their head around the philosophy and not making that handover work) Async-to-async is the solution for zero IO-wait without context switching problems and scalable to millions of concurrent sockets per machine, not that that's what you want, what you want is a distributed model where many small machines co-operate on a larger task, but that requires async-to-async too. An here you have to try and use any SQL database to see why that fails in a distributed system. etc. etc. I need to write a book and I rather write software to prove my point instead. (if yc had edit after longer duration I would explain this here too later 3rd tip) When a thread is stuck in IO-wait that is pure loss, eventually all sync. systems break due to IO-wait and that means you need overcapacity. The advantage with Async. is that 100% CPU means little to no problem and you can have the system appropriately powered at all times by sharing resources in a distributed sandbox instead of sharding them in virtualboxes/containers. > Sidenote: you need to be able to share memory across threads so forget about programming languages that don't have "real" threads (PHP, Javascript, ruby, python, etc.) Overloads are fun in a async. system, because the CPU just keeps working on the queue that it fundamentally needs (that sync systems have between everything to avoid crashing) and watching the latency go up a bit when the system is overloaded is so much fun when you see the system does not grind to a halt but just churns right through the overload. > Async. is inherently anti-fragile. About solar, you need to remove money and add all energy required to build everything around the solar panel, including the energy required for the person assembling it and even that persons cat food, transport, mining, etc. Otherwise you're only seeing "the tree and not the forest". Energy has no dollar price, you should not be able to buy energy with "nothing". > The dollar does not exist. As an exercise you can read the source, and then when you feel confident enough google: async. processor. My next and last project is to apply async. to a 3D engine, where the rendering/physics is done in two c++ threads, and the scripting in java asynchronously modifies the state for those threads from a third thread.