Location: Germany
Remote: Yes
Willing to relocate: Sure
Technologies: Mostly Rust currently (I wrote hunter: https://github.com/rabite0/hunter ), but I've also written a lot of Common Lisp, Shell Scripts, Linux administration, Microcontrollers. Haven't done any Web front-end stuff, it's very ugly in general.
Email: rabite0@posteo.de
How is the cost in terms of binary size nowadays? Last time I checked using Futures meant adding roughly 5MB to the binary. To me at least that is unacceptable, so I just rolled my own stuff on top of rayon's thread pools.
Ah, yes, that was probably it. I stopped looking into Rust's Futures pretty much as soon as I noticed how heavyweight the required runtime is, which seemed ridiculous to me, since Futures are so simple conceptually. I have to look into this again.
In general, Rust's big binaries are one of the things that puts me off the most. Even dynamic linking often doesn't help much. Then again, if a few MB, which is a rounding error nowadays, is among the worst I can think of, that's actually pretty amazing ;).
When Rust switched to the system allocator by default, that slimmed down the minimum size quite a bit. In addition to that, where size matters, there are some articles about how to slim it down even more, here's an example: https://github.com/johnthagen/min-sized-rust
Thanks for the link! I knew about strip, which helps a lot, but the other options look promising as well.
I really care about binary size, since for short running programs, or when startup latency is important it can actually be much faster in real time to have less, but slower code. Especially so on a slow HDD like in my laptop. Loading a few MB when it's under heavy load can take a few seconds.
Edit: Wow, LTO makes a huge difference. Almost a 40% smaller in my case AND it's faster. Really excited to try xargo now.
It was the runtime required to actually run the Futures.
Rust's Futures allow for easy chaining, whereas I only implemented a simple callback that runs on completion, but it doesn't allow one to get at the computed value directly. I simply send a "check for updates" event there. Instead the value gets stored in a Mutex and has to be pulled out of that explicitly, although it can stay in the "Async" type, just that it gets stored directly in the struct after it's pulled out of the Mutex. The advantage is you don't have to pay for the locking all the time and the value can stay where it is, so you don't need to juggle it around. You can see it here: https://github.com/rabite0/hunter/blob/master/src/preview.rs...
I started working on an improved version that actually allows for a callback with a reference to the value upon completion and also a callback that moves the value out, but I haven't finished that yet and after seeing this I might not ever, but I probably will, since it's definitely educative.
Sorry if that wasn't clear, it's been a rather long time since I checked on the Future story. There seem to be more options now than when I looked into it. When I did my research over half a year ago tokio seemed to be the only option. Glad to see that's not the case any more.
It’s all good! To elaborate a bit, there’s a trait, Executor, that people can implement to build these kinds of things. This stuff, along with the final version of Futures, stabilized a few days ago. But it’s been baking a while.
Also, if you use Box<Error> or failure[1]'s Error type you can get around implementing most of the conversion Traits, but you lose the ability to tell which errors can happen by just looking at the type signature and doing exhaustive matching on them.
Yes, you can select multiple files with space and open them all at once using the exec feature (type "!"). When you press tab it will insert "$s", which will then be substituted with either the normal selection, or when multiple files are selected with those multiple files. This works pretty much like in ranger. It doesn't work when you just open them by "entering" them. I'm not sure if that even makes sense since different file types could be selected and it's not clear what the right thing to do would be. Maybe opening them one after another? I'm not actually sure what ranger does in that case.
The most difficult thing.. That's actually hard to say since I started this to learn more about Rust and it's the largest project I've written so far at >8000 loc, so basically everything. :) But specifically, I guess getting the asynchronous stuff working right was the hardest part. hunter loads everything asynchronously and on demand, like the metadata and directory size. This is to speed up loading times. I'm still not sure it's 100% correct. Rust makes it easy to prevent data races, and it's very strict about what you can share across threads and how you do it, but it doesn't prevent race conditions and logic errors, and reasoning about concurrent programs is still hard.
I actually implemented my own Async type instead of using Futures or something pre-made, because as far as I can tell especially futures come with a pretty heavy binary size cost, which in turn takes time to load, making startup slower on a slow HDD. Other than that just getting the design right was pretty hard. Although the basic foundation is pretty solid I think.
Another reason I started this is to see how usable my TUI widgets are and when I first scrolled through a directory listing at light speed I got somewhat addicted. :) I kept those widgets really generic and they're easy to use in the sense that you can for example get a ListView for your type by just implementing a trait for it and they're very composable so that you can easily get a TabView for your ListView and so on. My plan is to put all that in a library eventually.
Error handling is another problem area. When I started I actually didn't make use of any error handling at all, in the sense that I didn't return errors from my functions, instead handling everything by just returning early, or returning empty strings or whatever made sense. This got problematic after I started heavily using mutexes, channels and other things that return errors, since I couldn't use ? and most of the time there is really nothing to do other than returning early with the error (and logging it), or skipping that operation when it happens in a loop.
I then went the other extreme and started returning Results everywhere. The problem is that right now there is just one single enum with all the dozens of possible errors, so it's hard to say what error can actually happen. Another problem is that I had to remove backtraces after implementing the Async type since backtraces can't be shared between threads for some reason and now the log viewer is pretty crippled. It's actually a "FoldView" and you could fold those backtraces in and out to see what went wrong where, now it's pretty much just a simple list. So yeah, splitting those error types is definitely on my todo list. :)
I wonder if the space region in the interior of a black hole expands the same way as regular space around it.
If so, it would seem to be possible for a super massive black hole to be so big that it would be impossible to actually reach the singularity. If there is enough space the singularity would "move" faster than light. Essentially another event horizon within the black hole protecting travelers from the singularity.
This would lead to a stable universe like ours. Though about this a few days ago and it seemed like an interesting idea.
I remember from a youtube video that the spacetime inside the black hole flipped around, where space becomes temporal dimension and time becomes spatial dimension (i.e. time is traversable in either direction while the singularity becomes an inevitable place in the "future").
> spacetime inside the black hole flipped around, where space becomes temporal dimension and time becomes spatial dimension
No, this is not correct. The "flip" is in a particular choice of coordinates, not in spacetime itself.
> time is traversable in either direction while the singularity becomes an inevitable place in the "future"
It is true that the singularity is inevitably in the future--that's because inside the horizon, the future "time" direction points towards the singularity. But time is still only traversable into the future; you can't "reverse" your travel in time inside the horizon.
Iff I understand correctly, what pdonis is saying is that it is in your future. It’s where (when?) you run out of future to go into, in a way which may or may not be analogous to the North Pole being the coordinate singularity where you run out of north to move in.
That is true, the time and space axis gets flipped at the event horizon. This also happens to a fast moving objects due to relativistic effects, although the roatation is usually not very high unless you go really fast. Seehttps://en.m.wikipedia.org/wiki/Minkowski_diagram
However that doesn't mean you can't move when you cross the event horizon. You can do that like usual (except for gravity pulling you inside. You can. It only means outside observer won't be able to see what you're doing, because of the time dilation (and the event horizon of course).
This kinda implies time and space are the same thing, it just depends on your point of view. Still have to see about that :D
> the time and space axis gets flipped at the event horizon. This also happens to a fast moving objects due to relativistic effects
Neither of these things are true, and I have no idea how you are getting either of them from the Wikipedia article you linked to. Penrose-Terrell rotation, which affects how objects appear to observers when they are moving at relativistic speeds relative to those observers, does not "flip" the time or space axes; it's an optical effect due to the finite speed of light.
As I noted in another post upthread, the "flip" of time and space axes inside a black hole's horizon is a property of a particular choice of coordinates, not of spacetime itself.
> This kinda implies time and space are the same thing
No, they aren't, because there is still a fundamental difference between timelike and spacelike directions in spacetime. That is true regardless of how you choose coordinate axes.
People often mistakenly try to map space time onto an ether-like flat background, treating spacetime like a drawing where the paper is the background. It's not an uncommon kind of fumbling as someone tries to grasp these things.
If black holes are universes, then what happens when 2 black holes merge? What happens when universes merge? The sudden appearance of more stuff? More space? Existential cataclysm?
It's simply the plural of "universe". If there actually is more than one universe, it would imply that "universe" was a misnomer, much like "atom" turned out to be.
People might keep using the word with a new definition. The new definition could be something like, "a region of the multiverse that is causally disconnected from other regions of the multiverse under such-and-such conditions." If those conditions change, two universes could become causally connected and merge into one universe. I imagine inhabitants of those universes would (if they look in the right place) witness events with no recognizable cause until the merger was complete.
Or what we currently call the universe might be renamed a sub-universe within the actual "one" universe, which was much bigger than we thought. Then the question is what would happen when sub-universes merge. Same question, different glyphs.
