cytzol

Embedding your assets like this isn't always an improvement. For example, I work on a site with a Go server and static content pages, and I like that I can update one of the pages and see the change instantly without having to re-compile the entire server binary just to get the new files included.

> Why do you prefer having an app running (and owning the sole menu bar) when it has no GUI on screen?

Here's a story from when I was using Windows for work after using Macs for ages. I had one folder in Sublime Text open, and I wanted to close that window and then open another one. So I hit the [X] button in the corner, which closed the window, and then I instinctively went to the global menu bar at the top of the screen to go to 'File › Open' to open my new window. But of course, it wasn't there, because closing the window also got rid of my ability to access the menu bar.

And then I opened Sublime Text again, and it re-opened with the old window I wanted to get rid of.

This is why, like others in this thread, I've grown to really like the application-vs-window separation. Having a menu bar on each window, and having programs close themselves when they get down to zero windows, means I have to do my operations in a certain order (I have to open my second window before I can close the first one, I can't do it in either order) and use a UI hierarchy that I don't think makes sense (I have to use the menu bar of an existing window to open a new window, even though that operation has nothing to do with that window's contents).

I found this "best practice" curious to read:

> The standard net/http server violates this advice and recovers panics from request handlers. Consensus among experienced Go engineers is that this was a historical mistake. If you sample server logs from application servers in other languages, it is common to find large stacktraces that are left unhandled. Avoid this pitfall in your servers.

I don't think I've ever seen a server library — HTTP or otherwise — that didn't have a top-level "catch all exceptions" or "recover from panic" step in place, so that if there's a problem, it can return 500 (or the Internal Server Error equivalent) to the user and then carry on serving other requests.

My reasoning is that any panic-worthy programming error is almost certainly going to be in the "business logic" part of the server, rather than the protocol-parsing "deal with the network" part, and thus, recoving from a panic caused by processing a request is "safe". One incoming request could cause a panic, but the next request may touch completely unrelated parts of the program, and still be processed as normal. Furthermore, returning a 500 error but having nobody read the stacktrace is bad, yes, but it's way, way, way better than having your server crash meaning nobody can use it ever.

Oh wait, is the assumption here that your service is being run under Borg and has another 1000 instances running ready to jump in and take the crashed one's place? Is this another case of Google forgetting that people use Go outside of Google, or am I reading too much into this?

As a sidenote to your sidenote: I've noticed that the term "syntax" seems to have two different meanings nowadays. There's the technical meaning, namely "the rules that govern how characters are parsed into abstract syntax tree nodes", which in your example, would cover whether Rust shoud use `.` or `::` as a namespace separator, whether to use `[]` or `<>` for generics, that sort of thing. (Both of which have trade-offs in constraining how other parts of the language can be designed.)

But I think sometimes, people use "syntax" in a blanket "how the language looks" way — that is, whether it's symbol-heavy, whether it's word-based, whether it's information-light or information-dense, and so on. This makes it more a function of which features of expressivity the language chooses to expose, than the individual syntactic choices that determine which characters we use and for what. Again in Rust's case, it has attributes, it has namespace separators, it has the zero-tuple, it has generics, and it has lifetimes, all of which need some way to be expressed.

Don't get me wrong, you're allowed to not use a language if you don't like the way it looks visually. Or maybe it makes good use of a certain character that's hard to type on your particular keyboard layout. That's fine. I also can't decree that either of these uses of the term "syntax" are wrong. But when we're talking about language syntax, it's important to remember when you're talking about syntax, and when you're instead talking about language features. If you don't like the way lifetimes look, that's one thing; if you don't like the way lifetimes make you change the way you write code, that's another.

So I have to ask: of those four code snippets, how would you prefer to write them? What would you change? And can you get away with making those changes without breaking anything else?

Looks like the application requires macOS v12, which is only a year old. What features does it require that means it can't be backwards-compatible? Is it a SwiftUI thing?

Sorry, I don't get what you mean. Could you elaborate or re-phrase?

Serious question: how do you square your third paragraph with your first? That is, if you're using Obsidian's features like [[square bracket link syntax]], or #tags, or inline images, aren't you effectively locked in to editors that support the same set of features?

> Just a reminder to everybody that Fastmail is an Australian company, and is therefore subject to Australia's TOLA / Assistance And Access. [...] Having your e-mail provider compelled to work against your interests is no joke and you may not want to be in that situation.

This is not quite true.

The TOLA bill does allow the Australian government to compel an employee to break their product's encryption — which, yes, is dumb as hell. But Fastmail does not offer end-to-end encryption. As an Australian company, they already have had to comply with a court warrant asking them to surrender data; in other words, law enforcement does not need them to install a backdoor when they already have a front door. Your comment implies that TOLA made Fastmail less secure somehow, but this has been the case long before TOLA; the existence of that bill changes nothing.

I feel like it's important to point this out, not for the sake of pedantry, but to say that if you want truly secure encrypted e-mail, you must be in control of the encryption and decryption step, rather that having a company do that for you — you can't assume you'll be safe just because your provider isn't based in Australia. It's been a while since I've looked, but I think it would be very hard to find an e-mail provider that explicitly says it won't hand over data when presented with a valid warrant.

I use cURL a ton too, for when I want to make a one-off request, examine the response, and then throw it away. Here are some reasons why I'd reach for a tool like this:

• I want the history of every request and response to be saved by default, so if I ever need to look back to one I know it's available

• I'm sending several similar requests and I want them to share a set of variables, or, I want something in the response of one request to be used as a parameter when sending another

• I want to set a URL parameter with a bunch of symbols in without worrying about quoting

• I have so many types of requests that I'd like to organise them in a tree

• The JSON returned in a response is absolutely massive and I'd like to expand/collapse subtrees instead of viewing the whole thing as unhighlighted text