Go sits at about the same level of abstraction as Python or Java, just with less OO baked in. I'm not sure where go's reputation as "low-level" comes from. I'd be curious to hear why that's the category you think of it in?
I'd argue that Go is somewhere in between static C and memory safe VM languages, because the compiler always tries to "monomorphize" everything as much as possible.
Generic methods are somewhat an antipattern to how the language was designed from the start. That is kind of the reason they're not there yet, because Go maintainers don't want boxing in their runtime, and also don't want compile time expansions (or JIT compilation for that matter).
So I'd argue that this way of handling compilation is more low level than other VM based languages where almost everything is JITed now.
I happen to work at a company that uses a ton of capnp internally and this is the first time I've seen it mentioned much outside of here. Would you mind describing what about it you think would make it a good fit for something like bcachefs?
Cap'n proto is basically a schema language that gets you a well defined in-memory representation that's just as good as if you were writing C structs by hand (laboriously avoiding silent padding, carefully using types with well defined sizes) - without all the silent pitfalls of doing it manually in C.
It's extremely well thought out, it's minimalist in all the right ways; I've found the features and optimizations it has to be things that are borne out of real experience that you would want end up building yourself in any real world system.
E.g. it gives you the ability to add new fields without breaking compatibility. That's the right way to approach forwards/backwards compatibility, and it's what I do in bcachefs and if we'd been able to just use cap'n proto it would've taken out a lot of manual fiddly work.
The only blocker to using it more widely in my own code is that it's not sufficiently ergonomic in Rust - Rust needs lenses, from Swift.
That is not true. A topological taurus can be flat or not.
A physical taurus embedded in our 3D universe, i.e. a donut, cannot be flat. Which may be the confusion.
But video game spaces are neither logically embedded or restricted by our 3D space. All its physics, including its spacial topology and geometry, flat or otherwise, were completely up to the game designers.
And the Asteroid game designers chose a flat space.
• Two parallel line segments stay parallel, no matter how long you extend them. Or how many times they wrap around the Asteroid space. (They also never intersect, but can overlap, just as in any flat 2D space.)
• Any number and distance of moves in any two perpendicular directions, are commutative. I.e. you can change the order of the moves, and you will still end up at the same spot.
• The three angles of any triangle in Asteroid space adds up to 180 degrees.
> a change in a leaf function in a little file in a random helper module could introduce asynchronocity which propagates all the way up to your `pub fn main`
If this doesn't make the argument that Zig has certainly not defeated function coloring, I don't know what would.
The fact that this change to how my program runs is hidden away in the compiler instead of somewhere visible is not an improvement.
> If this doesn't make the argument that Zig has certainly not defeated function coloring, I don't know what would.
if you're opting into stackless coroutines then yeah you're opting into their viral nature, but the point is that you don't have to. as the application author your dependencies won't opt you forcefully in using stackless coroutines (or any singular execution model), which is currently the case with other languages.
this is what it means to defeat function coloring.
Small marketing suggestion: maybe "limit function coloring" instead of "defeat function coloring". I like Zig's approach so far, but clearer terms would help avoid pointless arguments and disappointments that a certain proglang supremacist community loves.
If information is important enough to bother someone asking for a copy of it, but not important enough to spend an hour ingesting, I'm not sure what to tell you.
The thing is: When working with the material afterwards the important part are the small details. The talk/recording are good for the high level overview and following along on the big picture, but for details it is annoying as one has to jump around for specific words and phrases. Something written or an image/diagram is a lot better to study in depth.
And there lies the trouble with slides: During a talk they should support what is being said, but they are often abused as also being the handout for afterwards.
It sounds like you want detailed documentation. That’s fine, but that’s not what a talk is. A good talk isn’t a reference. And good documentation isn’t an engaging talk.
If people want that, produce two artifacts. Don’t try shoehorn a talk into being documentation. That’s just a recipe for bad work.
It depends on what the talk is about. Of course Steve Jobs' of cited iPhone introduction didn't have any details for in depth research later on, but was a high level product introduction.
A technical talk however explains a concept, a tool or something and thus contains technical information to follow up with, but for that I need the words, the phrases stated so I even know what to look for in the manual. And probably I want to follow it in the order they presented it (I hope they thought about the order they presented it in!) however the manual is ordered more in a reference order.
So yeah, if you do a high level marketing talk it doesn't matter, but then I also won't spend the time on watching a second time. If it has technical depth, then being able to follow the depth is good.
I have dealt with this issue as well before. If folks need something more in depth I will use a LLM + some massaging of my own to create a supporting document. Here is an example of a very disorganized conversation and the supporting document I made with it: https://www.danielvanzant.com/p/what-does-the-structure-of-l... It has clear definitions of the key terms. Timestamps for the important moments, and links to external resources to learn more about any of the topics.
For most talks, I would say no. If I were going to a lecture by Pynchon (ha!) I would want to listen at 1x. For 99% of talks at conferences which are mostly just a way of communicating technical data, a text transcription that is then reduced in word count by 50% is probably only a very small loss (if that), and a 90%+ time savings.
This gives me an idea for a website. All of the talks of a conference, audio transcribed and LLM summarized into 3-minute reads.
It might be worth doing the whole INFOCON archive…
The slices of a good presentation are worthless without the presentation itself. If the deck is valuable in and of itself, it could have just been an email or word doc in the first place.
Well, it's not the reality of most slides I've seen. Most of them seem to be a pretty good summary of the talk. Weirdly, some of them contain more information than the talk.
I do believe most presentations I've seen could've been an email or an article. So I guess I agree with you?
> I do believe most presentations I've seen could've been an email or an article. So I guess I agree with you?
Yeah, I really should have said that in my original post. Most presentations could have been a one pager, and any presentation worth sitting through the slides aren't worth having.
Always recording is a good practice I think. It's so cheap with video conferencing that you might as well. Even if nobody uses it later, it didn't cost much. And if you get that one presentation that provides stellar value it's a gift that keeps on giving.
I don't really agree that a recording is always better than the slides. Slides are a text medium, and as such can be searched. You can also go through them much, much faster than through a recording (even if you can listen at 2x). If you're just looking for something specific, slides can be much better.
And sometimes you need to get the whole experience. And then the recording is much better.
Hosting and operating the autoscaling of the various services (compute, pageserver, safekeeper, storage broker) that it takes to make all that work is complex enough that most folks would rather not. Same as any other "managed X" service.
This is the exact same attitude as people who threw tantrums about seatbelt laws in the 90s. It was wrong then, and it's wrong now. For mostly the same reasons.
Even when compiling in Debug mode! Where the analogy is closer to a friend who's applying for a cashier job asking you to role play being a customer so they could practice, and then spitting in your face when you go "Hey, Joe! I'll take these" because "No real life customer would do that! Start over."
> Even when compiling in Debug mode! closer to a friend asking you to role play being a customer so they could practice, and then spitting in your face saying "No customer would do that! Start over."
If we're going to go with the seatbelt comparison then we'd have to flesh it out a bit:
Your new car sounds an alarm non-stop if any seat belt in the car is unfastened, whether or not a seat is occupied and whether or not the car is even on. This seems kind of silly, so you raise it with the manufacturer and they say that standard procedure is to just leave all seat belts fastened all the time.
You start doing that and quickly realize that it's much harder to remember to put your seat belt on than it was in your old car, because the car doesn't warn you when you've forgotten your seat belt and when you do remember on your own you have to sit up awkwardly to unfasten it before you can get under it and fasten it around you. You point this out to some fans of the manufacturer and they act like you're the weird one for not seeing how this makes you safer.
> Seatbelt laws are still wrong, government has no business protecting me from myself.
If there are multiple people in a car and some choose to wear seatbelts and some choose not to, those who are not wearing seatbelts become a danger to everyone else as their bodies become in-vehicle projectiles.
Sure, I can understand the debate when it's just a single person in a car. But when a person's decision starts impacting others the debate is going to be very hard to win.
Even if it’s just you, you’d be leaving your mangled corpse on a public road for other people to deal with, which is a nuisance.
Like take the car crash out of the equation and imagine some cars came with an ejector switch that launches you through the windshield at 70 mph. This would not be allowed.
It also protects innocent bystanders from being forced to see your horrifyingly mangled body tossed on the ground in front of them in what could otherwise have either been a crash with no injuries, minimized injuries, or at least contained injuries. Do you still think that law is overstep, if so why? Genuine question,
I have no horse in this race and am on the fence myself.
Because any restriction of freedom is bad in principle and acceptance of those tend to create overreaching, totalitarian states/mafias. There are valid arguments for restricting freedom from an individual to harm another, but making sure no one can see your dead body right after you happen to crash your car definitely isn't one. It is very much infeasible and an absolute helicopter mom type of concern.
Keeping with the analogy, yes, you should always wear your seatbelt on public roads (release), but that doesn't mean I feel like I need to buckle up just to move my car while staying in my own driveway (debug).
That's reasonable. I think major restrictions that cause you to need to refactor your code when going from debug to release are a footgun and a half, but that'd at least be defensible.
So proud of all the HN denizens that none of us asked lvass about their stance on mandatory baby seats in cars. Or those bars they use to pin you down in your car on roller coasters.
Most hardware-level observations, like the latency of various memory accesses or numeric operations, would be the same for the Rust code. As for higher-level abstractions, I've already started porting them to Rust <https://github.com/ashvardanian/less_slow.rs>.
Next, it would be exciting to implement a concurrent job-stealing graph algorithm in both languages to get a feel for their ergonomics in non-trivial problems. I can imagine it looks very different in Rust and C++, but before I get there, I'm looking for best practices for implementing nested associative containers with shared stateful allocators in Rust.
I’m definitely interested in seeing this kind of content in Rust, have you looked at Rayon’s implementation for work stealing yet? Can result in some very nice high-level code.
