jsunderland323

I mean this is the struggle. And props to you for building that. It's an ugly problem.

I actually do think (and have personal evidence now to believe) that most functions adjacent to engineering can learn distributed version control. Once you start using it, you really don't want to go back.

We've internally adopted trunk based development for our assets and it gets rid of 99% of the confusing parts of version control to not use branches (I know blasphemy). My designer just pulls and pushes on the main branch and I do the same -- we've had very very few merge conflicts and none that couldn't be resolved in 30 seconds.

I feel silly now having spent so much time on branching as a feature. It makes a lot of sense for plain text and code but it probably doesn't matter that much (for small teams) for visual things. Merging has proven to be invaluable to us though.

I think you're probably correct that you likely aren't the target audience here. Version control is a loaded term. This would be a terrible replacement for perforce or anything for diffing something like a CAD file.

The real focus of the system is for things that are better managed by people who aren't engineers but end up interfacing with code very tightly. The idea was to focus on the peripheral functions that come up in UI engineering and enable e.g. translators, copy editors, and designers to essentially commit to a codebase without having to understand git or know how to handle plaint text merge conflicts.

> I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS.

I totally agree. You can modify the output to your hearts desire. This was a big part of our design.

I’m curious if you’ve implemented a rich text editor with this. I think Google Docs uses canvas. I hate the browser APIs for rich text and wonder if this could be more a viable candidate than using contenteditable for future projects

Seems like this could be a big win for local LLMs =D

There is a way you could make it deterministic. You could basically let the LLM select the resolution edits and preserve that. Just as you could write a bash script to let an LLM handle your git merges. But then we go back to why? This seems like a really high risk thing to do, since at the point of conflict you really do want to know intent. While copilot is great on the code editing level I’m not sure I’d want 20% of my conflict resolutions to be the opposite of what I intended.

It’s not about system design. It’s about design systems, which are custom UI component libraries used across a product or set of products to enforce UI consistency and code re-usability.

This has always been my take too, it reeks of a DSL. It's sort of like a no-code/low-code solution for people overwhelmed by the complexity of the FE ecosystem and/or those who don't want to learn anymore web technology but are proficient backend engineers. This is a completely understandable feeling and I have this feeling almost every day. I think DSLs that abstract markup work great for personal projects (just as a CMS works great for personal websites and marketing blogs), but for anything that starts picking up utility you will inevitably have to do something that breaks out of the DSL's abstraction.

Here's my fear of using DSLs like htmx. At first the escape hatch is your friend but eventually the project stops being an htmx project and becomes a "hyperscript" (or equivalent) project. For anything that reaches maturity, you're then left with the painful task of figuring out how to port hyperscript and htmx to react/vue/svelte (the very thing you were trying to avoid in the first place). This is way harder and more painful than using one of these frameworks as a foundation for your project.

What I don't get is why people that harbor this resentment to FE tech, don't just limit their feature usage. Think server components are dumb -- don't use them! Think react hooks are stupid -- write class components! In the event you actually have to do something that requires you to do something outside of your comfort-zone, you just have to push a little bit of your react/vue/svelte knowledge instead of appending more escape hatches to an increasingly bastardized DSL abstraction.

Yeah, sorry (as I said in the below comment the site is super incomplete, showing screenshots of visual diffs is actually not that easy and I am yet to upload a demo video). Probably can’t give a great pitch here but the whole thing is based around building diffable plugins (which are really just html documents that are run in an iframe). Most of the documentation at this point is based on teaching version control to mortals rather than demoing the 4 diffable applications I made to launch with. But it really is built for mortals and is generalized so anyone can build applications that can meaningfully diff.

There’s some snippets of a visual diff in the docs here https://floro.io/docs/product/product-and-terms. If you do want to give feedback or see a demo I’d love to chat. Again, my email is in my bio.

Totally. Sadly I’m focused on GUI use cases and not AST. I’m more focused on making distributed version control for tasks that are handled better by visual editors than plain text. Universal AST diffing and merging is probably an impossible problem to solve (entirely). You could write a driver for llvm that would work for any language that shares the same IR state. Even then there’d be a lot of cases where you’d have to depend on a developer to manually resolve syntactic conflicts and enforce consistency in the IR state, which makes it pretty impractical. But two things, first, I would look at Pijul, my understanding is there is (some) support for AST diffing and merging. Second, git does support custom merge and diff drivers — I’m not sure if this is where you’re going with your xml hack but I don’t think it’s too cumbersome to write a custom differ if your painful conflicts are relatively constrained to certain functionality or part of your code base.

My site is half built (lots of broken links and only half of the documentation is done so please don’t judge me), but I think my technical explanation does an okay job of talking through some of the complexities to think through in regards to structured diffing and merging. It might be helpful to you if you do decide to write a git merge driver. https://floro.io/technical-overview-part-1

I wish I could show you something I’m working on — I’m just finishing up documentation now. I don’t think many people get this too. I haven’t launched yet but I think I solved this problem, my email is in my bio if you have any interest in talking about sane visual diffing and merging

Does seem impassioned though

> Now, someone who regularly works with MIDI files - heck, someone who regularly works with binary files - could probably do it in a few hours, but this entire process took minutes.

In my experience, I think this is the key area it exceeds but this isn’t all that common. Hard to imagine 10x productivity boost unless you’re a jack of all trades master of none.

In my experience it’s really useful when you need to do something in a domain you aren’t super familiar with (that you don’t need to become proficient in). But when it comes to the everyday stuff that is my comfort zone I don’t need it. I’m years past looking up syntax or standard library functions for the languages I work in regularly. Every time I’ve tried to use it for a remotely complex algorithm I’ve found it to be much faster to implement by hand then try to debug whatever it got wrong. But for makefiles and gh actions — it’s a true godsend and those things can be major time sinks.

I’m also a developer who really likes to know what my code is doing. If I can’t code something myself I don’t feel comfortable deploying it. But I’ve found this is less universal of a sentiment than I would have imagined in the past year.

Agreed. I was on the edge of my seat. I wouldn’t do a write up for something like this. I feel no-soap radio’d.

It looks like you’re basically sending raw c code to an express server then evaling it with some zig module import. Is that correct? Seems super safe.

> Sure, we can sort-of reason about this stuff e.g. with a hierarchical css+html+js structure, but without a way to render that I challenge you to be able to simply diff that information. Seeing "bold" or "blue" seems simple enough, as long as you also know to which elements it applies and in what layout. So, suddenly you can't reasonably diff the css file without also difficulty the html.

We’re in complete agreement. But you can do this, you just need to provide a “renderer” and a schema that describes how your tree structure should merge or conflict. If you want to test out a weird version control for structured data, my email is in my bio.

This 100%. It does get interesting when you get into non-plaintext things that have to somehow integrate into plaintext systems (git managed codebases). We've kind of left it up to CMS systems to handle the non-plaintext bits but this leads to many more orthogonal process problems.

IMO, I think it really comes down to finding a universal mechanism for diffing and 3-way merging things that aren't plain text (document diffing). I think distributed version control can be universal (at least on a data level), how an application renders a meaningful diff for a specific task is incredibly subjective to the document type and task at hand. My point being that I completely agree that plaintext makes a whole lot of sense for programmers and pretty much nobody else. However, distributed version control does not have to be confined to plaintext, it's just tricky to see when all the version control systems we're familiar with are plaintext ones.

Well then you’re back to the bridge problem. postMessage is crazy slow. There are some problems where parallelization will outperform the ipc cost with postMessage but those problems are few and far between. I haven’t dove into the new web GPU api but it does look kinda promising (shared memory is hard, so I’m apprehensive). I’m sure some of these things will get solved in the long run but for the time being, the bottleneck to browser performance is not necessarily JavaScript itself but the webapis that are crafted around a single threaded model. This is really my only point. Aside from providing systems engineers familiarity with syntax/devex and possibly some portability with some llvm/wasm compatible libs, there is little point in wasm runtimes at this current time imo.

citation:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

“Data is sent between workers and the main thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler (the message is contained within the message event's data attribute). The data is copied rather than shared.”

I did a double take when I read this too. However, I’d wager that in 99% of cases the bottleneck isn’t at the language level for most desktop apps or GUI apps in general.

I have an app that has one pretty frequent cpu intensive call (it computes the lcs for diffing). I decided to benchmark a rust wasm bindgen implementation against the js one I was using and found that ironically enough, node did perform better than rust. To be fair to the rust version, I think the JS implementation was slightly better optimized. I then looked into parallelizing LCS, (which is possible) but bindgen and almost all node:rust ports don’t support multithreaded calls, I can think of a myriad of ways to overcome this but not in a browser context. At that point I gave up on worrying about porting to lower level languages for cpu intensive work because if you’re forced into a single threaded context the gains of a memory managed language are going to be trivial at best and add ipc overhead at worse.

The main culprit of poor JS performance in native contexts is almost always bridges and the serialization/deserialization that comes with them. Electron apps don’t really suffer from the bridge problem. While, I’d never claim that JS is as fast as GO or Java (objectively it isn’t), it’s seems equally naive to suggest that using memory managed languages without exploiting multicore is going to lead to significant performance gains in a native app or web app.

I think the real power of wasm is the power of virtualization, it won’t be performance unless web APIs decide to break the single thread paradigm.

But you did and people don’t want to register. So do you want to iterate towards a model that works for you and your users? I think OC left really good feedback. I’ve been in your shoes before and I really can empathize with your situation deeply but I’d try to lose the defensiveness asap. It sucks when the model of the universe in your head gets dashed by reality at launch but I think not taking the feedback is a mistake.

I’d also challenge your line of reasoning about what constitutes a user for your service. I hear what you’re saying about ignoring bad (non-paying) users in the case of SaaS products etc. but this is literally a blogging aggregator without a network. Get the network going by reducing all the friction in the world and worry about the rest later. 6 man months is not a lot of time for a product. There’s a whole “free” internet just a click away.

The good news is it does seem like there is market for this and as OC pointed out there are ways to make iterations and improvements that could get people to sign up. Keep moving! Good luck!

I think there’s arguments to be made both ways. I‘m generally of the belief that technology that works is a net win for humanity. But I think we need to stop being vague about what it means for an LLM to work. For me, I just want to tell an LLM to replace all the hard coded strings in my app with translation tags. Sadly, this isn’t possible to do reliably with what we have today. I’m not sure who’s job this would eliminate other than my own. I think the more existential questions are about if we made a god box that could perform all the white collar jobs. I think we’re so far away from that despite being sold that vision, that we might as well consider the moral and philosophical implications of a time machine or teleportation device if we’re going to continue to entertain AI doomerism for LLMs.

Yeah, I think that's well said. I think the doomerism is more of a sell to investors than users sorta situation but it cuts both ways, which makes me sad for the tech industry having just made this same mistake with crypto. Who benefits from this? Anyone invested who doesn’t want to disappoint an investor (LPS, VCs, and founders) and/or anyone who’s ego is invested in the space and/or anyone who is raising money in the space and reliant on the technology and/or AI companies who benefit from the publicity/legitimacy of having their CEO talk to congress and/or AI companies who get an entire NYT piece run for a week about how an LLM is going to kill us all and/or any public company that can benefit from a stock rally by pushing the narrative that they’re in a land grab market and have the coveted goods and/or any large company that could benefit from blocking out nimbler competitors by getting arduous regulation passed… I could go on. You realize that like every 10th article on HN is an AI existentialism piece? Reddit is even worse. It also diverts the conversation from LLMs being shitty to the machines are coming. I’m fine with doomerism (getting hysterical can be fun) but I think it’s completely unwarranted with where we’re at. I don’t think we should overlook the risks associated with intellectual property, impersonation, data privacy, the ever growing body of bot spam destroying the internet etc. but worrying about the more dramatic risks has proven to be a pretty effective diversion tactic from the obvious acute problems — namely that LLMs have very little practical utility as they are now and the little utility they do have is primarily beneficial to spammers/scammers. I can already feel the person chiming in to tell me they love co-pilot (please just learn the language you’re working in).

But to be clear I’m not saying this is a methodical highly coordinated ad campaign amongst multiple companies. I don’t think human beings are that competent. I think it’s way more grassroots and feeds on cultural tropes that have existed since at least the 1950s but probably the early 1900s. I think Anthropic’s leadership probably genuinely believes their own bullshit but I also think they understand that that same bullshit has raised over a billion in funding.

I'm not going to rebut everything but I want to point out that I think Geoffrey Hinton is way more in your camp in regards to faith in the technology (which is what we're discussing). I'm in the camp that thinks LLMs are at best a viable competitor to furby -- I have zero existential fears and have very little confidence in them. I'm not opposed to AIs, I just think the state of the art is really really bad (sorry) and the doom and existentialism is a marketing ploy to a world imbued in conspiracy theory and institutional distrust in order to compensate for a wildly over promised and under delivered product. But hey, when you gotta raise money, you gotta raise money, and as you put it, the "trend line is going up" and that's all that matters.

> 48% if half way to 100% … It's halfway their to taking your job and your underwhelmed.

You’re implying 100% reliability is actually attainable. If that were the case, wouldn’t that mean the halting problem would have been solved by AI? I’m not an expert but I’ve heard that’s like one of those fundamental laws of information theory that really can’t be broken.

> It's typical. It's like an indie band is only popular when not many people know about it. Once everybody starts talking about it all the time it loses it's popularity.

I think applying the sociology of hipster band fans to LLMs is a mistake and I’m not sure how the vogueness of the technology correlates with the correctness of the actual models. Sometimes an early technology seems docile or useless at first but eventually reaches ubiquity and in retrospect the utility is obvious. But sometimes (more often than not) standard adoption curves don’t make sense to apply to a new technology because it isn’t useful enough to go through an adoption cycle. I think there’s a temptation to apply the analogy of something like the early internet or smartphone to LLMs but those are networked products. LLMs don’t really improve with the various applications built on top of them if the LLM is itself fundamentally broken or faulty to the point that it is unsafe to use in practice. Furthermore given the massive amount of premature hype due to the AI zeitgeist, you can safely assume enough user hours have been spent messing with LLMs to get a verdict on their utility. Unlike the feeble technology that takes a longtime to reach a scale to know its utility, we don’t have to wait 10 years for 100m people to try LLMs, it happened in a week. My only point being, I think we should be apprehensive about trying to draw analogies of other adoption cycles that structurally are very very different to this one.

Obviously, I, like probably everyone else on this website would love LLMs to be reliable to a high degree. Just this morning I had such a good use for an LLM that I was seriously considering building (and admittedly still am pondering) but the second I started to think through the LLM faultiness, I had to consider the complexity of the safe guards and weigh if it was really better to use GPT or just write a nasty regex script and constrain the problem. I’m leaning heavily towards the latter but I’d much prefer a silver bullet if it really killed vampires. Until then (if that day ever comes), it’s lead bullets for me.

I think there’s some pretty cool applications to be built upon homotopy type theory/ univalent foundations. One use case I’m working on is building a structured version control system that allows versioned documents to be translated to code at compile time. Think rich text translations or other static assets that you may want to change at runtime. One really interesting exploitation of the univalence axiom is that you can make hot updates to compiled code without having to recompile the entire system by knowing if the identity paths of the updated document state is a topological subset of the document used at compile time. If it is, you know the updated generated code is isomorphic with the compile time code, meaning it’s safe to swap out. That’s pretty mind blowing and (seems very) practical to me. Basically allows for higher order configuration editing.

Why do people think the garter hype cycle is a law of physics?

The cryto people have been pointing to garter hype for over a decade. Still not using Bitcoin for anything and would be extremely surprised if my disillusionment ever subsided.

>There are still quite a few challenges to making LLMs work reliably.

I'm not unsold that AI will continue to improve but I'd be weary of this claim. LLM's reliably do what they are supposed to do and it appears they're reaching an asymptote in capability. If what you're wanting is a truthful chatbot, you're probably barking up the wrong tree with LLMs.

Do LLMs have utility? There's enough people on HN to convince me there are legitimate uses for them. However, many of the people using them are also the people desperate to legitimize their utility, so it's honestly hard to know. I personally have not found any application for LLMs in my life and would discourage anyone working on anything remotely mission critical from using them for code generation. But I've definitely heard of a few real world uses.

I lost brain cells reading this

This is the package manager paradox. The problem is multiple package managers but to address it we build more package managers.

I like to imagine this as the result of some BMW pm’s misunderstanding of the term per seat pricing.

I used https://github.com/cozmo/jsQR in production for years. Never had any problems, before all smartphones had built in QR readers, most of our users would use it primarily to interact with our product. Works for iOS and Android. To my knowledge does not use ZXing and is Apache Licensed.