trevor-e

Very excited to see this as an official project!

I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.

So this seems similar to https://temporal.io/, am I reading this right? I used that briefly a few years ago and it was pretty nice at the time. It did make some features much easier to model like their welcome email example. Would love to hear from someone with extensive temporal experience, iirc the only drawback was on the infra side of things.

In this example the value is incomplete, not the key.

Yea I think Latex is capable of much of this but it's also cursed

Not really sure what you mean by a "human-friendly" file format, can you elaborate? File formats are inherently not friendly to humans, they are a bag of bytes. But that doesn't mean they can't be better consumed by tools which is what I mean by "AI friendly".

I've been thinking lately that maybe we need a new AI-friendly file format rather than continuing to hack on top of PDF's complicated spec. PDF was designed to have consistent and portable page display rendering, it was not a goal for it to be easily parseable afaik, which is why we have to go through these crazy hoops. If you've ever looked at how text is stored internally in PDF this becomes immediately obvious.

I've been toying with an idea of a new format that stores text naturally and captures semantics (e.g. to help with table parsing), but also preserves formatting rules so you can still achieve fairly consistent rendering. This format could be easily converted to PDF, although the opposite conversion would have the regular challenges. The main challenge is distribution of course.

As others have said the Sagrada Familia is incredible and I had high expectations given all the controversy around it. I've visited many historic churches during my travels and it's my favorite one. Really neat to see it reach this stage.

Why would a company like Lyft/Uber partner with Waymo at this point? That sounds like doing a deal with the competitor who _will_ completely kill them off in the future.

You can never rely on support reps to escalate UX issues to product teams for a couple reasons.

First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.

Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.

This is a great use-case of AI.

However I strongly doubt your point about "It's not going to replace anyone's job" and that "they also free up the human agents to do higher-value work". The reality in most places is that fewer agents are now needed to do the same work as before, so some downsizing will likely occur. Even if they are able to switch to higher-value work, some amount of work is being displaced somewhere in the chain.

And to be clear I'm not saying this is bad at all, I'm just surprised to see so many deluded by the "it won't replace jobs" take.

Personally I like the UI for https://conductor.build/ a lot more than this, although I'll have to give it a try.

I see a lot of commenters asking why a GUI is necessary. When you're running several agents in parallel it becomes very handy compared to the terminal. I can easily see the status of each which I haven't found a good equivalent for when using terminal tabs. Also it handles automatically creating git worktrees for each agent which is great.

Yea sure, there are still some spots where I might find DaisyUI helpful, like building a quick internal admin page for something. And another commenter pointed out this works in non-react projects unlike shadcn. But I would know going into it that it will be a pain to customize/maintain, should I ever need to do that. Maybe that's already the expectation for people familiar with Bootstrap though.

My advice is more cautionary for folks who search "Tailwind components library", see DaisyUI as the 4th result, and think "great!"

I agree with others that this is not how Tailwind is meant to be used. For example, the approach shadcn (https://ui.shadcn.com/) takes is much better IMO.

Creating helpers like `btn` makes it very difficult to understand how it works and is not very customizable. Shadcn creates an actual component for you in your codebase and is just trivial Tailwind styles to modify.

That's super cool, I love the SciShow videos.

I think you're right about the editorial thinking + what do people find interesting parts. But that doesn't have to be solved by directly by AI, it's easy enough to sidestep the problem and provide a nice interface for the human-in-the-loop part. I'd imagine that would save you a ton of time by having a nice starting point depending on how much you have to rewrite for tone.

>SciDigest: An AI-powered platform that transforms complex scientific research into engaging, digestible content for the general public, making scientific knowledge accessible and actionable.

This would actually be great. So many researchers have a marketing problem with explaining and getting people excited for their work.

I'm not sure I understand the outrage. Before Discord, everyone used forums. And those were archived by Google for the entire world to see. What's the difference?

Having built some toy parsers for PDF files in the past it was a huge wtf moment for me when I realized how the format works. With that in mind, it's even more puzzling how it's used often in text-heavy cases.

I always think about the invoicing use-case: digital systems should be able to easy extract data from the file while still being formatted visually for humans. It seems like the tech world would be much better off if we migrated to a better format.

When I worked in the travel tech industry several years ago, it was basically unfair to compete against Google Flights. We just accepted they didn't have to pay for marketing and had infinite compute to work with, and had to differentiate in other ways. They could operate the business at a loss and not really care because it was still good for Google as a whole to have user's travel data. They built a great product but didn't have to play by the rules everyone else had to follow.

Lot of nice improvements here. I'm actually quite liking the async API after using it in a couple small apps and learning the fundamentals.

I really wish the entire Swift team would spend a quarter fixing bugs and improving the compiler speed, though. So many trivial SwiftUI cases trigger the "this is too complex for the compiler" errors which are so frustrating to fix.

Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.

You can't say that and then not share where you moved to. Now I'm curious. I don't live in the Bay Area so not defending it in any way.

I thought the same until having to do slightly more complicated and "off the beaten path" workflows. I'm still amazed at how easy they make building CI jobs now, but I also get frustrated at how it's not a "local first" workflow that you then push to their service.

The easiest logical way I can make sense of this problem is to apply it to humans. Copyrighted material has tremendously impacted my thinking and work, but I had to pay to access it. And as long as I'm not publishing copies of the copyrighted work, derivative work seems to be fair use. This seems fair for everyone, if they want to train on a resource then they should pay for it.

The only angle I can see this working for OpenAI is pushing the anti-China national security threat narrative, which I expect to see a lot more of this year (especially with this administration). While I personally hate that, I can definitely see how AI + drones are the obvious future in warfare, so I don't think it's that far-fetched to work.

How do you determine what is "proper form"? All forms are arbitrary until a best one is picked, although that's highly variable to specific individuals. Did you work with licensed physical therapists to determine this? After working out for many years I'm highly skeptical of any app claiming to do this unless someone licensed is willing to say they back the results.

The only mention I can find is: "How do we determine proper form? Firefly references the average exercise performed by credible fitness experts."

Also like others mentioned, your pricing is incredibly deceptive. Make it front and center to users, otherwise "Full Access (7-day free trial). Cancel anytime." is a hard no-install for me.

Great write-up!

Apologies if this side-tracks the conversation, but why do we as an industry complicate the naming of such techniques? I don't remember what "string interning" is off the top of my head, but a "string lookup table" is immediately obvious. Maybe I'm wrong though and this is a commonly understood name. I guess interning captures both creating the lookup table + using the index in the related data structures. We used this technique at KAYAK to help efficiently construct the list of possible flight combinations for N x M depart/return legs.

I cringe thinking about PR comments I left early in my career.

"akshually this should try to follow more SOLID principles"

But, coming from a formal engineering background, I thought this is what it meant to be a professional software engineer. Little did I know these "principles" were just the musings of a consultant lol. Turns out most folks have good intentions and want a standardized way to write code, but for some reason it always results in code that looks like the Enterprise FizzBuzz meme repo.

It's definitely a very gray area within Apple's policy. Shorebird (Flutter OTA updates) describes it best in their FAQ (https://docs.shorebird.dev/faq/#does-shorebird-comply-with-a...).

It seems to be as long as you don't significantly alter the primary purpose of the app, then it's "allowed". But that's a very broad interpretation and puts native Swift apps at a huge disadvantage.

I could have worded this better since running xcodebuild is obviously outside of Xcode. But it's not a stretch.

Is it possible? Yes, of course. Bazel and Buck iOS builds have existed for a long time, and many large teams use them. You can even use Gradle to build an iOS project.

Does Apple officially support any of those? No, you won't find any Apple instructions telling you how to do any of this, Apple expects iOS apps submitted to the store to be built with Xcode. You're on your own with these solutions. And setting up Bazel for an iOS project is not an easy undertaking.

Swift is open source, but SwiftUI and UIKit are both closed-source which is what I meant.

Good catch, totally missed that, will update