liancheng

In Neovim, most non-toy language servers allow you to open the doc/definition in a popup/floating window, typically bound to `K`. Some language servers like rust-analyzer and gopls also support opening the docs in your browser.

Unfortunately kickstart.nvim is no longer actively maintained.

I found DAP neat enough for interactive debugging (when logging is not enough). But I only used DAP under Neovim to debug Python.

Hey Will, thanks for building Textual! I'm using it in a simple side project and really enjoyed using Textual. However, I do feel that the magic methods used in the message passing system and reactive system are questionable, especially in large projects.

You recently renamed the widget "Checkbox" to "Switch" in a newer version. I easily did a rename in my single file app. But imagine that someone built an extremely complicated TUI app containing dozens of files, you can easily miss a rename, which won't be caught by any static checking tools and only result in runtime error.

I had fun building simple apps using Textual, but I probably won't use it to build any complicated TUI apps. I feel that IDE/static checking tools unfriendly magic may directly hurt Textual adoption because it doesn't work with automated tasks like refactoring, and that prevents people to use it in large projects.

Actually, none of these processes is essential for running Spark unless you have to read data from HDFS and have to run Spark on YARN.

Spark supports reading data from different sources, e.g., cloud blob storage, relational databases, NoSQL systems like C* and HBase. NameNode is only required if your data is stored on HDFS, and that is not an essential problem of Spark.

As for scheduling, Spark can run in standalone mode without any YARN components. Actually, that is how Spark clusters run in Databricks.

Coalescing down to a smaller partition number does decrease the number of output files. But it also decreases parallelism, which isn't expected when processing so large a dataset.

Coalescing makes more sense when some stage of the pipeline dramatically shrinks the amount of data (e.g. grep-ing error logs from all log files) so that successive stages can easily handle the rest of the data with much fewer executors.

(disc.: Spark committer)

Man, are you serious when you said that "The result is that concatenating two strings takes O(1) time in Erlang, compared O(N) time in other languages"? Yes, you are right that Erlang represents strings with lists, and that's the VERY reason that Erlang must take O(N) time to concatenate two strings (N is the length of the first string).

Just check your /usr/lib/erlang/lib/stdlib-xxx/src/string.erl, and you'll find this:

  concat(S1, S2) -> S1 ++ S2.

and "++" is obviously a O(N) operator.

But yes, string concatenation is somewhat faster than other languages that represent strings with arrays of characters. Because in Erlang, it's O(N), while in others it's O(N+M), where N is the length of the first string and M is the length of the second.

China mainland OK now.