spion

That promise doesn't really make sense to me - although partial compilation will likely ameliorate most migraiton pain for library dependencies if they come pre-compiled with the compiler.

Code written with the react compiler in mind will inevitably be MUCH slower without the compiler, as its not going to manually add any memoization. Likely to the point where its not going to be usable without it.

If you have a very large project which uses MobX, I don't think the amount of warning matters. You'll most likely have to (eventually) completely rewrite large amount of code, to the point where it might be easier to migrate to SolidJS.

Also, because next broke emotion, toolkits such as Mantine broke backward compatibility in order to move off of emotion, so second order instability effects still affect SPAs

Important or not, libraries you depend on may jump on it and abandon backward compatibility

react compiler breaking mobx is purely spa; progressively stricter rules of hooks too. Its bad.

> My react code now doesn't look very different to my react code in 2019

Server components, Next application directory breaking emotion for styling, stricter rules for hooks, the compiler breaking change tracking libraries such as MobX removing the need for useMemo and similar. This is just off the top of my head in React land.

> Implementing a basic "useState" and "runFunctionComponent" is easier than most third-semester CS assignments.

I'm not sure it is. There is a global dispatcher that finds the right component state to use and increments a counter to ensure that the correct state "slot" for that component is used. There are also a bunch of mechanisms to prevent slot mismatches. I guess you could make a loose analogy with writing custom allocators, except instead of the binding knowing the address, the order of calling useState determines the address :) Really not that simple.

IIRC reading the React source code became quite a feat around the time fibers were introduced.

You can use a language / compiler / static analyzer that restricts side-effects.

The setup / overhead is for the initial render, but after that I'd be surprised if O(N) defeats O(1) even with a bit of a bigger constant (given a sufficiently large N). Also, given React Fiber, I doubt that those 1000 calls will simply be function calls - I'd expect plenty of overhead on that end too.

Would be interesting to design a realistic benchmark around this. IIRC Michel Weststrate (the author of MobX) had a realistic example based on draggable elements on diagrams, where the diagram link lines needed to be recomputed in realtime as you drag the boxes around.

Another realisitc option would be large dashboards made of tables where lots of data updates come in real time.

The one place where signal based fine-grained reactivity still wins are lists.

Updating the "done" state of a single todo item nested in a list of todo items still causes an entire list (of possibly hundreds of items) to re-render.

In principle you can solve this with fully normalized state shape but in practice things like MobX (especially when combined with SolidJS) still provide the best ergonomics and separation of concerns with very little compromise.

I'm however excited to see what kind of DX improvements the compiler can bring to the table. Perhaps someone will have a good idea and we'll get something that's at the level of MobX.

Not really blaming, more like wondering how things would turn out.

Probably would only delay the move to the cloud a little bit, and perhaps make AI less capable.

You're selecting for people who feel they're priviledged enough to reach out to support and ask for bill forgiveness even when they may've messed up, repeatedly. This does select for something but I'm not 100% sure "people who are doing this work professionally" is that clear-cut, especially once you move past western cultural norms.

Was he though? If we didn't have GPL perhaps at least our software and data would've still been on our computers instead of a privately owned cloud...

Nothing that exciting, I'm afraid.

I've never used it with a rooted device! :)

I don't think there should be any significant difference in funcitonality, other than perhaps the set of directories accessible. In general, you should be able to access anything that you can view / access using `adb shell ls`, `adb pull` and `adb push`

Hello, maintainer here. Happy to see this little project on the front page of HN. Unfortunately it hasn't received the appropriate attention from me lately, mainly because of the difficulties of running tests (and the android emulator) on GH action runners. Attempt to add some basic tests can be found here https://github.com/spion/adbfs-rootless/pull/62

This submission motivated me to check out the latest state of virtualization in GHA and it looks like GH shipped it for all linux runners https://github.com/actions/runner-images/discussions/7191#di... - so it might be possible to get that PR working now.

There is honestly not much to learn, and that might be part of the appeal. At its core, JS is a relatively simple dynamic language with a clean syntax. Despite the clean syntax there are quite a few quirks in how some of the internals work (sorting and pervasive string comparison and casting, equality operator, etc). The most interesting thing about it is probably the programming model of free-form objects and closures: rather than using classes, you could write functions that return free-form records containing functions (and getters) that close over the lexical scope of the function. This gives a kind of dynamic object construction flexibility without the additional boilerplate.

For the base language I recommend Dr. Axel Rauschmayer's books (https://exploringjs.com/) as they're kept very much up to date.

Where things get really interesting is TypeScript, which takes all of this dynamism and manages to model it with a type system that doesn't feel all that constraining. It also ameliorates most of the core language papercuts. I don't really have good recommendations for TypeScript for now, other than browsing typescript issues and pull requests for examples written by Anders Hejlsberg

You have to be very careful with the library and tooling ecosystem, however. There are a billion ways to do things, many of them incompatible with each other, and things break all the time. This includes major, popular libraries and frameworks with good looking documentation websites, so it can be difficult to pick something solid and stable. This is where most of the pain of using JS comes from.

- Fewer people getting spammed

- The people who receive the cold email are (increasingly) more likely to be at least somewhat interested

- A human really wrote personalized emails, instead of trying to trick people into believing that

To make this less spammy, the person sending out the emails could've instead used AI to filter through a smaller set of people where their product is likely to generate very high interest, based on a prompt containing the product description and perhaps a summary of the things the potential recipient blogged about. Then, they could've used that short list to write a set of _actually_ personalized outreach emails with high chance of impact.

You could refine this in further iterations by also adding examples based on previous correct/incorrect interest predictions, thereby effectively reducing the amount of spam / making cold outreach suck less.

There are different ways to use AI to achieve the same goals, some more responsible than others.

Wayland is almost-ready. This is what I needed to do to switch (caveat: this is ubuntu 22, so I may be 2 years out of date):

- Accept inability to use monitor color profiles (this is still WIP)

- Accept inability to use full-screen sharing (very likely to be broken, in theory fixable, in practice its unclear how to fix the portal mess)

- Forked libinput because it behaved unacceptable with my touchpad, and the original developers don't want to add the configuration options to fix this. (Well kind of - custom acceleration profiles may be available in later versions)

- Spent some time adding all the "use wayland" cli flags to everything electron based. In theory, ~/.config/thing-flags.conf is supposed to work, in practice it doesn't, so I have a bunch of wayland replacement clis for everything (wcode, wobsidian, etc)

- Spent some time looking up tool replacements (i3wm -> sway, dmenu -> rofi, xclip -> wl-copy, xprop -> ... its complicated etc)

Benefit: for the first time ever my Thinkpad X1 Extreme Gen3 laptop (4K screen) outperforms my Android phone in graphics rendering performance and responsiveness, even just using the Intel card. Using it feels gloriously good. This includes the OEM Windows install as a comparison point, which is doing significantly worse, even with nvidia card enabled.

Replacing Xorg is an absolutely impossible task, with a long tail of broken things left in Wayland's wake. But I think it might finally be getting to the point where its worth it

Monads being monoids isn't very interesting in a practical sense - e.g. just because you can associatively combine steps in a program isn't very interesting. (We do it all the time when we extract a subset of instructions as a procedure)

I'd say monoids are more interesting, mainly due to implications for massively parallel algorithms and caching and how finding operations that fit the laws let you reap massive benefits in both aspects.

I've yet to see something as practically interesting for monads. Perhaps monadic parsers or STM qualify. What would you say makes monads just as interesting in a practical sense?

They are interesting in purely functional languages like Haskell because they allow for side effects without sacficicing purity and referential transparency. Rather than allowing side effects, you describe the program as, say, specs for the instruction to run, plus the function that decides what the next instruction is after the first instruction completes and yields a result. Kind of like a linked list of functions that return imperative instructions.

I don't think the general concept is that interesting, at least in programming. Monoids, though simpler, are probably way more interesting (mapreduce, caching, etc)

Same. Coincidentally, wayland is pretty fast.

It depends on the context. In some context, they might actually jump out. In some context, even if they don't, it might be fine, because the larger modules containing the code already have excellent tests and are solid and stable

I could make the same argument for not using DRY. The DRY-ed code is hard to change, programmers feel honour-bound to keep using it and tweaking it by adding a variety of parameters to more and more cases, and at the end becomes impossible to understand or update, slowing down development.

Now, what probably should've been 3 abstractions is one incredibly convoluted "abstraction" that makes no sense, and its 3x harder than 3 individual abstractions to deduplicate and inline. It further pulls and invites complexity, as its current size is implicit invitation to include additional cases and places.

Furthermore, while without DRY fixing bugs may've been tedious, now with DRY it may be almost impossible due to high risk of breaking a lot of things that depend on that code. (You might be lucky enough to be able to and have written extensive tests with 100% edge case coverage for it - if that's the case then you've postponed the moment of pain somewhat)

Both can be true. It depends on the context whether benefits exceed costs. Decisions should be made based on a specific context and with thinking applied, not generic rules.

This really makes me think we should be focusing on cost/benefit, risk/reward, pros/cons at all times. If we have a bug in these 5 copies, will it be too hard to fix in all of them? No? What about these 10 copies? If that sounds like its starting to get difficult, maybe now is the time.

Its not about OOP but the probability that those two functions will diverge. Linked elsewhere in the comments too, this article (https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) is probably better at articulating the point.

"this will be done tomorrow/next week/in three months"

This type of answer is also possible if you can agree on the desired confidence. I've found that 95% confidence is sufficient for most cases, but that number will depend on context. Understanding the stakes of the deadline for stakeholders can help adjust this further.

I agree that building trust with stakeholders can be tricky, and discussions about risks can be sometimes be interpreted as unwillingness to take responsibility. In that situation, the team can at least get a measure on their level of confidence and give an initial number they're somewhat comfortable with, as well as an estimate of how likely to succeed the agreed upon number is.

For cases where the tech stack is in some ways unfamiliar, we create research stories where the goal is to do the quickest thing possible to answer questions about the tech. This is typically timeboxed by the max time we'd be willing to spend on it, rather than the estimated maximum time. Its still useful to try and put a maximum estimate if possible, because then you can also estimate probability of success for the timebox which makes you better prepared for discussion with business to help them decide if they want to take the risk to invest time in it.

Few years of experience should be quite sufficient, although I think overall team culture is probably more important. I've usually done this type of estimation together with teams where there's already good communication, but when that's not the case something like pointing poker to open up safe discussion and uncover uncertainties may make sense as well.