ThatGeoGuy

Yeah, I think that's something that folks tell me all the time as well. I'm pretty consistently in Rust, C++, Python, or Scheme myself. I tend to only keep ~2 of those in my head at a time, but I don't jump around so often in such detail that anything like that would matter. And C++, Rust, and Scheme all have pretty good compiler and linter tooling that prevent me from really needing something extra. C++ may be the exception there (cmake can be a pain depending on your unit test framework) but even then I don't often find myself wanting.

I do think if folks find LSPs useful they should keep using them. I might even be convinced one day! But at the moment I find I'd rather not. Vim's default auto-complete functionality is actually fine enough for me most of the time, so I might actually be weird here.

Interesting! I actually didn't know this - I've stuck to neovim lately because GUI support is somewhat better than gvim on Wayland (which I think is really just about qt more than anything, but I never really used gvim-qt).

But yeah, tmux & vim together definitely changed a lot of my workflow when I'm not at my local machine. Now working away from "the office" is just a matter of ssh-ing into my machine and jumping into tmux.

I do keep a pretty spartan config though, so I imagine I could do most of what I do in regular vim as well. ¯\_(ツ)_/¯

I like this post, it reminds me a lot of when I started using vim / neovim in university. I spent a lot of time learning nano, cramping my hands, and then eventually deciding to sit down and learn vi proper.

One thing I'm not so sure of though -- the justification for neovim seems to be partially due to needing a pretty recent version (at least newer than 0.5.0, for LSP features). There seems to be a big portion of vim users who seem to dump on neovim for one reason or another as some kind of meme, but I'm not sure that I agree about it being bloated or whatever. If I have to run Slack for work next to neovim / vim, I'm pretty sure I know what is using the majority of my system resources... Anyways, back to needing a recent version of neovim: I think the author could probably get by with just regular vim + extensions if they didn't use LSP stuff.

To be honest, I still haven't really used LSP much, and most of my experience using similar features in other products (Intellisense in Visual Studio, whatever the equivalent broken thing in Xcode is called) is that it really was never that useful? Maybe I'm misunderstanding something and it's just not good for me and my workflow, but I feel like a lot of newer devs seem to enable it and declare that they can't work with anything that doesn't support it. For a long time I've avoided such features since they often seem to have poor performance (Xcode's version of such has definitely taken down a Macbook Pro on me before), or just generally don't add much to the experience other than some coloured lines under parts of my code.

A good compiler (e.g. rustc) and corresponding linter for static analysis (e.g. cargo clippy) are actually pretty good on their own! This isn't true for every language out there, and maybe that's where LSPs are more useful - the Typescripts / Pythons / Javas of the world! I don't know if I'm over-simplifying it though. Either way, I'm pretty sure my point is that whether you choose vim or neovim, it's a great idea to sit down and spend a good chunk of time just getting better at using your tools. It's the kind of exponential improvement that won't even seem egregious a year down the line.

I'd have to support this as well. Many folks always reel in terror when I tell them I almost never use a debugger, or I'm using gdb or lldb instead of some graphical thing if I decide that it's worth actually running.

I think they have their place as tools but largely that's dwarfed by other practices. In the notion of systems thinking, I try to limit the scenarios where needing a debugger is seen as the natural extension. This means having tests, practicing type-driven design, mapping my APIs to some real-world model (and knowing where that fails or falls short), using languages that obviate the existence of certain classes of bugs (e.g. Rust, languages with a GC), etc.

Sometimes you're trying to inspect behaviour that changes in the moment, and debuggers do great there. However, I'll say that some of the most interesting bugs I've dealt with were only visible in release builds with no debug symbols, so my debugger didn't do much of anything for me there.

Plus, this doesn't even dig into other tools that _aren't_ taught because people reach for their debuggers. How many of the folks grabbing debuggers every day have been given the same speech / sentiment given to toolz above about strace? valgrind / address sanitizer? thread sanitizer? syslog?

I feel like this comment might be a bit rambly, but I was hoping to expound on what toolz mentioned above -- there's a lot of ways to crack an egg here and the debugger is something I almost never reach for.

> Huh? I don’t know why you’d say that, if anything I think it’s the Either err t / Result<T, Err> style that is more expression-focused (I mean, it even originates in Haskell :). I wouldn’t even call Common Lisp particularly expression-oriented, honestly, not unless we’re comparing with plain old C and not Rust.

I think that's exactly what I mean. The vast majority of languages (including golang, in TFA) use statements for dealing with exceptions. Rust also had try-catch, but has long since removed that syntax.

Anyways, the reason I said it is because it is not clear what to do when one wants to restart a statement. There are plenty of non-expressions that can throw, and usually it's not thought about deeply, but from a language semantics point of view one does need to have an idea of how to engage with it. For example, if you wrote:

    with open('somefile') as f:
        for line in f: 
            # ...

in Python, and had to deal with a restart during `open`, how do you manage this? The naive answer is to just return the continuation at `open`, but the "with" statement may have contextual setup. For example, `open` might be fine during `__init__`, but may have failed in `__enter__`. If you "restart" in `__enter__`, you need to deal with the partial state. Expression-based languages don't really have this issue because the call stack is usually clear (there's no magic under the hood). Similar analogues would be the `using` keyword in C#, or perhaps even lambda-expressions in C++. The abstraction in the code is separated from the execution of the restart, so it gets kind of gross as a language implementer in terms of not having to have very specific places where restarts can and cannot be.

This is a good reason why Rust / Haskell don't package these and just use Either / Result instead. If you have a bunch of types that you didn't write, injecting a restart into any failing code now brings a question of: "Can you safely inject types into a restart for code that you do not have access to?" and the answer is often no. The visibility rules in Rust make this a non-starter, and in Haskell you have a problem of mutability as well. A condition may be triggered at a point where IO could be injected, and so many of the language semantics would be in question. I suspect the type definitions for a restart in any arbitrary location in the code would be pretty hard to write, so maybe this is an open research area in Haskell already, but I doubt it'd be as ergonomic.

This is correct (in that the most simplistic case is try-catch).

However, the difference between a try-catch and conditions / restarts is that when one signals a condition (exception), the restart (catch) has a continuation from the condition. This allows you to inject an expression into the location where an exception occurred and "restart" your code from that point.

Whether you do such a thing or not depends on the code, on the type of condition raised, and on what expressions are valid. So you get a lot more flexibility in how errors are handled across the system. But likewise: more complexity in having to make that choice in the first place.

Going farther than this, conditions and restarts are really just a fancy way of packaging delimited continuations. I don't personally know any non-Lisp language that has attempted to package these concepts (maybe Dylan, which is a Lisp-like in its own way but without the syntax?). Going back to the original thought regarding error handling - I think Result<T, Err> type handling is fine and that most languages would be better served by that than having different types of exceptions. Conditions and restarts are powerful but your language has to be very expression focused (i.e. does not use a lot of statements) and it's not really clear that there's been a lot of work on making restarts nice to use. Exceptions in all languages that have them have their own set of associated problems, for what its worth, and it's not as easy to move Lisp features into a non-Lisp as one might believe...

HN (and myself honestly) might be a bit biased in favour of Lisps, but if one wanted an unambiguous notation for mathematics, Polish notation / s-expr style writing would be the way to go.

As for screen-readers -> parsing s-expressions and converting them into a more meaningful reading of the equation is within our power as well.

That's not to say that everything should be a lisp, but in terms of unambiguously applying mathematical formulae, I think (* f (+ x 1)) is very distinct from (f (+ x 1)).

¯\_(ツ)_/¯ mileage may vary I suppose. As someone who uses LaTeX a lot myself, I'm not sure I'd be fully happy writing Scheme / Lisp instead either. But I'm not sure the article really gives us less ambiguity purely thanks to an extra whitespace.

This is actually what this law is about. The difference between a cyclist at a stop sign and your average vehicle is visibility. Cyclists don't have blind spots the way cars & trucks do.

So if you can reasonably see that there is no immediate traffic, you don't have to wait at an intersection and risk hoping that another driver at a 4 way stop will respect the stop sign. This whole law is being called the "Colorado Safety Stop" but was initially called an Idaho stop [1][2]. It resulted in a 23% reduction in bicycle crashes in intersections with STOP signs only [3].

Even if you think the results are not intuitive, they are certainly backed by data. Making this a law just means cyclists won't be harassed by law enforcement for doing what is statistically known to be safer.

[1] https://en.wikipedia.org/wiki/Idaho_stop

[2] https://www.youtube.com/watch?v=HT_KdFCVEdc

[3] https://www.bikede.org/delaware-yield-crash-data/#page-conte...

One note to readers who may end up seeing discourse like this online: a (very simplified) critical race theoretic version of this goes as follows:

1. All race is a social (and to some degree, legal) construct. There is more variation in genes / ability / class within a single racial class than there are between racial classes.

2. The "white" race is even a social construct by this definition.

3. Society attributes certain attributes to "whiteness" or "blackness" or "coloured" as a result of its construct.

From there you may hear someone say "we should fight against whiteness" or some such, like a game of telephone. Typically the actual intent is to fight against the construct that certain values are "white" vs. other traits being ascribed to "person of colour." In short: the social construct of "whiteness" as an act of supremacy is the problem, not the colour of one's skin.

I'm not sure I have ever seriously heard the argument "white people are inherently morally guilty due to racism" but I can see how this starts to blend over time. People taking the above argument and misrepresenting or misunderstanding it could quickly devolve into a game of telephone. It's a sensitive topic so it's important to handle it with precision in our language.

But yeah, I'm not sure I've seen any serious "anti-racist" folks actually claim being white is a sin, so much as perpetuating the construct of "whiteness" as some kind of intrinsic value is the real sin. Of course, CRT is a graduate-level field that requires some degree of legal expertise, so you would have to go digging for the steelman version of the argument.

I should check this out!

Bernoulli's Fallacy is pretty new though, it was originally published (hardcover) in August 2021. Which likely explains why GoodReads has more ratings, since it's barely been a year yet and books like this aren't exactly the mainstream vogue.

Thanks for the recommendation though, I'll (eventually, backlogs are a disease) have to add it to my collection.

It's difficult to make an apples-to-apples comparison with this statistic because the US has more sprawl.

Like sure, per-kilometre fatalities may be down, but that says nothing of:

1. The number of non-fatal crashes

2. How much of this incorporates driving on large highways

3. When not on a highway, the degree of traffic in which fatal crashes can't occur (can't get in a high-speed accident in high traffic in New York, for example)

Needless to say, the roads of Japan and New Zealand are so different from the US that it isn't exactly clear that this statistic is really informing us of much, really.

While I'm not dang, I will ask that you refer to HN's guidelines if you want to criticize my writing: https://news.ycombinator.com/newsguidelines.html

In particular the first three rules:

> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.

> Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

Thanks! I'll fix this soon. Small details like this always seem to slip through.

> Elan School was apparently a behavior modification/"therapeutic" boarding school in Maine that engaged in some extremely controversial practices: https://en.wikipedia.org/wiki/Élan_School

Not that I'm doubting any intentions here, but I think dressing this up as "extremely controversial" might be under-selling or burying the lede a bit. Had the practices (the ring, isolation, management structure) that occurred at Elan been done on adult prisoners, they would have with absolute moral certainty been seen as war crimes of the highest order. The fact that this happened to children and had the level of corruption and money behind it to persist for as long as it did should give one extreme pause, and the reprehensibility of the institution should not be "controversial," but rather condemned.

Indeed I would agree that this is really harrowing stuff. Just wanted to add that if you're going to look into this without any prior knowledge be sure that you're ready to be exposed to several levels of trauma.

North America does seem to like their cars, and is quite hellbent on finding any explanation for deaths caused by automobiles that absolves the system from having to take any responsibility or do anything (e.g. build infrastructure, regulate cars, etc.).

Of course, that's not to say that six school children being killed by motorists didn't happen after the time _didn't_ switch, but to pretend that the preceding week or two were materially different in terms of light / dark levels to the degree that driving was significantly more dangerous would mean we have to accept that certain hours at certain times of year are always more dangerous (and we should then enforce more restrictions on when one may drive).

If the idea that not switching to driving an hour later causes more dead children sounds preposterous, then DST seems to be a straw-man being propped up. More likely: there was general unhappiness about the change, and people were motivated to find a reason to repeal the law (and cars and bad car-centric planning came in to save the day). It's very easy to take the wind out of a political movement for change, but not necessarily to put them back in. I've been meaning to read Jessie Singer's new book [1], and this seems similar in that regard. Rather than acknowledge that our society has built things (e.g. bad infrastructure) that cause harm (six children died) we instead point at the problem and any attempt to make change anywhere in the system is looked down upon because that would be interacting with the problem, which makes you responsible for any effect of it down the line [2].

Overall, I think my take-away is that we know that shifting the clocks twice a year causes some non-zero amount of suffering (and doesn't have a large justification for _why_). Rather than "Chesterton's fence" ourselves into inaction, we shouldn't let past reasons dictate our choices here. There's surely a lot of overhead with regard to making this change (my heart goes to anyone who has to work with international date / time APIs), but even with knowing that I still don't think it's a bad idea. A unanimous vote by the US Senate surely says that there's some will towards doing this, since it's rare for anything to be this bi-partisan nowadays...

[1]: https://www.simonandschuster.com/books/There-Are-No-Accident... [2]: https://blog.jaibot.com/the-copenhagen-interpretation-of-eth...

If you can get used to applying Bayes Theorem in your head as a second nature, it helps greatly as a quick dummy check with reality. Obviously this doesn't mean calculating hundreds of probabilities in your head at once, but it can be very useful as a litmus test for all manner of things.

Knowing roughly what the value will come out to be if your priors are ~10, ~100, or ~1000x apart is very helpful when trying to discern if you're just being led down a wrong path.

Generally speaking doing Monte-Carlo simulations in your head would be nothing more than a stress test on your brain, but the simple multiplications and divisions used in reasoning under uncertainty can take you quite far, and with very little effort. You can even double check your work in the future if you really felt you did a bad job, and you'll be able to point out exactly where the error was (to yourselves or others) because it's more formalized than "I had a gut feeling."

It doesn't seem likely. Vaccines were mostly rolled out in the west (read: United States), whereas the initial variants (alpha and delta) were a result of COVID proliferation in unvaccinated areas. Delta, for example, first really blew up in India.

It is important to not forget the little details, and to avoid speculations based on broad statements (e.g. the vaccines "rolled out" and we got "more variants"). The vaccines started rolling out to very specific locations and we got variants everywhere.

Ariadne actually answers this in that thread: https://github.com/openssl/openssl/issues/16660#issuecomment...

I'll quote the section:

"Given that the OpenSSL 3 migration had an outcome where our contingency plan came into effect, I believe it to be the most prudent course of action to evaluate all possible options before committing to trying the OpenSSL 3 migration again, such an evaluation would be required by the TSC anyway."

The Alpine project operates independently from OpenSSL, so it's no surprise they published their own report to discuss their own timelines. I'm not sure I can attest to this being a "personal" reaction from my interpretation. Instead, this seems rather like the Alpine project's reaction to their own internal deadlines. Tossing out OpenSSL may appear flippant from a distance, but getting SSL correct for their own releases and finding projects that want to work alongside them (as LibreSSL is supposedly responsive towards doing) should be a priority if you're in charge of getting this work ticket over the line.

Of course, the wording and general attitude towards OpenSSL developers can be interpreted however you want, but I don't see this as outright hostility or a personal reaction so much as "this ticket was left for over a month, and our project needs to make forward progress."

Because the message format is different. In XMPP, the message is an XML document according to the message schema. In Matrix, it's JSON.

You can exchange the private keys, but using what format? Once that's done, you can encrypt XML on one side, but Matrix has to convert it into JSON on the other (in its own, separate format with its own fields). This can be done on the server side after decryption (no more E2EE), or on the client side (after decryption). In the latter case, you're not running a bridge anymore, you're just running an ad-hoc client for XMPP inside your matrix client.

It seems like you're trying to hold Element to some kind of impossible standard here. It's not like the tech they used to build the bridge didn't already exist.

The bridge itself serves a specific purpose (opening up Signal to the Matrix API, allowing for the use of a single app), and succeeds at that. Of course there's a trade-off, and the team (at least allegedly) appears to be working on encrypted bridges so that even if the bridge decrypts from Signal, it re-encrypts on the homeserver at rest in a way that only the user (not the bridge) can decrypt in the future.

I think the complaint here is "you advertised a service doing a thing that was already possible, people might use this." I may be mis-characterizing that, but I think it's worth stepping back and thinking a bit more on the actual threat model you face, and how the proposed product (Element One) somehow subverts that. Sure it can do so at scale, but that just means this is one incremental improvement that needs more work, not that the idea needs to be thrown out entirely.

There is a whole host of things this could be, but you may want to talk to your University IT and determine if they're doing any kind of port blocking, NAT blocking, etc. on the network.

Many campus networks are fairly restricted, often for a variety of reasons. IPSec / OpenVPN may get a pass because they're known exceptions, whereas Wireguard is new enough I'd not be surprised if your campus didn't move fast enough to include it as an exception.

The physical kill switches work as described, but yes, the phone is "too good to be true."

It will not (yet) replace your iPhone, although you can get pretty far on your own if you don't mind SSHing into such a device and messing with stuff on your own.

I am extremely skeptical of this. I think the best summary of why this isn't the story is provided by Zvi[1]. See the section "Delta Variant."

It's not something I can summarize in a couple short sentences, but the base rate of infections we're seeing from the actual data of delta infections doesn't match the 39% intuition at all. Additionally, the Israel Study seems to be thrown around a lot, but the data is suspicious if you look at our actual delta infection data from every other source.

In short, I think there's a lot of panic here that is being done by people who are looking at a single study.

[1]: https://thezvi.wordpress.com/2021/08/19/covid-8-19-cracking-...

Didn't _Alphabet_ buy Tenor (not Google)? It seems pedantic but it's probably the over-arching corporate structure that determines the distinction here.

Edit: Actually I kind of walk this back. I don't think Tenor has ever stopped providing the same service in an open manner (i.e. via their API), which would be needed to make the argument that there is a competition concern somehow.

I think a lot of the performance problems on the switch occur when you set the resolution of the device to anything outside a fixed 720p.

I've definitely had issues with 1st party titles, but after going into the settings and forcing 720p, some did go away. At the end of the day I mostly play my Switch in docked mode with an mClassic, so the forced 720p doesn't typically detract from the experience.

However, many 3rd party titles on the Switch are just actively bad ports. Omensight, for example, which is an otherwise good game has the most atrocious port I've ever seen on a console. I would agree with you that the thread parent is off-the-mark in saying that Valve will do worse here -- PC settings are notoriously better than what you get from traditional consoles since you can actively choose to optimize them to your environment, instead of hoping some developer took the time to even try.

Compiling custom versions of proton are somewhat a thing of the past already.

I installed Steam on Debian sid via Flathub / Flatpak, and then installed https://github.com/GloriousEggroll/proton-ge-custom using their flatpak instructions as well.

Honestly, it has never been easier to get a version of proton that makes gaming on linux seamless. Of course, I understand "run these terminal commands" is the usual defensive linux nerd^H^H^H^H coward's reaction, but installing Steam and this package from flatpak and then going from there is a _vast_ improvement from yester-years. I've been fairly happy with it, and I didn't have to do any actual compiling / building!

Usually the best bet is to use something like https://hn.algolia.com and search that way if you're looking for an actual HN post.

Otherwise Google does wonders here.

Ah yes, the part in my comment about dismissing matrix was in reference to the thread parent. Apologies if you thought that was directed at you.

I think the terminology you're looking for is "homeserver." Homeservers are tied to a single hostname / domain, but may be a collective of servers running the different services that comprise the protocol itself.

That said, you _do_ have to worry about spam from other homeservers, but that only matters if you have users from that other homeserver in your room. You can choose to federate / not-federate on a room-by-room basis, or just not federate at all ever.

Needless to say, you're right that it is a bit different than IRC in that regard (IRC can just kline hosts / IP ranges from the whole service if you're spamming). However, in practice there's a lot less instances of random spam such as in the article than you would think.

For myself, I never noticed any of these spammers at all (anectodal, so mileage may vary). I do have my own homeserver through Element Matrix Services, but I am part of a good number of rooms that exist purely on the Matrix.org server. Certainly I have to "police my users," but that's pretty easy since I run a small homeserver for ~5 users, and we just federate with the greater network when needed.

I guess I agree with you in general that there's different failure modes, but I don't think it's as simple as dismissing matrix because it "has the same spam problem as email" compared to IRC. In practice at least, it doesn't seem to be as much of a problem despite how much larger than IRC Matrix has become.

Because the same behaviour never exists on IRC?

All things considered, I can't say that the Matrix.org team responded slower than I've seen any IRCops respond. The main difference is you don't tend to see news about this happening on IRC as much anymore because IRC has had spam problems for decades, and there's hardly as many people who are out and about making it news.

Plus, for what its worth, most of us who run our own homeservers never encountered this issue at all, because public registration isn't open in the first place. It seems awfully dismissive to wave off Matrix for purely this one incident as it being "immature" as a protocol / platform.