dthul

Love the flashback to the old Compiz days! The only thing missing now is wobbly windows.

Can't wait to try this out! I always wanted the ability to see the tasks that are currently running or waiting.

In the screenshots I can see that tasks have descriptive names. Does anybody know how to set the name for a task? tokio::spawn doesn't take a name parameter. Does it require `tracing`?

The author of the PR is burntsushi of ripgrep fame. This isn't some "developer oppression by non-developers".

I agree. I use software written (at least partially) in Rust all day every day and it's only getting more. Obvious examples include Firefox, ripgrep (which powers VSCode's search) or librsvg which renders SVG images in Gnome.

Love the 2021 edition changes and also the fact that they are so minor!

The commas give it the right rhythm I believe. I can only hear French though, maybe because I never heard the English version.

Fully specified function signatures are a conscious decision because it allows you to type check and borrow check a piece of code without needing to analyze the bodies of other functions. I also love it as a human because there is no guesswork involved.

Right, in both approaches you can choose to handle the error by ignoring it and crashing. In "errors as values" languages you have to make that choice explicit by marking the line with `unwrap`. Saying that this requirement is "the single most unproductive mis-feature a language could have" is extreme hyperbole, no? Adding `unwrap`s during development to imitate implicit exceptions for fast prototyping takes no time or thought at all.

On the contrary, when you later want to polish your program for release these explicit markings make it very easy to find the points in your code where errors can occur and which you don't properly handle yet.

Without knowing much Go I believe it's neither a nor b. The pointer to the single element will always stay valid, no matter whether reallocation happens or not (and having a pointer doesn't influence whether reallocation happens or not). Re-allocation might be a confusing word here because afaik it's actually always a new allocation (the old one is not touched) and only if there are no more pointers to the old allocation will the next GC cycle deallocate it. So there is never iterator invalidation like in C++ but of course you still need to be careful because you might accidentally share or not share the same underlying data.

I don't quite follow. You always have to somehow handle the case the file does not load successfully. In exception languages that handling might be implicit (raise an exception and crash your program) and in "errors as values" languages you at least have to acknowledge that it could go wrong with something like `image.unwrap()` (which turns it into a program aborting panic).

I don't think that's true because if I understand it correctly, the return type of functions which can possibly throw unchecked exceptions would not indicate that they can throw or what they can throw. On the other hand, with the "errors as values" approach (including "bubbling up" operators like `?`), you can tell exactly from the function's return type if an error can be returned and if so what the set of possible errors is.

Did you maybe mean "the checked type"? In that case I still think it's not equivalent because at least in Rust you can automatically transform the error while it bubbles up, while I don't know of a language with checked exceptions that lets you transform the exception while unwinding (short of manually catching, transforming, and re-throwing).

Note that in Kotlin the return type is `Int?`, not `Int`. You can't forget to check for null because the compiler enforces it.

To your first point: Another example in the design space would be Rust which works very similarly to Kotlin but returns more information in the failure case.

It's the correct design only if we assume that the design space didn't allow for a different return type. Kotlin for example offers toIntOrNull (https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/to-...) as an alternative.

I read some other thread on here some time ago that talked about the option of using a Pi-hole (or so?) to block smart TV ads.

That could be a nice alternative! In that case you do need a separate tuner though and something like a Chromecast if you want to watch Netflix. And you might not have easy access to extended channel offerings such as watching older episodes on demand etc.

The issue is that it's hard to find any not-too-smart TVs with up to date technology (4k, OLED, HDR etc). Unless you spend a fortune on a luxury brand like Bang and Olufsen.

It's not as easy as just retuning camera settings. Due to physical limitations (at least with our current state of technology) camera sensors have a very limited dynamic range compared to the human eye. Increasing the exposure to better image darker surfaces will overexpose the rest of the image.

We can be hopeful though that this will become less of an issue in the future due to camera technology advancements (like HDR exposure stacks).

I don't know if I would call the SIGGRAPH audience the non-science type :D Also this is not an award but a showcase of short videos which are in some measure remarkable from the computer graphics or art perspective.

We don't see such things happening though and trains have been around for far longer than airplanes.

The return types of fallible functions map naturally onto sum types. By using product types instead there is a semantic mismatch. You get an error and a value but only one of those is valid. So you need to follow certain code idioms to get back the sum type semantics whereas this is something the type system could handle for you. Go's reasoning for that might be that they didn't want to have the complexity of sum types in the language, which is fair but is a tradeoff.

I agree that Rust, besides its technical excellence based on all of these prior languages, also hit a sweet spot with its timing.

Thanks for the info, didn't know that! I'm actually using KeePassXC.

And make it possible to have password managers auto-type the username and password. Some sites don't focus the password field after the username field and so the "username -> tab -> password -> enter" auto-typing breaks.

In one especially bad case I encountered, the tab key after the username would focus on a "clear username" button which appears after entering the first character of the username. So the auto-typing of the password manager would enter the username, tab to the button, enter a password into the void and then click the username reset button, leaving the login form empty. Who needs a button to clear the username field in the first place? That's seems so useless to me.

Yes, I thought about something like that. Being able to map it to the filesystem and back to the Unison database.

But then, what is the point of this content addressed code again? What do we gain from it that we don't already have now? With current file based version control you already have an append only repository, code is never deleted from the .git directory, it's just not always mapped to a file in the source code directory (until you check out an old revision, that is).

Edit: I guess Unison still has the unique feature that dependencies are referred to by identity and not name.

What I don't understand is what they do when merging two branches. If both branches introduce a function with the same name a merge conflict is inevitable, no? Or do they not support the distributed version control approach and every developer has to submit their changes to the current version of the database?

I agree that text files might not be the best way to store code. My point was more that all of the existing tools like code editors and version control systems have been designed around the concept of files though. And instead of Unison being able to tap into the existing ecosystem of tooling, they have to rebuild custom versions. Maybe there would be a way to map a Unison codebase onto the file system and back?

Edit: also worth mentioning that thanks to specialized editors you don't need to manually browse through files but you can browse your code similarly to https://share.unison-lang.org if you so please. That's another plus point of the vast existing ecosystem, it already offers so much and it's a shame that Unison can't make use of it (at least for the moment).

An immediate caveat I came across: if you want to look at some Unison code you need a special code management tool. Take for example their base library on Github: https://github.com/unisonweb/base

The actual code lives in a sqlite file in the .unison/v2 folder. That would mean existing tools like version control and editors would need to learn about how Unison works in order to seamlessly support it. Also pulling out code into a scratch file, editing it and pushing it back into Unison's database sounds kind of annoying. Again, this could probably be solved with an editor that would make this process more seamless and feel more like editing regular code.

As it currently stands it seems very cumbersome to use, mostly due to the tedious process of even just exploring a codebase, nevermind modifying it.

I started reading this book some years ago but quickly gave up when after the first chapters it was made clear that you would have to put a lot of time into the practice. I don't remember what the book's recommendation was. How much time do you spend on it?

Does it get significantly slower if you use Eigen's fixed size matrices? I have a C++ project which uses Eigen and some other templates (but nothing crazy) and it is quite slow to compile. Not complaining though because I don't compile often.

Bootstrapping and language safety are orthogonal. C is unsafe and still you can't bootstrap it if you don't already have a compiler which can compile your C compiler. According to that logic even assembly is not low level enough because you need an assembler to make a runnable program out of it.