jzm2k

Looks like Nebula uses go-libp2p and all of the supported networks listed in the README use libp2p for their p2p networking. Mainline DHT doesn't support the same transport protocols that libp2p supports (such ash TCP+Yamux+Noise) which is probably why Nebula doesn't support Bittorrent

Isn't this criticizing the discussion of (new) programming languages, not the new languages themselves?

>I mean how do you even use the numbers? Who looks at code and says "no, this should be exactly 8 lines below this one." I just Alt + Down until it's right. I'd spend more time trying to write the command right than I'd spend just pressing the keys multiple times.

With relative line numbers it's really easy actually. Typing dd7jp takes less effort than pressing alt + down multiple times and I have hard time believing you'd be make this argument if you were comfortable with modal editing.

In fact, none of the alternatives you listed seem attractive if you're accustomed to modal editing. How is Home, Shift + End, Delete a good alternative to dd? So much movement to do a simple operation.

I would highly recommend you giving it an honest try and if it doesn't work, you can always go back to editing the traditional way but once it clicks, "the old" way feels super awkward.

I still don't understand what this has to do with WebRTC/WebSocket. You can combine, e.g., mDNS with WebRTC and build a pure peer-to-peer network.

Is there any P2P network that fits that criteria? The first time you connect, you need to know at least one publicly reachable node but I fail to see how that relates to WebSocket/WebRTC. I think central server is somewhat ambiguous because the bootnode could be any node on the network you have prior knowledge of.

>Sadly both WebRTC and WebSockets seem to have been designed in such a way that excludes pure peer-to-peer operation.

What do you mean by pure peer-to-peer operation?

git-rebase is stupid because somebody doesn't know how to use it?

I use it all the time and I really like how I can make garbage commits (wip, test) and then squash them into atomic commits which are easy to review and later on easy to bisect when inevitably mistakes happen. Sure I've fucked up too when I was learning on how to use it and those were some painful mistakes but only through using it and making those mistakes have I learned to use the tool to great advantage (clean history).

You can still enjoy the language without engaging in this drama. I only know about this because it's on the front page of HN (maybe I'm living under a rock) and yet the language still works nicely and I enjoy writing it immensely.

>You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking.

Are you saying the mentor should actually go and check the browsing history of one their engineers to verify whether they've actually done "correct work" or what are you trying to say exactly? This sounds to me like micromanagement of the highest order.

Genuine question, why? It's not like the project (at least by default) owes anybody any explanation why it's run the way it is or why contributions are not accepted.

Maybe you should try committing longer? I had used Vim for nearly 8 years and had learned the crazy tricks you can do with Vim before switching to Kakoune and it took maybe 2 weeks to feel comfortable. I think people may overestimate how long it takes to relearn a style of modal editing which keeps them from committing to Kakoune/Helix which then prevents them from giving Kakoune/Helix a fair chance. After having learned this new style of modal editing, I'm really glad Helix doesn't have Vim style because I feel it be inferior to what Helix has.

I don't think it is. There are times in projects where you're exploring the problem space and figuring out how to get implement whatever you're doing and to speed up that process, you can take shortcuts such as assuming that a value always exists, there are X many users, or this function will never fail so you `expect()` on it. Also very little testing and no documentation. Once you have something that works, it's time to make it correct by removing those assumptions and adding tests and documentation. I believe this is what the distinction between "make it work" and "make it right" is.