Vendan

Pretty sure they are talking about https://code.visualstudio.com/docs/remote/containers

I wasn't aware of all that, thanks, but I still think that Apple's stuff is a whole different ballgame.

Google gatekeeps by default but you can trivially bypass and install custom app stores or sideload apps. Apple gatekeeps, and does everything in its power to prevent you from bypassing that. Seems like a rather striking difference...

It seems to not be considering "can it reach a temperature", but "how much heat can it remove in 3 minutes", which, IMO, considering constant power usage, is more valuable for "how efficient is this"

Windows task bar can pin things to always be on it, even if it's not running, as well

Good news, there is! It's called a database. When an item comes in, tag it with a unique barcode and add a row to the database saying "Item X came from company Y in shipment Z" and then sue/penalize/whatever company Y when it's counterfeit.

The unmoddable ones are mostly there cause they are big names or old names. I mean, heck, LoL was literally inspired by how moddable Warcraft 3 was. If you aren't using a massively well known source material, and you don't have a AAA game studio, your main chance to make a big game according to that list seems like either moddability or cheesy facebook game tactics.

You do realize, exposing the "inner workings of the game" seems to be at least somewhat responsible for massively increasing the appeal of the game in other cases? see Minecraft, Rimworld, KSP as a few examples...

The SSB issue with json is that it plays with the json after signing it. Just don't do that.

I tried, and tried, and tried to make that library for Go. I failed, cause of serialization issues too involved for it to be worth it to me (got to the point where I'd have to write my own json implementation)

Just giving people the heads-up that JS seemingly is the only blessed language for scuttlebutt

Just serialize, sign, pack the signature and the raw bytes of the serialization. Doesn't matter how, just gotta pack the raw bytes, not futz with it

Scuttlebutt is a neat concept, burdened by a bad protocol. Signing a message involves serializing a json object, signing it, adding the signature as a field on that json object, and then serializing it again. To verify, you deserialize the message into an object, remove the signature field, and then reserialize it, and verify the signature against that new serialization. This means that all the clients have to have a json serialization that 100% matches the node.js serialization that the majority (totality?) of current clients use. Any other implementation (I wrote one in Go) becomes a nightmare of chasing rarer and rarer differences that prevent verification, and if you miss one before you serialize your own message with it, suddenly you've poisoned your own journal...

All in all, it's something to study and learn from, but I strongly recommend not becoming involved unless you are 100% happy with being tied into node.js.

Please don't, it makes it annoying/hard to read on mobile( it doesn't wrap)

Interestingly, the one time I introduced someone to Go without really "realizing" it (during a coding interview, got to pick the language I used), his first comment was actually that he liked how explict the error return was. (strconv.Atoi, to be specific). That pretty much sums it all up to me: `if err != nil` seems like annoying boilerplate, but then when you see stuff that's not just doing `return err` inside that conditional, you realize that it can actually be a benefit.

Linters aren't bad (Go basically has one as `go vet` that checks for all kinds of "this is probably wrong", like the common "closing over a loop variable")

Warnings are bad, specifically when the warning is unambiguous (importing a package you aren't using is always wrong, though it makes debugging frustrating at times) The idea is that warnings that don't "stop" the build generally get ignored. Build most non-trivial C++ projects and count how many warnings flow past the top of your screen for an example of what they were trying to prevent.

goroutines (and the go keyword) are the primitive, just like async is the primitive for python. Something like golang.org/x/sync/errgroup gives Go the same kind of "nursery" concept and can be leveraged almost identically (modulo Go not having the "with" concept, but defer can play the same role)

You can go pretty darn far with CSS if you are ok with multiple divs...

https://diana-adrianne.com/purecss-francine/

Bazel is the king of parallel builds though, at work we can spread out 100 actions wide across across a cluster of machines, and the only reason it's that small is we have no real need to go wider...

Why do you think OnStar doesn't have access to the can bus https://news.ycombinator.com/item?id=10008228

If it's not obfuscated, you can get a pretty good dump of a c# binary's source with a decompiler. Some variable names may be missing (local variables and such) and some constructs may be awkward (generator/iterator stuff) but it's usable.

Go does put that goroutine to sleep, freeing the underlying OS thread to work on other goroutines, so it's very lightweight.

Goroutines are scheduled onto system threads via M:N greenthreading. Each "system" thread can steal work from other threads, and there's some stuff so that blocking system calls don't use up your "goroutine system threads" (you can put a limit on the number of goroutines that run concurrently). Channels are fixed size on creation, either 0 (directly handing off items from 1 goroutine to another) or >0 (the channel has space allocated to hold that many items). If the channel is full(buffered, i.e. >0 size channel) or there's nothing waiting to receive the item(unbuffered channel), the sender sleeps until it can send the item. Channels are purely data structure, have as many as you want. You can lock the system fairly trivially, but Go can detect it in many cases and give you stack traces of all the places stuff is waiting to read/write (only if all goroutines deadlock).

edit: And no, there's nothing really special about channels, just they play nice with the goroutine scheduler, so it's perfectly sensible to do lots of "wait on these channels" stuff inside your program, without having to have lots of OS threads and such. (goroutines are a bit more lightweight then OS threads)

> Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.

That's still just an argument for "everyone use a specific formatter with these settings". Go's formatting is simple, built into the main implementation, and has no knobs, as a result, everyone uses it, and all code is formatted with tabs and spaces. It can work, esp. if a language adopts it early (like Zig could have).

Visual studio does it for C#, at the very least. Other formatters choose other options, and it's a matter of preference in any case (I personally think it's a code smell to have that many arguments or that long of names, and I also don't limit myself to 80 columns, cause I've got a widescreen monitor)

Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments("), add that many spaces after your indentation tabs on the next line, continue arguments. The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.

The simple fact remains that using tabs provides many accessibility benefits that spaces are just unable to provide, like being able to drop tab size when you boost font size (legibility for poor vision) so your code doesn't indent off the side of the screen, or far better support for indentation for proportional fonts (another thing that people swear by for increasing legibility).

So then it's the editor that's at fault. Most editors let you do a "run formatter on save", and zig has(had? at least it did last I played with it) a formatter that can do correct "indent with tabs and align with spaces" with only a minor tweak

    The battery life of the Light Phone II is approximately 1-3 days of 'light' regular usage.

So yeah, battery life is not that great for what it is...

Most common malware is on windows (think IE browser bars and such).

As far as the zoom issue, that's just one specific instance that came to mind. Yes, with a proper package manager (like aptitude) that's managing all the files, you are much less likely to have these kinds of things, so yay linux. On the flip side, most consumer OS's (windows/mac) don't go in for that kind of package management, usually relying on the app to be in a single place or have a packaged "uninstall".

As far as the specifics of the zoom problem, it's definitely not a chrome issue, as it's a standalone web server running locally, not a url protocol handler. And it's not quite an OS issue, other than that the OS allowed it.

>Also removal of the app guarantees removal

My experience with malware would strongly disagree. Heck, even non-malicious programs have been known to stick around after uninstall (https://apple.stackexchange.com/questions/358651/unable-to-c...).

One way to work around that is to use interfaces (https://play.golang.org/p/aAEAi8GvDkv), but either way, you are "shadowing" the type, and can no longer use the .TraceID in the second function cause it's just a plain error at that point.

Speak for yourself, Go is a bastion of formatting sanity for me cause they chose (correctly) to use tabs. Tabs for indentation are the obvious choice to improve code readability and accessibility for people that want different indent sizes. I don't need it (usually), but I've met people that prefer everything from 2, 4 or 8 spaces, and have heard of people wanting everything from 1 to 8. It also handles far more sanely then spaces for people using proportional fonts instead of monospace, another common readability/accessibility tweak.