> in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust
imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.
Completely agree! The author made a buggy android port of nintype (called keyboard 69) that I used for years. The UX was incredible, and every swipe system I've tried since feels downright clumsy by comparison. Two finger swipe is peak ergonomics, but unfortunately I think it's an innovation that's simply too niche.
I find matplotlib to be clunky and verbose compared to ggplot. When using python, I will often use https://plotnine.org/ because it gives me a nice ggplot like API.
Even taking the author's criticism about large context windows for granted, which in my experience are exaggerated, they are still a huge UX improvement over short windows. That reason alone is enough for me to support them.
Feel free dismiss my option by assuming I'm some ignoramus that doesn't know anything about how databases work.
I'm well aware of the underlying challenges that SQL provides convenient abstractions over, and what I'm saying is that it actually isn't all that helpful for complex use cases unless you know a decent amount about dbs; which at that point, I'd rather program against a thinner
, less abstract persistence API.
The flip-side of what you've stated is that SQL makes doing things that that SHOULD be hard, because they are stupid, stupidly easy. For instance, it's dead simple to make read queries with complex filters that join together an arbitrary number of tables and transactional updates that change values in rows across multiple tables. However, on large datasets or application that need high throughout, relying on those kinds of queries would be a terrible idea.
Furthermore, databases like Postgres use SSI by default which means that complex transactions that mix reads with writes can have subtle and hard to catch bugs that are completely non-obvious to new comers. I could easily forgive a junior developer for thinking they could implement an accurate counter in postgres using a transaction with a select then update to increment a value in a given row.
Scoffing and acting exasperated doesn't actually refute anything I said. I obviously don't disagree with you that SQL has been wildly useful and popular, but that has very little to do with my comment. SQL is an outdated and flawed technology, that is propped up by decades of institutionalization. You can say a similar thing about C++: that's it's one of the most popular and useful languages in existence, yet it's also a total trash fire that owes it's lasting success more to historical trends and institutional adoption then technical merit.
Having the result type of a function change based on context sounds like a horrible idea because it would introduce tons of unnecessary ambiguity. If it's an issue that you have to chain one extra collect call, just write a helper function for splitting that returns a vec.
The comparison with JavaScript as an exemplary imperative language is silly. You can find examples of C code from 40 years ago that still work perfectly with modern compilers. Like C, SQL is a technology that has far outlived its usefulness, though, for very different reasons. SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, raw strings, macros/preprocessors) comes with unpleasant rough edges. The best thing young developers can do is read a book like "Designing Data-intensive Applications" and learn how the fundamental technology behind databases work. Learning relational modelling is great, but learning SQL itself, unless you actively have to work with it, is a waste of time.
Too bad it will not be adopted for anything serious in the next 50 years. There is no reasonable value proposition from a business standpoint for picking zig over rust. It is already the reality in much of the tech industry that Rust is filling the space previously occupied by C++. The fact that there now exists a safe low level language is legitimately a paradigm shift. It doesn't matter how many shiny cool things zig adds, being unsafe means it a technology stuck in the past.
Really? You are telling me that the discovery/development of general relativity or quantum mechanics has not thrown new increasingly complex doubts on the accuracy of previous physical models due to these new "essences" implying contradictions with classical "essences". What could possibly make you so confident that new datapoints, theories, and discoveries as it relates to consciousness will be completely flawless?
It absolutely is a problem with the article. Science deals with physical phenomena; metaphysics quite literally means beyond physics. It's ridiculous to say that consciousness is the last hold out, as if there aren't a million other unanswered questions about meaning, essenence, and experience.
Here is a parallel argument for you. The history of science has been one discovery after another which leaves us with new, increasingly complex unanswered questions about phenomena. It is reasonable to think that if/when we reduce consciousness through science we will find that there are more increasingly complex unanswered metaphysical gaps.
> It is because of the hundreds of years of astonishing and unexpected success of the sciences that have convincingly shown that apparent metaphysical gaps are never such.
This has to be one of the most dumbfounding pseudo-philosophical sentences I've ever read. Metaphysics by definition is unfalsifiable and unscientific; it exists on a parallel plane from empiricism and is derived only through intuition, reason, and for the religious revelation. If this guy's claim for material consciousness simply rests on an intuitive argument from induction, it suffices as a counter argument to say "If I am mistaken, I am".
Bambu absolutely could create a system where their printers both communicate with the cloud and local devices, they just don't want to do the difficult software engineering necessary because it is difficult. This is not theoretical either; I work on production devices with hybrid cloud and local functionality. Engineering around a zero-trust threat model (as in you assume the user can and will tamper with the device) is completely doable.
For instance, using a push-only RPC model where only the cloud can initiate a request is one zero-trust strategy that can be used for ensuring a predictable network load on cloud infrastructure, which seems to be their main concern.
Yeah this is a good point, and maybe a hole wasn't the right way to explain myself. The point is that the way a WAL is supposed to work is that the main data store always lags behind the WAL, so that if a partial operation (always idempotent) occurs on shutdown it is replayed on start up and fixed. In the case I describe, because of a lack of fsync it's possible for the WAL to lag the main data store, so partial operations will not be fixed on start up.
Unless I am mistaken, it seems like there is a glaring flaw in this scheme, which is that without fsync you cannot guarantee the previous WAL blocks have been persisted before the current one, so a power loss event could leave a hole in the log and cause erroneous recovery. I believe that SSDs reorder writes internally so even having atomic batched O_DIRECT is not a strong enough guarantee for durability. I'll admit that I could be misunderstanding something about the system that alleviates this concern.
For the uninitiated who didn't watch Terry's streams, HolyC is both an AOT and JIT language, but the JIT was in some ways much more rudimentary and in some ways much more powerful than a typical JIT compiler. Like this CJIT project, it basically could dynamically link and compile source code, spit the assembly into memory and proceed to immediately execute it. In fact, the system shell was literally JIT compiled HolyC. Which also meant you can do fun things like call kernel functions directly from the command line.
Thanks, I added a formula for a dynamic filter coefficient to my original comment. It makes sense intuitively to me, but I'm also not certain if the exact formula I provided is correct.
If all you care about is a windowed average you can implement the fps counter (really you keep track of seconds per frame) using an exponential moving average which has constant time and space complexity regardless of window size. The calculation you do once a frame is:
Which will give smoothing comparable to an n sample moving average. This is the same formula used for n-day exponential moving averages for stocks.
As the article points out, this is a sample based window which is not as good as a time based window, but it's also dead simple to implement.
Edit:
Just spit balling because I haven't thought about this problem in a while and asked AI to give a foruma for EMA with variable duration events, so take it with a grain of salt. Maybe for a time based window you could use a dynamic alpha (forgetting factor) with the following formula:
You really can't compare crates to a taxi service and I think the article lays out the reasoning nicely. The people running crates are a small team of mostly volunteers offering a free service. If someone offered a free taxi service as a small organization of volunteers then they could easily be forgiven for not having the same standards that a regulated for-profit business would.
I have a phone and laptop; those are my only two "mobile" devices that I might ever use to access my home network remotely. I set them up once, it took a few minutes, and I won't have to do it again unless I replace one of them.
I can completely understand using Tailscale for enterprise networks, but it seems very overengineered for my personal VPN needs.
Genuinely curious: is Tailscale actually providing any values to this use case beyond what you get from a raw Wiregaurd exit node with port forwarding instead of Tailscale's NAT traversal? I've never used Tailscale, but I have a Wiregaurd setup on my home server for the same purpose as described in the article, and I've never had any issues with it.
Edit:
Noticed some sibling comments asking effectively the same thing as me. I've been meaning to write a blog post covering the basic networking knowledge needed to DIY with just Wiregaurd. My impression is that many people don't realize just how easy it is or don't have the requisite background information.
I've worked on large React and Solid codebases and don't agree at all. You can make a mess of either one if you don't follow good practices. Also dynamic dependency management is not just a nice to have, it's actually critical to why Solid's reactive system is more performant. Take a simple example of a useMemo/createMemo which contains conditional logic based on a reactive variable, in one branch a calculation is done that references a lot of reactive state while the other branch doesn't. In React, the callback will constantly be re-executed when the state changes even if it is not being actively used in the calculation, while this is not the case in Solid because dependencies are tracked at runtime.
> I struggle to see the point. The paper in question doesn't claim to be practically faster...
I struggle to see the point of your comment. The blog post in question does not say that the paper in question claims to be faster in practice. It simply is examining if the new algorithm has any application in network routing; what is wrong with that?
I publish a Firefox plugin and needed help a few years ago. Not to get too far down that rabbit hole, but they suddenly blocked my plugin because they couldn't build my source code, even though the issue with their build environment was pretty obvious. Anyways, I had to use their Matrix support channel and they recommended Element. I was immensely frustrated with how buggy the experience was, and it turned me off from ever trying it again.
Your comments are shallow because you just continue to assert the idea are bad with no reasoning. You also clearly don't know your protestant history: Martin Luther did basically just whine about the Pope. He was thoroughly a reformer that wanted to see the Catholic church changed; he did not condone "Lutheranism" as a separatist movement.
> Because they have all been tried before and had the opposite affect.
Did you even read the document? Claiming that Wikipedia has implemented all of these suggestions in the past is just plainly false. If you disagree with the documents contents, why don't you provide a substantive argument instead of just belittling efforts at changing the status quo?
I don't understand how you could read the nine theses essays and think they are anything but reasonable. Even if you disagree with his politics, the results of his suggestions would almost certainly make Wikipedia more pluralistic, welcoming and neutral.