4 ms·

Yeah I can see this being a bottleneck for inspecting large arrays. Maybe they‘ll add more transports over time.

royjacobs 7y ago
Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).
naikrovek 7y ago
It uses JSON-RPC which isn't held to a specific transport that I'm aware of. Currently in VSCode if you use a language server for Go, it launches the language server and appears to simply pipe data in and out using STDIN and STDOUT. That should be pretty fast if there isn't a cmd.exe somewhere in the mix. There's a lot of talk about fast C++ JSON libraries and how they can parse 1GB of JSON per second, and that's a lot of data, for sure, if you only count the data that's wrapped up in JSON. 1GB of JSON data contains a lot of waste that is not even usable data, and that's before you consider the textual encoding of what may better be represented by binary data, which inflates the size of a JSON file even further than the JSON syntax itself does. A binary file that is read at 1GB per second would contain far, far more actual data, and binary files can be read and written much more quickly than 1GB/s. I'm really starting to lose patience with all the JSON and web technologies that are finding their way into non-web use cases. using binary formats and simple programs to handle them is really, truly, easier to rationalize about, easier to maintain, easier to write, and easier to replace when the time comes.
- rmetzler 7y ago
  Sorry, this is for debugging. How much state are you planning to transfer in a debugging session?
  - saagarjha 7y ago
    Perhaps a dump of a section in memory?
  - 0xffff2 7y ago
    Practically by definition, anything up to and including the total program state (i.e. the total amount of memory being used).
- icholy 7y ago
  Unless you have fixed width messages which you can directly map to a packed struct, json is waaayyy simpler to write and maintain.
  - naikrovek 7y ago
    100% complete and total disagreement from me. 1) Write a JSON library from scratch. 2) Write a method to handle a binary format from scratch. 3) Compare them. I understand that you are likely relying on some JSON library or language feature, and I would argue that you will bear the weight of that all of that code the instant it has any problem, and that you bear the performance cost every time you use it. Maybe that library or language feature doesn't have any functionality bugs that you encounter; you will still pay for the loss in performance for as long as you use it. Maybe this is acceptable. For me, if I'm writing a tool that either delivers a result that a human relies on, or is a tool that a human uses, I consider it immoral to waste that human's time without a very good reason. I always try to avoid wasting my own time. Reasoning about code that reads and writes binary files is much easier for me than reasoning about an entire JSON library. Desktop, laptop, and tablet CPUs are not getting faster overall. In fact, they're getting slower as cores are added to the silicon dies. We've lived as developers for far too long under the performance gains provided by hardware advancement. Software has generally improved performance only when put on newer and faster hardware platforms. As a general rule, faster hardware platforms aren't a guarantee anymore. We may have more cores to run on, or more CPUs thrown at us to improve performance, yes. We can improve performance in other ways, with zero hardware cost. Avoiding JSON unless it is actually needed is one way we can reclaim performance from the debt of our previous decisions.
    - icholy 7y ago
      100% complete and total disagreement from me. 1. Write your own C compiler. 2. Implement your binary encoding/decoding. I understand that you're relying on gcc or clang, and I would argue that you will bear the weight of that all of that code the instant it has any problem.
      - 7y ago

Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).

It uses JSON-RPC which isn't held to a specific transport that I'm aware of. Currently in VSCode if you use a language server for Go, it launches the language server and appears to simply pipe data in and out using STDIN and STDOUT. That should be pretty fast if there isn't a cmd.exe somewhere in the mix. There's a lot of talk about fast C++ JSON libraries and how they can parse 1GB of JSON per second, and that's a lot of data, for sure, if you only count the data that's wrapped up in JSON. 1GB of JSON data contains a lot of waste that is not even usable data, and that's before you consider the textual encoding of what may better be represented by binary data, which inflates the size of a JSON file even further than the JSON syntax itself does. A binary file that is read at 1GB per second would contain far, far more actual data, and binary files can be read and written much more quickly than 1GB/s. I'm really starting to lose patience with all the JSON and web technologies that are finding their way into non-web use cases. using binary formats and simple programs to handle them is really, truly, easier to rationalize about, easier to maintain, easier to write, and easier to replace when the time comes.

rmetzler 7y ago
Sorry, this is for debugging. How much state are you planning to transfer in a debugging session?
- saagarjha 7y ago
  Perhaps a dump of a section in memory?
- 0xffff2 7y ago
  Practically by definition, anything up to and including the total program state (i.e. the total amount of memory being used).
icholy 7y ago
Unless you have fixed width messages which you can directly map to a packed struct, json is waaayyy simpler to write and maintain.
- naikrovek 7y ago
  100% complete and total disagreement from me. 1) Write a JSON library from scratch. 2) Write a method to handle a binary format from scratch. 3) Compare them. I understand that you are likely relying on some JSON library or language feature, and I would argue that you will bear the weight of that all of that code the instant it has any problem, and that you bear the performance cost every time you use it. Maybe that library or language feature doesn't have any functionality bugs that you encounter; you will still pay for the loss in performance for as long as you use it. Maybe this is acceptable. For me, if I'm writing a tool that either delivers a result that a human relies on, or is a tool that a human uses, I consider it immoral to waste that human's time without a very good reason. I always try to avoid wasting my own time. Reasoning about code that reads and writes binary files is much easier for me than reasoning about an entire JSON library. Desktop, laptop, and tablet CPUs are not getting faster overall. In fact, they're getting slower as cores are added to the silicon dies. We've lived as developers for far too long under the performance gains provided by hardware advancement. Software has generally improved performance only when put on newer and faster hardware platforms. As a general rule, faster hardware platforms aren't a guarantee anymore. We may have more cores to run on, or more CPUs thrown at us to improve performance, yes. We can improve performance in other ways, with zero hardware cost. Avoiding JSON unless it is actually needed is one way we can reclaim performance from the debt of our previous decisions.
  - icholy 7y ago
    100% complete and total disagreement from me. 1. Write your own C compiler. 2. Implement your binary encoding/decoding. I understand that you're relying on gcc or clang, and I would argue that you will bear the weight of that all of that code the instant it has any problem.
    - 7y ago