Direct

It's a library, so only half an answer to your question, but there's a fantastic library called rayon[1] created by one of the core contributors the the Rust language itself, Niko Matsakis. It lets you use Rust's iterator API to do extremely easy parallelism:

  list.iter().map(<some_fn>)

becomes:

  list.par_iter().map(<some_fn>)

Seeing as in the original example code, the final copies into the minifb have to be sequential due to the lock anyway, all the usage of synchronization primitives and in fact the whole loop could be replaced with something like:

  let rendered = buffers.par_iter().map(<rendering>).collect();  
  for buffer in rendered.iter() {  
    // The copy from the article  
  }

I've not written much Rust in a while, so maybe the state of the art is different now, but there are a lot of ways to avoid having to reach specifically for synchronization primitives.

Really cool stuff. I don't like being negative when it comes to fantastic moves like this, but I'm still really disappointed that it doesn't support 64bit executables.

Or underground trains, or long tunnels, or hikes, or many things. Hopefully though the typical developer doesn't spend the majority of his time on an airplane. Me personally, I don't need to be coding so consistently that the loss of a few hours on a plane is going to stop me doing this.

Used to use a SoYouStart E5-1650v2 for the 6 Core/12 Hyper-Threads. I moved when I got a sweet server auction deal with two Xeon's but recently moved to Hetzner because the price for their AX50 Ryzen 1700X + 32GB of RAM is hard to beat.

I have been doing this for 4 years. I can rent a 16 core server for a couple of years for less cost than a low entry Macbook, with a 1Gbps line. With mosh, I can develop literally anywhere with no lag at all (or at least, no noticeable lag) even with a 3G connection. I can RDP to an EC2 Windows instance when I need a quick Windows machine, again with minimal lag even over 3G.

I sold my desktop, and now use a cheap £200 garbage laptop as a thin-client to my machine. Not only do I get incredible compile performance due to being able to use 16 core Xeon's, but I am not tied to any desktop.

I can whip out my phone and pop open a tmux session from anywhere, in an emergency I can hop onto a friends computer and thanks to SSH 2FA fearlessly login to my dev system with my full environment that I never have to close.

At this point, I would actively avoid jobs that wouldn't let me work this way. Currently got a sweet remote gig and I'm going to fly to Spain next week and spend a couple of weeks coding on the beach with my 3G tethered laptop.

Edit: Just to clarify, I don't need to work in an IDE or use any Windows software that I couldn't tunnel over X. So it might not work for everyone. Just wanted to give an example of it working out great for someone.

I wonder if the design is based on some of the solid research that went into MangoDB[0].

[0]: https://github.com/dcramer/mangodb

Yeah, I can't see how I would do it. I could open a tmux pane with fzf and run another kak window but that's not really the goal. I'd like to use fzf to open a found file in the current kak window. The plugin architecture just really limits this kind of thing, and this fzf example was just a simple one I wanted to use to demonstrate the point.

But again, the stuff you have in this editor is absolutely fantastic, really, I can't say that enough. I just personally find kak less flexible than an already inflexible vim so I couldn't stay with it.

If you have a way to do the fzf example though I'd be curious to see how you do it.

Honestly it's been a little while, I can't remember. However this is more or less why I went back to vim. Your other comment in particular:

> We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).

I don't really want to switch to an editor where missing options might have to be justified. I'm not knocking your work, it's really good, and my complaint applies to vim as well. But if I can't implement something myself as an add-on (which I definitely have more power to do in vim) and have to wait for it to be patched and released in your release cycle I'd rather just try and implement your features in vim and keep the customisability.

Having said that I could be wrong and maybe the plugin system is more powerful than I thought. But as an example, I have a 5 line function letting me have ctrl-p like functionality backed by fzf in vim. I can't figure out how I would do that in kakoune at all.

I tried switching to this editor permanently from vim. The selection based movements are asurdly good, I could kill for something like this in vim.

However I couldn't stick with it for two reasons. The first is when I went to figure out how to customise it, I found that the customisation is essentially vim like but weaker. Everything is hardcoded like it would be in vim but with less options. If you're used to Emacs insane customization, this is the other end of the spectrum. The stuff that IS customisable works by executing embedded bash scripts[1]!? You can only embed these in specific hooks and places, so it's really limited, and platform specific. Install this on a system missing a bash feature someone is using and who knows how it'll behave.

Basically, the features implemented are gorgeous, but past that I can't stick with it. Just going to consider trying to port the selection based movements to a vim plugin but I think it'll be a challenge.

1: https://github.com/mawww/kakoune/blob/master/rc/clang.kak

I think having to remap your systems keyboard to something other than your native language in order to use an editor is a bit unreasonable.

Typing accented characters is far easier in Spanish with a Spanish layout, that we all grow up with. The software shouldn't just ignore half the planet on the basis of "use English".

I'm not sure if I follow, I don't see what the benefit is in defining an authentication protocol like this based on passwords. If websites are going to actually work with this protocol, why not use public key authentication or any of several other existing authentication protocols. Maybe I'm missing something, but unless this somehow eases the distance between password based authentication and other methods then it seems kind of like trying to shuffle our human password schemes into a protocol where details like a unique password shouldn't need to matter anymore anyway.

I'm a little confused.

This is awesome! I recently read this ticket[1] mentioning that porting of µBlock seems to be a starting point for gorhill to port µMatrix. In my perfect world, I would be using Firefox with nothing but µMatrix, as it is right now I'm having to use Chrome with µMatrix and sadly can't get rid of µBlock until µMatrix can hide blocked frames. Still, getting closer to that perfect world! The work done by gorhill is amazing.

[1]: https://github.com/gorhill/uMatrix/issues/73

This and the paper above were extremely entertaining reads. To the point that I am downloading CHICKEN right now to start exploring. Thank you for those links.

Trying this out now, It's actually pretty nice. I get that It's a visual editor that uses Markdown as a storage format, but it still would be nice if it would actually let me type Markdown - interestingly it seems to be pretty indecisive on whether or not I should be able to that.

I can type a # and it will automatically turn the text into a Title which is nice, but any other Markdown-like syntax is printed verbatim, which is odd because when I save and reload it will suddenly render it as Markdown just fine.

If I could write Markdown in this and had some way to refresh the editor to visualize it as an alternative to the insert bindings, personally I'd be sold on this for sure.

> All written in machine code: that's even lower-level than assembler!

Can you clarify? I don't know much about the history of this game or the BBC Micro. But do you mean to say this was written byte by byte by hand? I'm imagining someone typing each individual byte of an opcode here. If so, that's pretty amazing.

Ah ok, brilliant. This was my main reason for not trying to play with Rust a little more. I thought it was something I just didn't understand. Just out of interest, is there anywhere I can have a look to see what kind of solutions have been suggested?

I'm a little rusty but I did read the 0.4 docs before and gave the language a try, I'll dive into 0.5 again this weekend, I am a little confused by something however. What's going on with strings? When I last looked, a lot of the string operations worked with a specific pointer sigil[1]. If I'm using managed boxes, and the methods take and return unique boxes, is it because I'm using the wrong sigil for the job or should I expect to be able to use managed strings?

Is this just me misunderstanding the memory model or is this something that just hasn't been straightened our yet? I'm pretty confused about this in particular, as I thought I understood the point of the different sigils pretty well, but the way the library is written makes me wonder. This applies to things other than strings I guess, but strings seem like a good example.

[1]: https://github.com/mozilla/rust/blob/master/src/libcore/str....