Threads for silby
-
Starts off pretentious and goes to the moon. Pretty woodworking, though.
-
I was that age once. I thought I knew it all.
Time has certainly humbled me.
-
-
-
One of the key benefits of zVisor is its use of the Zig programming language.
I am at this point completely fed up with the implementation language of a program being touted as a feature or “key benefit” of that program. Microsoft GitHub encourages this behavior because if you want your repo to attract contributors or certain flavors of users it probably helps your SEO to put the language in your description. But the choice of language is a developer benefit, not a user benefit. Crowing that you’re wise enough to use Haskell/Zig/Go/Rust/C/TypeScript or whatever else before you explain what your program does makes me feel like your core audience is other people who think your language is the good one, not people who want to use your software to get something done.
-
-
Interestingly, my first thought seeing such things is indeed “Why?”, because there are already tons of implementations and for the hypervisor part they are basically mostly wrapping the KVM interface that is readily available in Linux and by the means of an ABI available to any programming language.
Otoh, I totally appreciate people exploring reinventing the wheel to learn more about wheels. And then you get way too excited about how round your wheel is in comparison to others. Human behavior.
-
-
That’s exactly the problem with this kind of thing, it entirely lacks the nuance of the real world and instead talks in absolutes.
Does Zig have better spatial memory safety than C? Yes it does, slices and pervasive bounds checking make a big difference here.
Is Zig as memory safe as something with a garbage collector? No, at least not in its present state.
-
-
I am skeptical of any language that makes the following two claims:
- Can be used to implement a hypervisor
- Is memory safe
A hypervisor manipulates address translation. It deals with things below the level of an abstract machine that provides an object model (memory-safe or not). You cannot have both properties in the same language. Pick one.
-
-
-
-
But the choice of language is a developer benefit, not a user benefit.
Are the users of a hypervisor so lacking in technical skills?
I’m far more interested in tools I can modify and extend (without significant effort) than in tools I can’t. Being written in any of the ten or so languages I can already use is a big plus.
-
-
-
I’m not going to make a forecast of how successful this social network will be but I will note that rather than a screenshot on the landing page there is a JSON blob.
-
I also think that public/private key pairs are too tough of a concept to drop on non-technical users. It took me a while to understand them, I still don’t really grok them, and I’ve been programming for over a decade.
I think they can be a great building block, but they need a better face. Like HTTP is good for what it does, but we still slap a browser on top of it, for it to actually be used. No one (except Stallman, maybe) goes around browsing the web with curl.
-
-
the problems that Rust is designed to avoid can be solved in other ways — by good testing, good linting, good code review, and good monitoring
This stuck out to me, as the four things the author mentions here are the exact things that have always been in short supply in my current line of work, on under-resourced teams at a public sector employer. Obviously Rust is not the only productive language out there offering good compile-time guarantees and the firm guiding hand of a type system, but in general I wonder if “just let me crush code and we’ll
fix it in postcatch the issues in the test suite/CR” isn’t an abundance mindset. I frequently have to fix things (in Python or Perl or JavaScript) where nobody including me has looked at the code in 3 or more years and there are no tests; I’d give my kingdom formypy --stricton those occasions.
-
Coincidentally, those are the names of my daughters.
-
-
Too bad the binary name conflicts with another essential Unix tool
-
-
-
-
It also speaks volumes about their culture, completely absent of Unix hacking tradition.
One never knows, I might be wrong here, but I don’t see this sapling ever becoming a full grown tree. Successful universally accepted projects have succeeded because they nail a specific solution to a well understood problem and offer a clear direct ovcoua benefit to the user drom day one. I don’t think this is the case here.
-
-
-
I think I had always assumed it referred to a small stamped label plate affixed to a boiler, like something with a maker and serial number on it. Hillel once again demonstrates the power of actually looking something up.
-
We might have chosen CommonMark as a baseline, except GFM supports tables, which we knew we needed.
Honestly it’s pretty sad that CommonMark doesn’t have this. :C
-
-
Plaintiffs estimate that statutory damages for Defendants’ direct violations of DMCA Section 24 1202 alone will exceed $9,000,000,000.
Whoops!
-
I’m loving the irony of legislation as bad as the DMCA being used against those who lobbied for it in the first place, and continued to support it in subsequent years. See e.g.:
The hypocrisy here is stomach-turning.
-
Even if the plaintiffs absolutely win every single aspect of the case, they’re not going to get a judgment for that amount. Every lawsuit starts out setting a ludicrously high demand for damages, because generally that number can only be pushed down as the case goes on, not up.
Or more simply: it’s like those news stories that say someone is potentially facing some ludicrous number of years in prison in a criminal case, when that number comes from literally maxing out the severity and sentencing range of all the charges. The prosecutor knows that’s not the sentence that would happen even if the case went perfectly.
-
If they win on all their claims I don’t think 9b seems out of the question as a reward. It’s high, but not ridiculously so.
I take issue with how that number was calculated, but in a less lopsided manner than I would for most damage claims. They’re multiplying a statutory minimum by an estimate on the number of infringements. They estimate that each user (going off of a June 2022 claim by GitHub) infringed an averaged of 3 times… which doesn’t seem unreasonable. The justification for that estimate is based on a “1 infringing output * it counts 3 times”, which I doubt, but it turning out that each user had >= 3 infringing outputs doesn’t seem out of the question to me. I suspect the statutory minimum award really is a minimum reward, if the case goes to trial, too.
That’s also before considering awards for their other claims.
-
-
-
Excellent, another markup language. I’m sure this time it’ll be the well-thought-out, well-supported, properly specified solution we’ve all been waiting for.
-
John McFarlane has been developing pandoc for nigh-on forever now and leading the CommonMark project for half of forever so if one were to nominate a single individual for the task of building a well-thought-out and properly-specified markup language of this type, one would struggle to pick a better candidate than he.
-
Can’t argue with that.
-
-
-
There is no standard way to iterate over a sequence of values in Go.
Go was publicly announced in November 2009, and version 1.0 was released in March 2012.
I can’t help but feel like something went badly wrong here but what do I know.
-
These types of comments really drive me up a wall. It feels like what you are saying is “this is a common feature in other languages, the people behind Go (vague bad thing) since they didn’t add the feature too” which is just not sound reasoning.
In order to form a judgement about how bad something is, we should consider the consequences of it. The “normalness” of a behavior is an OK pointer, but thats all it is.
Maybe you can argue that the consequences have been grave and thus this is a grave failure, but that doesn’t seem true to me.
-
I can’t argue that any of the things about Go’s design that people have been unproductively grouchy about in comments sections for the past decade have had grave consequences for any given Go adopter or for the widespread adoption of Go. Having written one short program in Go for my own purposes, the lack of a proper idiomatic iteration construct (no map, no iterating for loop, no list comprehension, no yielding to a block, just the apparently-hacky for-range) was flummoxing. Go’s designers are entitled to their priorities but idk I feel like I’m entitled to make fun of those priorities a little bit, especially because they get paid more than I do.
-
IMO there is a solid iteration idiom, and they hit on it early in the stdlib, although the fact that they managed to do it several different ways afterwards is a disappointment. It’s the
for iter.Next() { item := iter.Val() // ... }one. You can do pretty much anything with it, it doesn’t impose any burden on the caller, it doesn’t make the caller ugly, and you can implement it on top of pretty much anything else. With generics you could even codify it as an interface (parameterized on the return type of
Val).None of which is to say that I opposite this proposal — it looks pretty nice to me. But in 7+ years of writing Go professionally, the lack of an iterator syntax hasn’t been a major thorn in my side — or even a substantial annoyance.
-
-
-
I’m pretty sure Zig has no concept of iterators either
https://ziglang.org/documentation/master/
I saw in the latest blog that the Zig for loop is being changed, but AFAIK there will still be no iterators. You basically do what you do in Go – write your own set of methods on a struct.
So it seems like Zig will be a ~2025 language without iterators
I would say languages have different priorities, and it’s harder than you think. Or you could just make vague statements about people doing bad things for no reason
(edit: this bug seems to confirm what I thought https://github.com/ziglang/zig/issues/6185)
-
Zig deliberately has no interfaces or traits whatsoever. You put the methods in the struct and they get called and it will compile if and only if the types work out after comptime propagation. I might be wrong but as far as I understand “iterators” in the language will be a bit of syntax sugar relying on a documented (but informal) interface, and Zig will very much have iterators exactly like, say, Julia or JavaScript or Python have iterators (except those languages check if things work out at runtime instead of compile time).
On the other hand the major selling point of Go is having interfaces enforced by the compiler. But a fast iteration interface needs to be a generic interface so that wasn’t really possible until recently…
Hopefully it all works out on both fronts.
-
Eh I don’t see what you’re saying. My point is that, as of now, Go and Zig are the same as far as iterators.
As of ~2025, Go might have iterators, and Zig probably won’t. Go is thinking about adding some concept of iterators to the language to enforce consistency.
Python’s for loop and list comprehensions understand iterators; I don’t think the same is true of Zig.
If you know otherwise, please provide a link to the docs.
-
-
-
The dominating quality of Go’s development over the past decade has been the most extreme caution when it came to adding features. You can’t have performant, extensible iteration without some kind of generics and they were stuck in place on that issue out of fear of C++ compile times until finally a couple of years ago.
-
You can’t have performant, extensible iteration without some kind of generics
It’s even stronger than that: if you do want to map’n’filter, you need a boatload of machinery inside the compiler to make that fast, in addition to significant amount of machinery to make it expressible at all.
Rust’s signature for map is roughly
trait Iterator { type Item; fn map<T, F>(self, f: F) -> Map<Self, F> where F: FnMut(Self::Item) -> B; }That is,
.mapreturns a struct, calledMap, which is parameterized by the type of the original iteratorSelf, as well as the type of unnameable closureF. Meditating on this single example for a long time explains half of why Rust looks the way it does.
-
-
Go’s developers focused on higher priority concerns, such as pretty great performance, a pretty great (though basic) type system, an awesome runtime and compilation model, and fantastic tooling. Go’s feature set (including the features it elided) made developers really, really productive compared with other languages.
While there are a few use cases that weren’t feasible without generics, the absence of generics made for some really interesting and compelling properties–like “everyone writes their code the same way (and thus any developer can jump into any other project and be immediately productive)” and “code is very concrete; people don’t usually try to make things overly abstract” which aren’t present in other languages. It wasn’t actually as obvious that generics were the right choice as Go’s critics claim (whose analyses flatly pretended as though there were no disadvantages to generics).
The net upside to generics (including iterators) was relatively small, so it makes sense that the decision was deferred.
-
-
Google doesn’t really figure in at this level of discussion. The Plan 9 guys who made Go are the relevant actors for this. They were skeptical of generics, so it wasn’t a priority for Go 1.0. With no generics, a generic iterator protocol doesn’t make any sense, so that wasn’t in Go 1.0 either. Now Go has generics as of Feb. 2022, so there is a discussion about the best way to do an iterator protocol. This is the second proposal, which builds off of ideas from the first discussion and some ideas that had been in the issues tracker before that. It’s not really more complicated than that.
-
You’re obviously right that the decision making an process is entirely about Google’s desires, but I’d hesitate to assume that it’s necessarily utilitarian. Google does a lot of self-sabotage.
-
-
-
After having to deal with Rust iteration for a bit and missing out on Python…. I think the decent explanation here is that in more dynamic languages with stuff like coroutines it’s pretty easy to come up with a nice iterator protocol, but in more serious things it’s harder to come up with one that is both flexible enough for the “right” use cases without being very hard to use.
Like C++ has iterators right? And they do the job but they’re kind of miserable to use (or at least were 5+ years back, I’m sure things are better now).
Combine that with the perrenial generics things meaning container classes aren’t a thing and “stuff things into arrays and use indices” feels like a pretty OK solution for a long time.
-
I think C++ iterators are uniquely awkward in their design, and it’s not an inherent design problem or any sort of static typing limitation.
C++ iterators are based around emulating pointer arithmetic with operator overloading, with a state awkwardly split between two objects. There’s no reason to do it this way other than homage to C and a former lack of
forloop syntax sugar.And C++ iterators aren’t merely tasked with iterating over a set once from start to finish, but double as a general-purpose description of a collection, which needlessly makes both roles harder.
-
There’s no reason to do it this way other than homage to C and a former lack of for loop syntax sugar.
I think this is a little unfair, the primary reason to do it this way is so that code, especially templates work on pointers or iterators, eg being able to have a single implementation for something like
std::findwork for list or pointers. It’s not a “homage” so much as a source level interoperability consideration.-
OK, “homage” is a poor way of phrasing it. But it’s still an “interoperability consideration” with pointer arithmetic and C’s way of doing things, rather than a ground-up iterator design. The messy end result is not because iteration is such a hard problem, but because preserving C legacy is messy.
-
-
-
-
-
-
-
More great stuff for the world’s greatest database!
-
I’m super glad modern runtimes and programming languages are supporting this model more readily, but wow do I dislike the “The FUTURE of $X is $Y” taglines :(
Although the arguments in the article make good sense to me, I also am not wild about how such a trend would further erode the ability of a single human with a limited budget to serve content and applications.
“The future of the web is CloudFlare” <- Makes me a sad panda.
-
-
In short this guy (and his company) is forking SQLite, and wants to become a popular fork that is the hub for contributions. Good luck!
-
-
-
-
Linux, Python, nginx, apache, PHP, openssl, curl, Chrome, Firefox. All widely deployed, if not as much as SQLite, at least in the same order of magnitude, and all much more open to contribution.
Saying that SQLite is successful and stable thanks to not accepting contributions is extrapolating from pretty much a sample of one.
-
You’re not wrong, but it’s amusing to point out that there are, I think, a lot more copies of sqlite in the world than Linux. For instance, every Android phone will ship with at least one copy of sqlite, and then probably pick up more independent copies in apps that bundle it instead of using a system copy. iPhones will end up with an even higher sqlite-to-Linux ratio! ;)
-
-
Yes! I brought Android up because every Android comes with one copy of Linux but probably several copies of sqlite. 😊
-
-
-
-
-
-
-
Hot.
-
-
Oh my god at last, the last thing I needed to never have to actually visit github dot com again. (To a point anyway.)
-
It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content.
Why does everyone hate underlines?
-
well, in the web context, “Links should look like links, and nothing else should”, and more often than not links are underlined. And apart from that, using underlines for emphasis or other typographical purposes is discouraged by most authorities. Using up an ascii punctuation character for underlining would be a mistake imo.
-
-
I hope it doesn’t all boil down to incentives and the difficulty of measuring impact.
Narrator voice: it does.
-
Pamela Fox demonstrates in this rare display of developer humility that one needn’t be a power user of their editor to get stuff done. I appreciate that, especially in contrast to the evasions of past guests who can’t seem to admit that they actually have any practices that they would personally cop to being bad.
Setting that aside, though, I’m trying to understand the advantage of (neo)vi(m) keybindings over the conventions of GUI text editing contexts. For example, on a Mac, command+arrow takes you to the beginning or end of a line (horizontally) or document (vertically). Option lets you move by word. Doing any of that and adding the shift key selects text. IIRC, Windows has similar equivalents. Combine those keyboard conventions with the command palette and multiple-select patterns popularized by Sublime Text and you have a pretty efficient workflow with a much shallower learning curve. I can imagine if a good portion of your day is spent in an environment without a GUI, it would make sense to get pretty good at vim or emacs, but I would genuinely like to know, what is the case for GUI users to learn vim deeply?
I’m sure there’s no particularly good argument in favor of it, and I no longer actually recommend it to anyone, but having typed
vimtutorone day 18 years ago, I’m too far gone to learn anything else. If you go throughvimtutorand that’s not the path your life takes you’ll probably end up happier and better-adjusted than I am.I was a GUI user, but switched to vim(likes) for accessibility reasons.
So for me it’s not about what I can do, but how. I can do everything in my entire setup and never have to press more than one key per hand at a time, and rarely have to hold a modifier key at all.
My editor, web browser, window manager, email client, etc etc all work like that.
But yeah, I would never really recommend any of this to anyone who doesn’t need it.
I think I can relate to that. Started using touch input and key-navigation because I had to reduce the wrist pain from using a mouse.
Another vote for accessibility here. I have cerebral palsy and was developing wrist pain when using modifier keys. I switched to a vim layout and made extensive customisations to eliminate the need for modifier keys. This is purely anecdotal, but the problems have not recurred since I made these changes.
I really need to do a full post on this, but some of the specific vim motions i miss in vscode:
vi{char}selects everything inside a quote/parenthesis/curly braces/sentence."Ayappends your selection to theacopy-register, which makes it easy to go through and collect a bunch of different little things to paste all at oncezflets you create new ad hoc folds over arbitray parts of the fileguulowercases the entire lineEach one is those is only a small boost to my productivity, but when I have 200 small boosts it adds up. That said, I avoid vim emulation in other editors. It’s easier for me to switch between two sets of muscle memory if they’re very different.
I’d love to read it. You have a great blog. Based on this summary alone, I’m not sure how or if I would use these features, but perhaps if I could see how you use them, in other words, in what context, that would be very interesting.
Have you tried reporting those? I got some vi behaviours fixed that way. vi(char) may be easy to add since I remember using di(char) and that worked fine.
Vim lets you use ctrl+arrow to jump by words as well. Useful in insert mode when you do not want to go back to the command mode for some reason. People should be able to discover that just by muscle memory, so it’s somewhat awkward that she did not stumble upon it. Yikes.
Vim’s [v]isual mode lets you move around your cursor to prepare a selection (instead of holding shift all the time) and then [d]elete it, [y]ank to [p]aste elsewhere. Among other possibilities. She would probably like it, since you can e.g. search using slash to locate where you want to place the end of the selection.
Or on a one uses Pos 1, End, Ctrl, etc. when hot on an Apple device.
I think they are just good, proper Editors of which there aaactually see rest few, GUI or not. They’re usually slow, resource hungry, inflexible, hard to impossible to configure, lack features one wants or just have but been designed well. Sometimes they suffer from instability, as in new versions (minor or major) breaking things.
That’s a general theme with software. It also applies to editors of course and when you have something reliable then you stick with it. For many people that’s something like vim or emacs.
It’s often the first editor that’s “good enough”. And if you are at any time SSH into something chances are you get to learn vim or nvi in the end. Even if nowadays some systems have other defaults. They tend to not be really great.
And once you know it you end up using it locally now and then, then it becomes a habit.
I think it’s easy to overestimate how much choice there is when you have a few requirements for editors.