The first iteration of the touch bar didn't have a physical escape key. I'm not even a VI user but that was my main complaint. I barely use function keys so I was ok with them being virtual (they showed up when I was in the terminal). But I did love adding a custom screenshot button to it and I loved the way the volume and brightness controls worked.
Does that mean that all the black holes of a particular volume have the same interior? Or does it mean that the black hole state is the case where you can’t tell what the interior is?
I don’t think there’s harm is speccing out the arbitrary encoding and then having a different spec that references that spec but puts hard limits on it. Many rfcs are like that.
I do too, but with an exception—if I’m going to emphasize the word “actual” I’ll say “thuh ACTual” but with a full stop after the “the” so that I can really chew on that first syllable for the emphasis.
I would transcribe the first sound of “unicorn” as “yoo“. It’s almost ee oo but the ee isn’t voiced—it starts right at the transition between those which is what the Y sound is.
I will check what particular settings I have for AdGuard when I get back home this evening. I don't recall anything particularly hairy but it has been a few years.
There‘s a checkbox called “Enhanced Protection” (name might vary, I have the app in another language) that specifically says it’s for stuff like YouTube
Not just that how the maintainer was treated by the attacker which tells you something about the way people feel entitled to maintainers time and efforts for nothing even by people not looking to exploit the project. And the abuse after he received despite it being an easy mistake that the culture encourages people to make.
> And the abuse after he received despite it being an easy mistake that the culture encourages people to make.
I believe that that was in part simply people defending their reality.
Because if it's not the maintainers fault, then why did it fail? What are the implications of that? What does it mean for me personally? Do I have to do something differently? Do I have to change my assumptions?
People do not like these feelings. They want to simply push them away.
The easiest way of doing so is blaming that guy and being done with the negative emotion.
Most people do suck at this whole "being human" business.
sqlx at least has the (optional) offline mode, where you "cargo sqlx prepare" once (which wants access to a db) and then you can build in offline mode which typechecks your queries against local files.
Although I suppose that's still doing a lot of shenanigans at compile time. It could be sandboxed pretty well (theoretically). I'd hate to give it up completely though, getting a compile time error when SELECT query params or return values have type mismatches is extremely nice.
sqlx offline mode being opt-in instead of default is what bothers me. You know what else can validate that your queries return what you expect? Integration tests. Shoutout to sqlx for #[sqlx::test] though.
I also wish that it would be the default. Integration tests are fine, but they aren't compile time. Elevating them to compile time and using an LSP enabled editor makes it just underline SQL errors before I've even had a chance to run a manual compile let alone a test...
LSP diagnostics is actually what made me switch from compile time check queries. Whole "is db up? are migrations applied?" dance tired me pretty quickly. Its fine if you use sqlite, but anything else gets annoying.
I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf).
Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.
I don't really agree. You reach for a dependency when you need to do something non-trivial and the stdlib doesn't have what you need (or the stdlib implementation is bad). You don't just sit around running `cargo search` for fun.
I think the ease of adding dependencies does drive the idea of "microdependencies", where you have many dependencies that do one little thing, and then those dependencies likely have their own small dependencies.
Whereas in the C world, you'll probably have a smaller number of dependencies, but it's likely that some of them are very big dependencies that offer a lot of functionality (like glib, for example).
I could maybe see the argument that ease of adding dependencies discourages people from writing small things themselves. Good ol' left-pad comes to mind. In an ecosystem like C, I'd just write that algorithm myself, over and over and over, because pulling in a dep just for that feels annoying.
> Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason
I disagree: having a big stdlib that encompasses a huge chunk of common functionality (logging, a plethora of network server/client protocols, etc) means that for basic needs, the question of 3rd party libs never arise, whereas for other language, the question is not if you need a dep, but which one. Making gorilla easier to find won't undo the cultural reluctance of adding a 3rd party dep when using the (very pragmatic, IMO) stdlib server is adequate to the task.
Perhaps, but I think it depends on where the Go devs are coming from. In my experience the lack of proper dependency management in older versions of Go didn't really lessen dependencies, it just made teams have to deal with annoying $GOSRC issues. But then I worked at a place where the devs used PHP (w/composer) and node before Go was introduced.
Personally I came from a C background so I tended to use deps more sparingly.
In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.
I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in.
It absolutely is a culture thing. I've seen many threads asking about backend frameworks in Go, and every time there were lots of answers akin to "screw framework dependencies, stdlib is more than enough".
reply