That whole example feels like a strawman, from my (maybe limited) experience something that's rather the exception than the norm.

First, lifetimes are elided in most cases.

Second, the curly braces for the closure are not needed and rustfmt gets rid of them.

Finally, the "map" on result can be replaced with a return statement below.

So, in the end we get something like:

  Trying::to_read(syntax, |like| this.can_be(maddening))?; 
  Ok(())

I can vouch for purelymail (https://purelymail.com/), it's simply amazing. Their only rule is basically no marketing emails. It's also quite affordable compared to others.

I have some domains on migadu, one on mxroute, and one on purely mail. I have my Mai domain on google, and seriously thinking of eventually moving everything to purely mail.

I bought the mxroute lifetime membership, but the storage is kinda low (10g). Also Got bit with the migadu price mess in 2020. The purely mail model of pay for what you use makes sense to me. The developer is responsive and says it’s profitable.

Thanks for this. Purelymail looks to tick all the boxes for me and their T&Cs seem reasonable [at least compared to Migadu]. I've never heard of the company though. And they seem to be a one man band, which is a bit of a concern --the old "walks under a bus" scenario.

I shall have to investigate further.

I tried purelymail and it's a good service for the money. The only problem I had is that the spam filtering is really bad.

I've used purelymail for two years and almost without problems.

They look great!

Yes.

Having lived through the same frustrations I've released https://github.com/chmln/handlr a year ago. It comes with lots of nifty scripting tools and significant improvements over xdg-open

How does it decide what mime-type a file has?

It uses the shared mime database, which in turn relies on both file type and content to detect the mime.

Doesn't seem like it does. You set it yourself.

Thanks - will look into that.

> One of the most common use cases for the `ctrl` key is COPYING shit and followed by PASTING shit and it DOES NOT WORK in a fucking TERMINAL... Because `ctrl-c` sends an interrupt

Most terminals today have a copy-on-select feature, which means you don't need to ctrl-c at all. Just select and ctrl-v.

A large number of keyboard shortcuts are in conflict. "One specific keyboard shortcut has a mouse-based workaround" is not really a good answer.

The Windows GUI copied the Mac’s keyboard shortcuts (originally from Lisa?) but didn't have a dedicated key for them so re-used the existing Ctrl key, which already had a meaning on text-based operating systems. (This happened because Microsoft had no input into hardware keyboard layouts, and wanted to make software compatible with the plethora of IBM-Model-M-layout keyboards available in 1985–1990.)

Then Linux GUIs wholesale copied every feature of Windows they could including the keyboard shortcuts, in a context where this was even worse, because now existing Ctrl-based shortcuts from terminal software were directly in conflict with new Ctrl-based shortcuts from Windows.

>One specific keyboard shortcut has a mouse-based workaround

Except for that particular action (select some text on terminal then copy) you have to use mouse to do the "select" part anyways.

That's why I never connect a mouse on my laptops. I've got a touchpad that's part of the keyboard. I select text with it and paste with its middle button. I only buy laptops with three physical buttons precisely because of this user case. A mouse would slow me down.

Where a mouse is really needed is in action games. A touchpad is too slow there.

Doesn't the word "mouse" include trackpads in most context?

Maybe, but I'm not sure about it. They are very different in location and interaction patterns.

In this context there is a lot of difference between a mouse and a touchpad. For example, I select text with the keyboard most of the times in emacs and in any other input box (not in vim, is it even possible?). So I'd lose time by reaching to a mouse. I hardly have to move my hands to use my touchpad.

I want to chip in here with a rant of my own because I absolutely fucking hate this feature. The idea that something I think of as a passive action—selecting text—can destructively alter my clipboard makes my skin crawl, and it's baffling that anyone thinks it's a replacement.

The thing is it's the default on iTerm2 on the Mac, so every time I set it up I spend a week thinking "why is my clipboard always completely full of shite" before I remember and turn it off.

(YMMV, you may like this, you may actually have proper clipboard management, and so on. I didn't say this was a logically consistent rant.)

I don't think Mac OS actually natively supports select to copy so ITerm2 as an app implements it by filling the same clipboard buffer you would otherwise use.

X11 by contrast has by default 2 buffers so you never clobber your buffer filled by control+c however some clipboard management software optionally syncs the 2 buffers bringing back the behavior you dislike.

That’s not true, iTerm2 doesn’t overwrite your clipboard. It, like it’s forebears, uses a separate selection buffer. The only way to paste from it is middle mouse button as far as I know.

It 100% does. The "Copy to pasteboard on selection" option causes selected text to overwrite whatever's on the clipboard, and I just checked.

It's possible that this isn't enabled by default, but I'm virtually certain it is because it catches me out every time.

Aha well then, we have differing experiences

Usually in Linux (specifically in Xorg) it's select to copy and middle click to paste; which uses a separate buffer from the C-c/C-v clipboard.

Personally I find this method much more usable than the traditional windows-style clipboard.

Either way, you want to generally avoid C-c for copy in terminals because it's already bound to the all important "send sigterm signal to foreground process". This is on a long list of ancient cruft that exists in terminal emulators and shells.

The nice thing about how I wrote Kinto is that it supports numerous Terminal applications and the Cmd key location becomes Ctrl+Shift+(the_key_press), so you effectively have everything you'd want without needing contort your fingers for another modifier key.

I am serious about not wanting users of Kinto to feel like they are dying a death of a thousand paper cuts because they have to stop what they are doing and add yet another keymapping. Kinto can't get every app remapped right 100% of the time - but it gets awfully close still.

Initially I did not write Kinto that way because I didn't think it to be all that possible and with setxkbmap it was very difficult to understand and properly implement such a configuration. Probonopd, who does write some wonderful articles about UX related topics that I've also seen hit the frontpage here mentioned not wanting to remap terminals at all - I agreed and eventually delivered. He also made sure that I worked out wordwise hotkeys as well.

Also with it being rewritten, several months ago, to use xkeysnail it is also very simple to add additional hotkey remappings to as well.

> generally avoid C-c for copy in terminals

Absolutely. But it's not cruft. It's the original meaning of the character, and the standard method of generation.

Ctrl+C is just like any other keypress which maps to a standard ASCII representation.

The error is in reusing ASCII chars for GUI actions. This was an obviously-bad idea in 1985, and it has never become a better idea.

That's the traditional perspective.

My perspective is that control characters were a bad idea from the beginning. Then again, so are ubiquitous predefined keyboard shortcuts like C-c.

Having user interaction predefined makes it more difficult to change keyboard layouts and shapes.

Control chars are in-band signalling. This is always "bad", but sometimes it's all you have. Certainly back in the early days of wired serial connections, that was the case.

So if you have in-band signalling, you need a method to generate those signals. I don't think there was any other viable way to solve this problem, and honestly it has worked almost flawlessly.

Of course Microsoft is a big exception, but that could hardly have been predicted 20 years earlier.

So your entire point is that control characters are still good because they were a good solution to a problem that only existed 20-30 years ago? I'm not convinced.

My point here is that we are so steeped into tradition that usability suffers.

I really don't think that's true. It's not tradition, it's practicality -- control characters are good because they are established, standardized, and work perfectly to solve an ongoing need.

In-band signalling is inherently a bit of an architectural challenge. But the problem is solved. The entire internet is run on in-band signalling! We're going on 35 years for TCP/IP, and more like 50 for ASCII control chars. They work very, very well.

Yes, Microsoft broke control character generation for users of their OS, but that's a compartmentalized failure, and easily avoided. The Ctrl+Shift GUI workaround in Windows (and copied in Linux) is not elegant. But any alternative without control chars would be a total loss of functionality.

Ctrl+C being broken by Copy is a trivial example. There's a whole alphabet of control chars (in fact there are 32), and we all use more of them than most people realize[0]. Some have dedicated keys on the keyboard (backspace, return), but obviously not all of them.

I use about a dozen control characters regularly. This is not unusual for someone who works closely with server operating systems.

[0] I'm not sure how to gauge your knowledge of communication signalling or protocols, so I apologize if I'm being pedantic. It sounds like you have ideas about alternatives (and this is interesting to me), so I am curious about any specifics you can share or link to.

> Either way, you want to generally avoid C-c for copy in terminals because it's already bound to the all important "send sigterm signal to foreground process". This is on a long list of ancient cruft that exists in terminal emulators and shells.

stty intr ^X

Then ctrl-c will no longer bother you, and your muscle memory will quickly adapt as X is very close to C

I mapped intr to control g some 30 years ago. It's the interrupt key in emacs. I gave up after some months because I still had to use control c on any terminal that I didn't control.

By the way, I don't even know if I could paste with control c or control shift c back then. Maybe there was only middle click.

I could try again now and see what happens.

I didn't know you could do this before this thread this is a great idea.

Muscle memory doesn't help with "not quite what I'm used to, but it's very close". It doesn't handle conditional statements.

That's actually the worst though. I use selecting to highlight text that I'm reading as an aid. Copy-on-select is a huge dealbreaker for me because it clobbers my clipboard when I don't want it to.

To be pedantic X11 has a copy on select feature which works on virtually all applications. This means you get by default 2 different clipboards although some environments/applications have an option to sync them among other additional features like being able to select from the last n pastes which may be optionally persisted through reboots for example.

Shameless PR to update the "side-by-side" comparison on that page to an actually recommended style of Redux: https://github.com/wire-ts/wire-ts.github.io/pull/2

> There's no consistency

Just a reminder there's like 7 different context menu styles in Windows 10, not to mention two control panels.

This only emphasizes how bad the Linux desktop experience can be. The devs of the Linux DE community could do better but chose to do gang turf wars.

And as you say, Windows 10 still sits there having confusing and mediocre system UIs.

All of these are optional, just disable and use an alternative?

I use resolved and timesyncd however and they work amazing for my basic needs on the laptop.

Almost every point made here is basically false.

The best performing languages are imperative (C, C++, Rust), with functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads. Whatever properties were supposed to make it faster/parallelizable have clearly not manifested themselves very well after decades.

Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.

> Go is, by all accounts, a massive nightmare.

All accounts? That's a pretty strong claim. Go works well at Google.

Both of your comments would have been upvoted if they didn't have offensive judgements in the last sentence.

You speak the truth, functional programming languages have excellent performance characteristics when compared to other GC'd or JIT'ed languages.

I'm not sure about FP leading to better architecture, it might just be the type system there, which Rust has adapted (in a slightly less powerful form) as well.

Maybe if you had used Go to solve the sort of problem that it's meant to solve you wouldn't have judged it such a nightmare.

The final remark about Go is the only possibly valid remark.

I've used Go for both "web routing" and business logic apps and found it fairly nice. In what context and in what way do you find it a bad?

Go was designed as a language with fairly good performance, but with limited capability so that programmers with limited skills would find it hard to get too far into the weeds. It is well suited to undemanding tasks.

Most programming tasks are undemanding, and most programmers have limited skills, so it is a good match for a great deal of routine work. It fits in the same niche as Java, where Java's OO apparatus imposes complications that are superfluous for simple applications, and an actual obstacle in most. So, a language that abandons all that is better in those applications.

Simple tools are not bad except when you need something more. So, my agreement was with the idea in mind of writing Pandoc in Go, which would be madness.

Thanks for the details. I hear what you've said. I agree that Go was built with limited capability in order to make it easy for junior developer. And I agree it can slow down more senior developers at times. Although not nearly as much as I expected when I first started using it.

I don't know Pandoc so I'll take your word for it. I'll also agree that there are entire of classes that Go isn't sell suited for, but we'll have to disagree as to whether it's limiting for the types of applications it was created for. I must not be building the same class of application as you are.

By definition, it is not limiting for the types of applications it was created for. We might disagree on where to put the boundary around those applications. Historically, tools have always found uses beyond their intended purpose, and Go is unlikely to buck that.

It really comes down to whether, while working on a big system, you will discover a necessary task that a language cannot do well. This might be because it lacks a key feature, like bit twiddling operations, first-class functions, or operator overloading. It might be inherently just not fast enough to meet a deadline, or not consistently so. It might not know enough about types to prevent common mistakes, or might lack operations on types needed to direct compilation. It might lack the organizational features needed to make a large system manageable. That doesn't make it a bad language, but would make it an unwise choice for a project that might, as time unfolds, be found to need one or other such quality. Generally, the bigger a project is, the more unexpected requirements surface.

This is where we get to the idea of "dynamic range". A language with a wide dynamic range takes correspondingly long to learn. People skilled in it are harder to find and more expensive to hire, you have fewer of them ready to hand, and those you have are likely to be already busy. Yet, you might need more, and any you have more than earn their keep.

Wanting to make a livable wage is not greed.

Besides, unchecked migration would lead not only to seriously depressed wages but also massive social issues.

When it's done by stealing opportunities from the poor it is.

Immigration has a direct impact on the labor market. Unlimited migration would likely outpace any sort of economic growth and massively depress wages. I would not look forward to competing with an order of magnitude more candidates for jobs with mediocre pay.

> Your comment serves as an attempt to change the subject

That's funny because you did not refute anything I said and just brought up Trump, whose opinion I couldn't care less about.

Immigration has been limited for many years, and both parties support limits, it’s not a new idea that came from Trump. Personally I support open borders. I do believe it would reduce wages for some locals, but overall the dramatic increase in net welfare would be well worth it. There’s no need to bring up Trump - this view is so far from the Overton window that current political figures are barely relevant.