go podcast()

Dominic: 00:01

Hello, Gophers. You're listening to Go Podcast. My name is Demnik St. Pierre. I'm Morten.

Dominic: 00:08

And we have Andy Williams with us today, the creator of the Fine Project. Hi, Andy.

Andy: 00:14

Hi. Hi there, Dominic and Morton. It's great to speak to you today. Thanks for having me on.

Dominic: 00:20

Very cool. Very cool. We are glad you are here, to be frank. We we talked last time, you know, we FINE FINE is is a really nice project, and I I I always say that most, if not all, of the Gophers probably know the project. It it seems to be growing very nicely.

Dominic: 00:37

What what is going on at the moment with Fine?

Andy: 00:41

Well, I'm very glad that you think of it that way. It does seem to become kind of synonymous with building applications in Go. I'm definitely pleased to see how much it gets covered on podcasts and conferences. Previous years, I've been going around telling everybody about it, but now I'm learning from other people what they're doing, which is really great. So seeing lightning talks and presentations being described about other people's projects really fills me with with a bit of joy.

Andy: 01:07

It's always great to see people building. At the moment, actually we just released 2.7.3 which was a bug fix release. I think about 20 to 25 bugs were fixed, and at least half of those were by community members outside of the main core contributors. So we're seeing a lot of work being donated by people in the community which is also fantastic. We're very grateful to everybody both bug fixing but also just coming into the community whether it's the Slack channels or other forums and helping helping people learn.

Andy: 01:39

Also we're working at the moment on the 2.8 next major version, and this has got some really cool stuff coming. I've been working on accessibility, was very much front of mind after we last spoke, So we have a lot early version of the the basic read aloud type of functionality for Mac OS and Android is on the PR right now. We're going to get Windows and iOS sorted before that PR lands. We've also had some cool new graphics primitives added, there's polygons and bezier curves, arcs, and I've just added blur primitive as well, so we're adding more graphical things that people are starting to expect from a user interface. When we started in 2018, text lines and boxes was about it, but things have become quite a bit more sophisticated.

Andy: 02:31

So we're trying to keep up. Yeah, there's there's lots of really cool things coming.

Dominic: 02:35

Yeah. Yeah. Accessibility, of course, sounds great to to my hear. But I'm I'm curious to to hear a little bit about what you just said. So what you know, I'm I'm obviously not really someone that is used to build GUI UI.

Dominic: 02:50

So what can I do with polygons or or the things that you just mentioned? What what are what are those what what are they enabling me to build that I could not with the two dot seven version, for example?

Andy: 03:05

That's a a very interesting question because you're right. You could sort of do anything before. If you could imagine something being drawn to screen, there's pixels involved somewhere, And in previous versions of Fine, you could just use any graphics package to draw an image or or some kind of shape to an array of pixels and have that rendered to the screen. But it was a little bit slow, and given that Fine is a vector based toolkit so that something always looks crisp by the time it renders to screen. If you have pixels as the intermediate, you're using CPU instead of graphics optimization, and you might not be perfectly aligned with the output device.

Andy: 03:42

So the new graphical types are optimizations, I suppose, so you can easily describe this complex shape and have it displayed very crisply. Now, it might not be used so much on buttons and standard shapes, but it's been requested for a while for people who want to do more complex things like graphing, charts, and richer graphical interactions like you might see if you were editing complex documents I suppose on on a web based platform, they are more intensely graphical. I suppose we focus more on functionality, and now we're heading towards a richer form as well.

Dominic: 04:24

That's that's that sounds very interesting. So am I understanding that it's a little bit similar to what one can do with SVGs on on the web, for example? So, basically, I I is is it like now I I have a canvas and I can draw things on that and and it it just looks good?

Andy: 04:44

Yeah. Exactly. I mean, underpinning the graphics on any fine app is the canvas. There's a package called canvas, and that describes all of these shapes. Most people building an app are going to use the widget package, which is higher level, and that encapsulates the the graphics to make a render.

Andy: 05:00

And we're just making a richer canvas package. SVG is absolutely core to a lot of what we do because the iconography all needs to be vector graphics as well, and we use the material design icon set, which is purely SVG. I believe it's s r wiley's library that we have built upon to do the SVG import and rendering, but that does go through a rasterization process, which we've had to cache and and optimize locally. The more we can put into the graphics pipeline, the more we can push that rendering onto the GPU so you get quicker startup, snappier frame draw. Essentially, when you're doing something on the screen, you have to do the entire refresh of a window in under twelve milliseconds to avoid a lag, or I think six on on the the newer iPhones, are running a 120 hertz now.

Andy: 05:53

So there's not a lot of time to to hang around.

Dominic: 05:58

Yeah. Yeah. Yeah. This this this sounds crazy to me. I don't know.

Dominic: 06:02

So what wow. This this is this is so low level and out of the scope of what I'm building usually. So this this I I always like to talk to you because this world of graphic design or you seems to be very knowledgeable of all of those things, and it's it's really interesting to hear you talk about those.

Morten: 06:25

It sounds quite wild. Yeah. Oh, sorry, Andy. Was just pressing in because it's I was just sitting here learning, and it sounds very interesting.

Andy: 06:33

Oh, you're very kind indeed. Honestly, I'm no expert on this. I've just been working in the area for for some time. I was really lucky to to grow up alongside Linux when Enlightenment was the window manager of choice. And I worked alongside Carsten, the Raster Man, and a few of the the team there in the early twenty twenties and building out things.

Andy: 06:54

And they had a phenomenal project that optimized absolutely everything for really smooth and slick graphics in a time when we were, well, used to something that looked a bit more like Windows 98 on on Windows and and similarities on Linux. So I I know some of the optimizations there, but I really I have to say that a lot of the graphics primitives are being contributed by people from other projects who want to help out or or people coming into the community. I wish I could list all their names right now, but it honestly is a a community project that I've pulled together, maybe architected from the beginning, but there's so much there that I don't fully understand. I just know enough to talk about it.

Dominic: 07:35

Nice. Yeah. Yeah. It's it's it's very impressive. So so have you seen any kind of bump in traction seen since, I would say, the arrival of LLMs and whatnot?

Dominic: 07:51

You know, it it that does does that affected at all the number of people wanting to now build maybe desktop application or mobile application using these tools?

Andy: 08:06

Yes. But not maybe quite so much as you would think. I reckon that the difference has really been that there's a lower barrier to entry in general. But the the reason that I think fine traction is that Go is just a really great language for LLMs to succeed at. With all of the tooling, they're more likely to output the correct code first time.

Andy: 08:29

Or if there is an error, they can probably correct it quite quickly. And given that I I think it's fair to say the the real power in in LLM generated apps is is greenfields. You know, you've you've got an idea. You're trying to pull something together quickly. They they could do that very well.

Andy: 08:45

And so we're seeing more people realize that it's actually super easy to get involved, and then they look at the code that's been generated. And Go code is pretty clean, and fine code aims to be exactly the same. So they're looking at something that they can actually read, but then it it translates or or compiles directly onto their Android phone or their Linux desktop all from the same code base. And, you know, kind of people getting to this moment when they're realizing how much they can do and understand it at the same time. They just didn't know how to get started.

Dominic: 09:16

Right. Yeah. Yeah. Yeah. Yeah.

Dominic: 09:17

Yeah. That's that's pretty pretty yeah. That's pretty mad what what what we are seeing at the moment. But but again and so not not a huge bump. I'm a little bit surprised to hear that, to be frank.

Dominic: 09:31

So what is what is pushing people? Do do you see more bigger enterprise, maybe companies wanting to build desktop application nowadays? Are we seeing some kind of return to, let's try to build tools for employees that are not, know, always web based and whatnot? So so what what is the the story regarding this?

Andy: 09:59

I think you're exactly right. What we're seeing in the most part for the adoption is companies that understand that a a native app is going to be a better, more secure, faster pay, perhaps easier to to control platform than doing something web based. You don't have to worry about some of the infrastructure challenges. And people can take this and it's offline by default. You get a lot of benefits, particularly if if I suppose if you're building something that is downloading data and then you can take it away because it's it's local, you know, you don't have to have the cloud services available for it to work.

Andy: 10:34

And I think that also indicates perhaps why we're not seeing quite such a massive uplift in the number of people approaching this for their own projects because AI is not going to help people to learn the difference between technical approaches. And so folk who want an app, they assume because you access everything through a web browser, app means what we would call web app. And there's perhaps a little bit of education or enlightening that we need to do to help people to realize there's actually a big difference in the types of technologies that could be used and the benefits of them. So I don't imagine many people are going to their their coding or vibe platform of choice and saying, you know, build me a native app that I could put onto my phone. They just want an app.

Andy: 11:17

It goes on to a website. They upload it to a cloud system, and they're away. Whereas we could help them to build much more if they were understanding, that native was of benefit and potentially a much better fit for the project that they're that they're building. But I think we perhaps, yeah, need to to help people realize the the difference there before they can actually start to adopt it.

Dominic: 11:41

Yeah. Totally. Totally. I can I can see myself a you know, if we are there, I don't even know? I don't I don't I don't know.

Dominic: 11:49

But if we are talking about power users trying to build themselves, I I always say to my wife things like, you know what? Before they were Microsoft Access in companies, and they were they were people that were able to build kind of, you know, quote unquote, advanced tool for themselves back then. And it was this thing was was able to to connect to to the main database of the company and they were able to I don't know. Just build things without having to ask the IT department or or any any people inside the internal. So but I I I hear what you are saying by by saying when you when you are asking, I need a nap, the the LLM, know, first choice is probably, you know, oh, that's React.

Dominic: 12:39

That's React with with maybe some some kind of back end, but but, yeah, this is this is interesting.

Andy: 12:48

Absolutely. It it feels like, you know, we could accidentally be slipping backwards a little because the the the power that was in the tools, in the hands of people working in this area, like you say, used to be so much more sophisticated and perhaps, you know, easier to to understand because it was visual. And early of the LLM age, we've gone through prompting only, and so we've lost that graphical medium. People are working at a text level, seeing something graphical output perhaps, and then going back to the text again to to work on it. So it's it's less it's less approachable, which is yeah.

Andy: 13:22

It is a shame actually, but of course, you know, business could be doing stuff to to educate people and these technologies move on, and we are still in the early days, I'm sure, of the the generative coding.

Morten: 13:33

I've also seen a few projects come out now where I don't know how familiar I would like let's see. It's Aaron Francis who did what is it called? Conductor or something. But that was like I think that's a a native app he's building. So it seems like maybe there's a little uptick in, okay, I can actually do really cool stuff

Andy: 13:53

Yeah.

Morten: 13:53

With with these tools. But maybe it's a you're right in in the fact that it's education or being aware of the after these things exist, and it's actually quite easy to work with.

Andy: 14:07

Awareness is such a good word there. I completely completely agree with you. So I was really fortunate to have been building mobile apps in the vicinity of smartphones when the iPhone emerged and when Android gained in popularity. And native was everything. Right?

Andy: 14:21

And and people just kind of assumed that's what you were building, and that's what app meant. And somehow we slipped into a place where people have forgotten about it. It's largely a portal onto a website, and we've we've lost the advantage. Maybe it's being commoditized or or maybe the differences have have just kind of disappeared. And so we're we're in a world now where we're sort of at on on the web first, and that's what we've been surfing.

Andy: 14:48

When you can actually show people the difference it makes to have it running locally, they get really excited. One of my favorite things to do at the moment at conferences is is just to do a lightning talk where I I work on like a little topic. So maybe you've got five or seven minutes, I'll do three to four, something like that on I may I was working on this app. I had this idea. Here's how it came through.

Andy: 15:11

But at the end of it, I I like to go, oh, but, you know, this this presentation was also made by an app that I created this way, which is running on a desktop that I created this way. The terminal that I used is all Go code. And that way, you know, you're leaving people with kind of a bit of a mic drop moment, something where they can go, oh my goodness. I had no idea what was possible. And the conversations that leverages creates and and what you see people go off and make as a result is really exciting.

Dominic: 15:40

I so I suppose you are talking about the the GUI for for Linux that that was built on on top of Vine. Right? The the framework?

Andy: 15:51

Yeah. Absolutely. Fishos, which is ffyshos.com. It's kind of an an amalgamation of lots of different applications. The Fine Desk project is like the the window manager in the desktop shell, and a lot of other apps are pulled together into a distribution that allows people to experience a a graphical desktop with a reasonable amount of richness using only Go code and the fine tool kit to render it, and it's becoming more and more sophisticated.

Andy: 16:23

Occasionally, I'm really stretching the boundaries and working on a bug fix on the desktop before I present, and it can lead to some unexpected results. But we always get there in the end, and it's fun. I don't know about yourself, but I quite like living on the bleeding edge of of software. I think it comes with being an open source. Right?

Dominic: 16:42

Yeah. Probably, Martin. Less less for me these days with with the screen reader and whatnot. I mean,

Morten: 16:48

this is Of course.

Dominic: 16:48

Something I've yeah. But So I I did not I did not understood correctly that it was a full distribution, a full Linux distribution.

Andy: 16:57

Yeah. I mean, we're building on top of Debian, so it's not like we're coding Right. The the package manager or the kernel itself. That would be I mean, for even for myself loving to juggle lots of projects, that would be sheer madness. But it could emerge into something pretty cool.

Andy: 17:13

And we're we're trying to deliver the full desktop experience. So the the apps, the graphicals, the interactions, the the switchers, screen savers, terminals, everything that goes with it. And over time, the utilities to manage your screens and your your packages, all that is is coming along. But as you can imagine, it's a lot of applications. And and even with LLMs behind us, it's gonna take a while to to match what you would expect from from Nomor KDE.

Dominic: 17:40

Oh, yeah.

Morten: 17:41

I mean, if if Omachi can't be classified as distribution, I think you're in clear. Okay. I mean, I mean, that's probably a branding question from from DSH and 37 signals. That was a huge discussion. I don't know if you if you have used Omachi or seen the seen the project, but I thought it was a funny

Andy: 18:02

I mean, I read the blog post, I looked at the images, and I thought, oh, you know, that that's quite that's quite lovely. It works really well for the workflow that they have. And

Dominic: 18:13

as

Andy: 18:13

much as I could geek out about it, I'm I'm more interested in something that I don't know, feels more familiar, that's that's more approachable for

Morten: 18:21

Yeah.

Andy: 18:21

For beginners. So my desktop by default, is slightly less minimal. Everything that's critical to your day to day is visible when you switch it on for the first time. So it's a different aesthetic. But you're yeah.

Andy: 18:33

You're right. If they can call it one, I think we're definitely there as well.

Dominic: 18:37

Yeah. Let me let me dive a little bit deeper in that because I'm I'm extremely curious to to know. So is it is it a desktop environment or or it's a it's a it's a tile man management like I three and and things like that?

Andy: 18:51

Yeah, it's a full desktop environment, so your window handling is like your Mac OS or Windows. It's multi paned windows, you're dragging around on screen with full screen, maximize, minimize, that kind of thing. It has virtual desktop so you can see the window sliding around as you move workspaces and overlays like the terminal. So I have my favorite feature actually is like I call it the Quake terminal. I don't know if you played a lot of first person shooters, but particularly back in the day, maybe they're still there.

Andy: 19:22

With a keyboard combination, you can get a terminal sliding over the edge of your screen, issue a few commands, and then and then slide it away again. So the alt alt tilt, I think it is, is the keyboard

Dominic: 19:35

for the whole cheat console you're talking about. Right? Well,

Andy: 19:38

yeah. It could be used for cheating.

Dominic: 19:39

Yeah. Yeah.

Andy: 19:40

In fact, may maybe it's Alt Escape. I don't have the keyboard in front of me right now to tell you. But I quite enjoy just, you know, dropping in and out of the terminal. A lot of what I do is graphical, but sometimes you just need a couple of commands issued here and there.

Dominic: 19:55

That that sounds nice. Is it like a main fine application that is, you know, the parent of all of those things? How does it work?

Andy: 20:05

I mean, it is it is a big showcase of what FINE is capable of, but it's not used by a lot of people. So sometimes I feel hesitant in saying it's it's a big part because it doesn't necessarily represent the latest functionality or graphics and there's not so many people coding on it so it can be less polished in terms of quality, hence my comment about the fact it can have bugs and I warn people it's probably not to be their only desktop unless they are actually coding on it. I find it very helpful when people go oh maybe fine, it's just like for hobbyists, It's something that you can build a little app for your for your device. It's like, no. You can run a full machine on this stack.

Andy: 20:52

It's definitely got everything necessarily necessary to make that happen. It's my daily driver when I'm not doing media and podcasting and that kind of thing. I'm on Mac at the moment, but when I'm on Linux, it's what I use all the time. I find it a great coding environment. Yeah.

Andy: 21:11

I guess I just I would love it to be, oh my goodness, this is clearly just the best fine app out there. But at the moment, I think other people have so much creativity. It's it's great to see what what's being built in lots of smaller applications rather than just one massive one that's that's kind of reinventing what's possible and and bringing a little bit of new life to it.

Dominic: 21:32

Yeah. May may maybe I I asked wrong. So what I what I was saying, in fact, is, you know, once you log in to the to the system, now you I guess there's a main process that is starting. Is the desktop environment a fine app that is the parent of you know, let let's say I start a terminal and I start, I don't know, a web browser, for example. Are those two going to be child of of the of the final app?

Dominic: 21:57

Or, you know, how how does it work, you know, from a desktop environment point of view? Is is it is it like one app, or it's multiple small apps?

Andy: 22:08

Yeah. Okay. I see I see your question. Actually, happens it it starts before then. So if you're logging in, well, naturally, the login manager also is a fine app.

Andy: 22:18

So this one is called Fin, fine login manager. And, I mean, you know, it's just displaying a dialogue for for your username, password, maybe profile images, a selection of the desktops that you wish to log in to. So that's that's one application. FindDesk, the desktop itself, is what displays everything on screen. So you could consider that the parent process.

Andy: 22:39

It's launching all the other applications that that you would be using. At this time, it's built with x 11 support only. We're working to migrate to Weyland like everybody is, but I don't know. It's it's tough, and x is just better understood at the moment. And X being a client server protocol means that it's not necessarily direct parent child relationships.

Andy: 23:04

We do some clever stuff as well, so that if for some reason there is a crash in the desktop itself, you might imagine that's catastrophic, but there's tricks that I learned playing with Linux over the last couple of decades where you can have runner applications. So if there's a crash, we we log it, catch it, and launch the the desktop again, and all of your windows are are still there. So you don't go completely mad in the development cycle. Although I suppose I I I also failed to mention, because it's a a fine app, it doesn't have to be run only on on a Linux computer. It works everywhere.

Andy: 23:39

So if you're coding on it, you're away from your Linux computer, can boot it on Mac. It's gonna just show a window because you can't have a custom Mac window manager at the desktop level. It's going to pick in the icons from from your Mac instead of from your Linux system. And people have taken this to real extremes. There's people who are loading this onto their Linux phones and and using it as like their their launch, their I don't know what it's called on Linux actually, but the SpringBoard, I think, is what iOS calls it.

Andy: 24:09

So the the home screen for their mobile phone is is also a fine app, which is absolutely blowing my mind what's what's out there.

Dominic: 24:16

Damn. That sounds that sounds very, very nice. That that that was my that was my follow-up question. You know? How how are you developing this?

Dominic: 24:23

You know? So, yeah, that explained a lot. So you can you're able to because let's say when the the project started, it it, you know, it was not part of the of the Debian. It was not already on top of Debian and whatnot. So so so it was it was basically built like a normal fine desktop application.

Andy: 24:42

Exactly. Yeah. It just when when the application launches under certain circumstances, it realizes that it should be the desktop window manager. You know, if if it's launched into a Right. A vanilla graphical instance and there's no window manager, it takes control.

Andy: 24:58

Although, actually, yeah, I just realized you could do more random stuff with it because it's about window management. There's there's context where that could be helpful. So like multiple windows in a in a complex document environment can be helpful in other ways. And just recently, I'm I made a version that runs on the web. So obviously, a a fine app can be run through the web using WebAssembly, and there's now a version of the fine desktop that will load in a browser.

Andy: 25:26

And it can't connect to the applications running on the client because of sandboxing, but you can tell it different fine applications that it should launch. So you can you can actually run fine apps in a browser inside a desktop that's kind of managing all of the windows separately. It's almost a bit inception like, but I'm just trying to show what truly platform agnostic really means.

Dominic: 25:49

Yeah. That that is that is just crazy. And and you can build all of that from one OS. That that is also something that it I finally I find it extremely extremely nice. Am am I wrong in saying that there's there's some docker involved?

Dominic: 26:08

If you want to build let's say, I am I am on Linux and I want to build a a Mac OS application, a fine desktop application for Mac, do I need anything on my Linux machine or or the tooling allow me to do that?

Andy: 26:22

Yeah. You could take two different paths. It depends on whether you want to have full control over your tooling or if you want to have an easier process that that perhaps, you know, requires more more CPU. So you could download the macOS SDK and install some libraries on your Linux machine and compile the macOS directly using the standard tools. Because it's Go, it's fundamentally possible, But because it's CGO that we're using behind the scenes, you do need the the native libraries available.

Andy: 26:51

And similarly, building for 32 when you're on a 64 bit platform means you need additional libraries and the tooling that's capable of building for a different architecture. And a lot of people find that complicated and unnecessary. So there is a docker or a pod man based system called Fine Cross. It was originally donated to the community by Luca Corpo who is very generous in in having delivered such a big impact. It's been further developed by members of the community and it's still there.

Andy: 27:22

If you don't want the complexity, can run fine cross to compile your app and at that point it's it's going to work for for anything. So that can be helpful to get your Linux developer system to build your macOS binaries. I was about to say I do that for Android, but that's not really true because Android Studio is helpful for debugging and if you have Android Studio installed you can just compile the Android apps with the the fine tooling without any Docker or Podman. But particularly when you're going across desktop operating systems it it can be helpful.

Dominic: 27:57

Nice. No. Yeah. Yeah. Yeah.

Dominic: 27:59

I can't remember that now. Yeah. That's that's that's that's very interesting. So that led you to to create an interesting, you know, offering. Let's let's call that a product.

Dominic: 28:14

It's not it's not a SaaS like you mentioned to me earlier, but you you decided to to take a jump and create a a product that would let people build desktop application. I I would say, from from the comfort of a prompt or something like that?

Andy: 28:36

So I mean, Fine was created with the idea that building apps for all these different platforms was too hard. So we've got some solid tooling, really simple API so that any developer can now build an app for any device. And that's that's really great. I love where it's got to. However, I realized it fell short a little bit of the idea that anybody, like literally anybody, should be able to build applications.

Andy: 28:58

So the the product that you're that you're referring to is trying to figure out how we can do make that possible for people who aren't familiar with coding. And AI is obviously playing a big part in in everything, and it can help to to translate people's thoughts into code. And so we're we're factoring that in as well. So now there is a product that you can if you're a developer, you can open your project, you can drag and drop things around on screen, and you can write some code. So it's kind of a graphical development environment if that's what

Morten: 29:31

you would

Andy: 29:31

like. But it's oriented towards people who who don't know how to code, so we we want to get people into that. And the AI features are going to make that possible. So you can, like you say, you could prompt, you could write a description of the application that you're wanting, and it will think about it for, I don't know, five, ten seconds, and come up with a visualization of the application that you would like. And if you're happy with that, it will then load the full application editor, and you have the app on screen where you can edit, or you could preview it on your local computer.

Andy: 30:06

You could also choose to do something a bit more graphical. So, I mean, we've all heard the joke about, you know, some of the world's biggest applications were just an idea on the back of a napkin. Well, now you can sketch your app, how it might lay out the types of features involved on an app can or on your favorite image editor and import that into the application, the product is going to look at what you've designed and build that application so you could prompt it graphically instead of textually if that's what you would like. And this, yeah, is now available, we're hoping that people will try it out, it's at apptrix.ai, that's apptrix.ai and the applications it's creating are are fine applications. They're using Go and the fine toolkits with all of the benefits of the clean code you would expect.

Andy: 31:03

And additionally to that, you mentioned Docker and the complexities of cross compiling. We realized that this is a little bit too much for people, so it also has a back end that will build for any platform that you want. So when you're happy with your app, can tap the deploy button and choose any of the standard operating systems, and it will then spin up the appropriate compilers. And for your basic apps in roughly three to four minutes you can have Android, iOS, MacOS, Windows, Linux all compiled and then you can download them from our host or it will show QR codes for your mobile app. So it makes the process just as smooth as possible.

Andy: 31:44

I have a great quote, sorry, I'll stop in a moment, but somebody using this said they were so excited about it. They managed to build the first app onto their phone in less time than it took to read the welcome email, which I thought was pretty cool.

Morten: 31:58

That's crazy. And how so you you cross compile. How how does that differ from something like React Native? Because I've not done a lot of React Native stuff, but I heard about the the native it's not native builds, but there was issue with it. So don't know if my question makes sense, but when you cross compile with, like, with the fine the fine to a fine app, how how does how does this compare to something like React Native in terms of, I don't know, performance?

Morten: 32:28

Or is there any differences in terms of cost compilation there?

Andy: 32:32

I'm not an expert in React Native. I must admit. I just generally don't enjoy working with JavaScript, so I've I've stepped, you know, clear from there. I mean, the main difference is that you're using Go instead of JavaScript here. That's not a big deal when you're not actually writing the code yourself.

Andy: 32:50

When you compile a fine app, it is compiling it directly to the machine code of the native platform. That's why I call them native apps. It's not using the widget toolkit of the target platform because we offer consistency of look across all different platforms, but it is a native app. And so anybody who's curious or or concerned that maybe Apple won't like the tooling or maybe Google says it's not allowed, You could check out plenty of apps that have been deployed across the stores. There's a there's a showcase from the community actually.

Andy: 33:21

If you go to apps.find.io, it shows you about a 150, I think, apps that people have made, and there's a a categories selection for different areas that people have worked in, and there's a way to filter based on deployed to stores. So you can actually see Google Play and Apple App Store listings live and download the download the apps directly onto your device through the usual channels. So it proves that these are truly native couple of hours, there's no run time so we're not violating any terms. But also you're getting really slick boot times. It it should feel like a native app.

Andy: 34:02

If there's anything that, you know, is slower or there's a lag, anything like that, we've got a bug and you should let us know and we'll work on it.

Morten: 34:09

That's super cool. I I don't have much familiarity with React Native. I just read about people using using it, and that was always, I think, the conclusion that people came towards. Like, they they did the React Native app. They cross compiled, and then it got users, and they were like, okay.

Morten: 34:25

We need something different. So it's very cool to hear that you you get to a very close or you get to native builds. Yeah.

Andy: 34:31

Absolutely. I mean, that that's why I've gone down the route of the the complex technical challenges of native build because a web or a runtime or some sort of simulated graphics layer is just never quite the same. And eventually people look at whether it's PWAs or or wrapped web apps in a native shell, they go, it's it's just not quite good enough, you know, the the the responsiveness or adapting to the system settings interacting with the drivers devices. It's it's not all there. So we we definitely want to match the capabilities at every level.

Morten: 35:06

Cool. And that's really nice.

Dominic: 35:09

Yeah. Yeah. That that's true. My my my first experience it's funny that you said that you had a previous experience, Andy, you know, couple of years long long time ago with with with apps and and mobile. My my experience was I tried to jump into that that band bandwagon back then.

Dominic: 35:29

I really which is strangely, but myself, I really enjoy Objective C. That was not the problem. The problem for me was all the all all the the the mouse dragging and dropping that you need to do to to hook down events and whatnot. So I I I was I was not I was turned down by by the tooling, but I I used PhoneGap back then. So so that was that was kind of it's it's exactly what you are saying now.

Dominic: 36:00

So it it was like a you could build web application and they were distributed on the on the, you know, mobile OS, but they were they were at the end just a just a shell and and loaded like that. So it was was not very not very performant.

Andy: 36:15

Absolutely. Yeah. It's it's a real shame actually that mean, I Apple's built such a phenomenal platform for the end users, but the development tooling, it just has famously lagged very far. And early X codes, it was very much drag and drop, understanding the code equivalents to avoid it was was very difficult indeed. The one thing that I'm trying to hold true with the product that we're building is that each action in the editor results basically in one line of code.

Andy: 36:43

So there's like a one to one mapping. If you want to, you can actually bring up the code that's generated alongside the user interface and and see directly what's changing, and it will link with a little line the widget with the line of code that creates it. So you can you can understand pretty quickly what's what's going on. And I I didn't really mention this actually, but we're we're not really believing that LLM generated code is the best code. So instead, the focus is on working with a domain model so that AI is understanding what you're trying to do and then creating a descriptor, you know, something in memory or persisted perhaps through JSON.

Andy: 37:26

So when it comes time to actually writing the code and compiling the app, do get proper thought out, carefully laid out code. It looks more like something that you might build manually if that's what you were doing. And so if at some point you like what you've built with our technology but you don't want to use the graphical editor or the AI anymore, you just save the project. In fact, it's saved on your hard drive already. You just take that project and you just work on it from there.

Andy: 37:55

It's a fine app. You could work with the the code that's been generated quite happily.

Dominic: 38:01

Nice. Okay. So I I I need to understand this this desktop application. So first of all, are you building Visual Studio? And second of all, do, you know, do I do I have, like, a toolbox?

Dominic: 38:14

Because you you're you you mentioned that you have the option that you can organize visually your your, you know, your your widget and whatnot. So that that's why I'm I'm I'm making that jokes of, you know, are you building Visual Studio? Because now it seems that you are building kind of a visual, I don't know, designer for people that would not really want to describe their UI would find, like, directly in code?

Andy: 38:45

Yeah. Absolutely. I'm not big user of of Microsoft tooling. I've not used Visual Studio myself, but in years gone by, I did play with Visual Basic, and actually Visual Basic six in some ways was a very excellent example of how to help people really easily build software. And it's like you said, it was around that time where individuals who were vaguely competent could build software that they didn't know how to code.

Andy: 39:12

They just made it very very easy. And there's elements of that that I I do think we're we're trying to remember or revive, but alongside modern graphics, modern techniques, and and all the things that make it more powerful to build in the current in the current time.

Dominic: 39:32

So when I opened the the desktop application, so it's a fine application that allows me to build fine applications. So I guess I I have some some kind of toolbox or something like that that displays me the widget, and I can drag and drop those things?

Andy: 39:46

Exactly. Yeah. That's that's quite right. We have a couple of prebuilt applications if people want to, you have a little bit of inspiration, but basically you're working with a canvas and you're arranging widgets in containers and you can drag the widgets from the library into the app, move them around, and of course you get then panel of features that you can configure for the widgets, you know, what a button says, the icons that are used, and the ability to manage theming as well so you can bring your your brand or your design into the application that you're creating. You're absolutely right.

Andy: 40:20

It's a fine app built to help you build fine apps. And like any good fine app, it's going to work on just about any platform. So if you wanted to be building an app on your iPad, you could load this application there and and get coding. Of course, the developer tooling is not available on an iPad, but because we have the cloud infrastructure, you can deploy it to all your operating systems from an iPad by using the the build system that we have configured at the back end.

Dominic: 40:49

Yeah. But that that that is my concern. So what if what if someone does not have the the the Go tool chains at all or any any kind of things like that? They they could still in install this this application. Now they are able to drag and drop their widget and whatnot.

Dominic: 41:03

What happen if they want to build that?

Andy: 41:07

Well, exactly that. You don't have to have any tooling installed at all. It can run-in, like, a developer mode. So if you've got all of the tooling installed, instead of just previewing the application, you can truly run it locally. So you tap there's a run button that's enabled.

Andy: 41:23

If you've said you're a developer, it will use the local tooling to compile and run the app locally. If you don't have any tooling or you don't know what those things mean, that functionality is hidden, and all you have is the deploy button, and that will outsource it to the to the build system, and you'll be able to then download the resulting app from the from the infrastructure.

Dominic: 41:44

Okay. Okay. Yeah. Yeah. Yeah.

Dominic: 41:45

I was I was starting to I was starting to fear that you embedded, like, I don't know, TinyGo in in there, and and you were doing all the compilation and whatnot.

Andy: 41:54

So mean, it's definitely something we've considered because we want to bring as much down to the local as we can. Yeah. But as you've already indicated, compiling is a complex thing, and if you if you were to then spin up containers and do all sorts of things, you're going to, you know, potentially run out of space or use too much CPU. And and for the target audience, I think mostly they just want to know that it's working and they don't have to worry about it. And so us managing that infrastructure makes a lot more sense.

Andy: 42:25

It's actually it's using the same fine cross technology under the hood, but instead of Podman or Docker, we have Kubernetes cluster that runs the containers and and launches it. And that's that's why it's so fast because we can we can spin these up in in parallel.

Dominic: 42:45

Interesting. Yeah. Do you do you do you foresee a software engineer wanting to build, you know, or people that were already building fine desktop application, but might not have you know, there there's always there's there's all types of of software engineer, and some might prefer to have a visual designer to build their their their UI interface. So do you do you think that even though even though your your product seems to target maybe more like non developers, do you do you think that still there there might be a couple of people in in the community that already know fine that will prefer to use the visual designer?

Andy: 43:25

Oh, definitely. Yeah. I mean, I'm I'm one of them, honestly. I I do enjoy a graphical editing session. Part yeah.

Andy: 43:32

There's there's there's just something about graphical tooling that is sometimes difficult to get what's in your head onto the page really quickly. And so I'll often start an app in AppTricks. I'll pull together the graphics, lay it all out, save the project and then go back to my traditional command line editing setup. I do coding videos on a Patreon channel and one of the projects I worked on recently was a really fun little slash dot reader so just a newsfeed RSS reader with articles, imagery, that kind of thing and the user interface thrown together in Apteryx in about four minutes and connect it to a data source and then do that was like the first version of the app and more recently I've added some caching capabilities so it works offline and you can read the articles at your leisure. That was very much a a coding part of the project, so I definitely work with these two systems alongside each other.

Andy: 44:34

And our pricing has been set up to match that as well. So if you just want to use it for a quick tweak of your graphical setup, you can use the free tier. It's not going to cost you anything. Just download the app and you can get the basic functionality with an integrated terminal, of course, because, you know, every developer needs a terminal. Or if you want the AI functionality, there's a really cheap tier, which is basically just covering our token costs.

Andy: 45:01

And so you as a developer can issue some queries onto the code base, do something, maybe work with the assistant to get your visual up to a point where you then take it elsewhere. And then the tiers after that are where it's designed for for people who just don't have the technical knowledge, and we provide more functionality and more support to help them build the the richer apps without coding anything.

Dominic: 45:26

What are we able to do with the terminal? When you say terminal, why do I need a terminal in in the find desktop application?

Andy: 45:37

Really Excuse me. I suppose in part it's just because proximity and convenience. If you're in an IDE most of the time and you're working with code, you might pop up the terminal to do a build or a search or something that's just easier with text. Even if you're doing a graphical editing of an application that will be presented graphically graphically, sometimes you just want that command line to be able to do something quickly, a search or an execution, or maybe you want to prompt something that's going to help build that project that's not included in the user interface. In part, I think it's sort of matching the aesthetic of FINE's design itself to be really, really easy to use, very simple to get started, but to provide the ability for people to extend it and do more if, you know, they have the the knowledge or or desire to do something custom.

Andy: 46:35

So much like any widget can be extended with code, the graphical editor of applications kind of allows you to drop to terminal level to issue some commands if if you want to. But that really is a developer feature. It it doesn't really advertise itself if if you're a nontechnical person.

Dominic: 46:53

But are we able to write code as well in in this application then? There there's there's no there let's say I have a button. What what happened? What what happened?

Andy: 47:04

Oh, yeah. Have a button. So, I mean, the default flow is for you to use the editor to say, you know, on tapped, should do something. And we're looking at all of the different ways that you might want to hook something up, you know, to perform an action that's predefined. But obviously, lot of in a lot of what your app does is specific to your app.

Andy: 47:27

So one of the flows is I want some code to run. And what that does then is it initiates or it creates a new function definition in it in a Go file, and then it opens that Go file for you to fill in a little bit of code in in the editor.

Dominic: 47:43

Okay. Otherwise, it's all visual. So there there's predefined things that that are there to, you know, normal response to a click of a button. Right? I could I could do I don't know.

Dominic: 47:56

Save something to the database? Is is that is that something that is there?

Andy: 48:01

That's the kind of thing that we're aiming for. So the the graphical functionality for data manipulation I'm working on right now. So I I can't promise that all of this is in the UI right away, but if you download it, then updates will be made available and it automatically detects them. So don't hold don't hold back to anybody who's who's looking to play with it.

Dominic: 48:22

Nice.

Andy: 48:23

Yeah. But of course, two two way data transfer is is part of the fine API. It's built into a lot of the standard widgets. So my thinking is that sometimes when you're working with data in your application, you just want it to automatically stay up to date. So maybe pressing a button saves the data somewhere or maybe it's part of a it's already been saved, don't worry about it flow.

Andy: 48:46

The complexities of this are very much I think in the the workflow. I'm working with a professional designer who's who's been part of a few companies of mine in the past to to really polish this in in coming releases to make it straightforward and and easy to understand.

Dominic: 49:05

Sounds good. Sounds good. Yeah. Yeah. Okay.

Dominic: 49:07

So, yeah, I understand a little bit more the terminal now because okay. So you are you are you are building a a real exactly is it exactly similar to what v b six was, you know, in a sense ish.

Andy: 49:21

Ish. Yeah.

Dominic: 49:22

Yeah. That that no. But but I mean, it's it's it's interesting. I I'm now seeing more clearly what it is. I I haven't download it.

Dominic: 49:29

I haven't tested it because, yeah, of course, it's not accessible, so

Andy: 49:32

Yeah. Of course. Then then once once we've got the accessibility in FINE, then the application itself will be built with that version of FINE. The accessibility will be built in, and all of the applications that you build will be accessible. But at the moment, it's it's still in the poor request, it's not quite baked into everything.

Andy: 49:50

Yeah. You're right, though. V b six is a good model, and one of the reasons, I think, to have developer functionality, whether it's a terminal or something familiar like code present, is partly to be extensible, but also to help people realize this truly is an application that they're building that they can take away and rely upon. It's not a web service. We're not locking you into a monthly subscription for your application to stay alive.

Andy: 50:14

We are just helping you build. And if you don't want this after the build process is complete, that's okay. You've deployed the application. It's in the store, and nobody's going to try and charge you money just to keep it there. Well, I mean, Google and Apple might, but but we don't really care.

Andy: 50:28

You've you've built it. You know? Congratulations. It's now yours.

Dominic: 50:30

Nice. Nice. Wow. I I imagine that when you started the project, you know, way, way back, you could not really imagine that that you were you would be there today having an app a desktop application that allows people to build fine desktop applications. It's kinda it's kinda very nice.

Andy: 50:51

I I really love where it's got to. I I don't know if I foresaw what was possible or where it was going. I think I had at the back of my mind some thoughts about what should be easier, and if we could crack it, I kinda realized what was possible but to think that we would achieve it that's a real long shot. The thing that I find really quite gratifying at the moment actually is to bring all of these things together. If you do download the the PhishOS or you use the the fine desktop system, then the application bar, like, it understands this ecosystem.

Andy: 51:29

And if you have some open source apps installed that were, you know, made in this way, you can not you know, where you would left click to launch an application, you can right click to bring up the context menu, and for the applications that, you know, this that understand this, it will say, you know, you can edit this application. And so the system will download the source code and load it in the AppTricks editor. We have, like, a a free for community open source version, and it gives you the ability to graphically edit the application on your system. And when you're done, you save it, you you install the new version that you've created, and it overwrites the the binary that's that was on the system that was shipped to you. That feels kinda like full circle.

Andy: 52:15

We've done everything we can to help people build applications and to learn about the process and empower them, I suppose, is where it's all got to. I I feel like we've done just about everything we can, and it's a case of features, polish, and and Outreach now.

Dominic: 52:31

Yeah. Wow. How how does it know that this app or this binary is coming from an open source project?

Andy: 52:39

It's a little bit of metadata. So the the Linux desk standards body, the free desktop organization, defined a .desktop file. It's a piece of metadata that sits on your hard drive, that says where the application is, which icon it uses, and we have injected a little bit of custom metadata in a in a format supported by the protocol that identifies it as a fine application with source available at a particular place, and so it then knows everything it needs to to to download. And of course, it's built on the forward thinking setup of the Go team right at the early days when they made it easy to discover software and made it very standard for the way that these projects are set up. We just leveraged a lot of that and and taken it to to perhaps another level.

Dominic: 53:32

Nice. Yeah. That's that's that's very nice. So yeah. What what what about the the community?

Dominic: 53:39

What about the project? Is it is it getting harder and harder to maintain? Because now it's growing, you know, there there there might there might be are you saying no a lot? Is is people wanting to to have a lot of functionalities that do not align? Where are things regarding this matter?

Andy: 54:02

I I try to say yes as much as possible, but I know to most people particularly for coming to the project for the first time, might feel like no is is said a lot. Of course, the secret I think to saying no is to describe exactly why something doesn't fit and the steps that might be taken to adapt it so that it did. We're seeing lots of great contributions. And I think if if people read the contributor guidelines, understand the the way that the API is set up and how it works, it's quite possible that your first PR will be a yes, maybe after a little bit of tidying and some CI has run. But it's not a difficult community to get into, but it is a colossal codebase at this point, there's lot to understand.

Andy: 54:50

So if you find an issue, log it, work on it, and contribute back. Bugs are pretty straightforward to get in. Feature development is harder. Where our maintainer pushback comes in is around API design. Over the I think we've been going for about eight years now.

Andy: 55:10

We've obviously wanted to accept a lot of functionality that we couldn't because it wasn't presented in a platform agnostic way or it wasn't aligning with existing API. And we really need everything to be, you know, path of least surprise, I think I've heard it called, where developers sort of they know what to expect based on what they've typed before. And obviously, that aligns really well with LLMs as well. They want to just generate something that's probable rather than strictly correct. So we want to make it most likely that what they output is is going to succeed.

Andy: 55:46

And we have been very lucky with the number of people that have come in. Think GitHub says we've had nearly 150 contributors over that eight years. We try to maintain a team of core developers of around like five or six people and we have people coming in, you know, wanting to contribute more and of course life gets in the way so folk maybe disappear off as well. But we have a vibrant group of folk who are building this. I don't think it has gotten more difficult over time, but it does take a lot more time because just the volume.

Andy: 56:23

So I'm keen to look at workflows and processes that can help to streamline things. I don't want to take the human out of the loop, but design is very important and having people feel that they're really being spoken to by by folk who care is core to a good community, but optimizing things is is going to be important. We have been lucky that we've not been inundated by AI swap, but there are occasionally those tickets, PRs or or issues opened where you know that somebody's been frustrated and they've used an LLM to remove the frustration and just sort of push it out into the world. And that doesn't always come across with the most refined presentation of you know what's on their mind. So we do sometimes have to work with folks to get down to what truly is the problem or how we can find the best resolution.

Andy: 57:18

But I think largely we've seen AI tools being used as productivity boosters more more than just, you know, generating stuff that folk didn't want to put the time into.

Dominic: 57:32

Yeah. Super interesting to hear you talk about a project like that. So when when you say colossal and eight years, those are two things that I find extremely interesting for a Go project. So what are we talking about here? Do you have a lot of technical depth?

Dominic: 57:50

Do you what about the backlogs? You know, what what it what it looks like a a typical week in the core team of of of the fine toolkit?

Andy: 58:03

Oh, wow. There there's a lot in there.

Dominic: 58:05

Yeah. Another episode maybe?

Andy: 58:08

Quite possibly. I mean, yes, of course, there's technical debt. You you can't work on a project this long and stay on top of it, so there's no debt. I suppose technically it would be possible but the challenge I suppose of open source is there's always people pushing for something that they need and it can be very hard to juggle the priorities that nobody's going to notice versus what they're going to see immediately. And so doing the things that help the project in the long run can be challenging.

Andy: 58:42

We have a backlog that captures quite a few of those. There's tickets that track. What will we do when we upgrade the Go version requirement, which which we lag quite heavily because we want to support people who are just using, you know, whatever Go version is is in their package manager by default. So we're we're often behind by a a few versions what the the cutting edge is. Of course, we test against the the latest to make sure it's all working.

Andy: 59:11

There are issues that have been open for a very long time where it's quite complex to understand where the problem lies and not a lot of people have been affected. Interestingly, I found recently that AI has helped with this because it can see by examining, you know, all of the documentation and all of the code ever written. Can it can kind of see solutions to problems that have not been obvious to to us, so we're seeing resolution of tickets that were opened. I think what I did a couple of days ago, it was issue number 255 finally got resolved. And for context, you know, we're we're kinda in the four thousands tickets at the moment.

Dominic: 59:50

Wow.

Andy: 59:51

So we we try to stay on top of it. We try to triage appropriately. We have not yet instigated a automatic. This ticket has been dead for x amount of time, so we're closing it. But at the same time, if it's been needs information, for example, if it's been tagged as needing to know more for six months, we'll we'll just say, look, you know, we'll assume the issue isn't there anymore because things move so so fast.

Andy: 01:00:20

Yeah, so there's lot to do. I I'm actually I'm just finding that working with it is still very much fun and to stay motivated to help people solve their problems part of what I need to do and I would recommend any maintainer really is to use it yourself, explore the possibilities. And maybe for us that's easier than than for some others. We're building, we're enabling graph collapse. It's a pretty thing.

Andy: 01:00:51

You get something good to look at as a result of the work that you're doing. But on a day when I feel, oh, there's so much to do, I'm behind, and these people are waiting for stuff. Sometimes I just take an hour, build something, you know, cool, add functionality to to a project that I'm using elsewhere, and it reminds me that, you know, this is this is a fun project Yeah. And people are are getting a lot out of it. I don't think I answered half of the questions there.

Andy: 01:01:12

No.

Dominic: 01:01:12

No. That's good. That's good. It's yeah. It's you know, it's very hard to for for anyone that do not have a project of that of that size and and popularity to really understand what it is because at the end of the day, I mean, this this this is this is a huge this scene yeah.

Dominic: 01:01:31

This is this is a lot of work.

Andy: 01:01:34

Yeah. I don't think I I remember now you said, you know, what's a typical day look like? I don't think there is typical day, but it would be fair to say that a day usually starts with reading my GitHub backlog, or notifications backlog, and then at some point during the day, I will go back and look at what's happened, how is the CI working, what pool request needs a little bit more review. And then I'll probably wrap up the day by working through that again, making sure that who have done something through the day have got the reply that they're looking for. And in between times, working with the community on on Slack or Discord or Matrix as well so that if for some reason, you know, there's a question that nobody else has got to, that everybody is getting the help that they need within one day at the longest of of having asked for a bit of support in the community.

Andy: 01:02:28

I I think that's important to keep people confident that the tech is is moving forward and that they can be helped to to understand it. Yeah. Other than that, yeah, it really is just managing a backlog, careful prioritization and catching up with the core team of maintainers so that we know that what we're looking to get into the next major release is progressing slowly but steadily, And so we don't end up with, you know, one or two weeks before a major release going, oh my goodness. How much functionality could we cram in the next ten days of development?

Dominic: 01:03:01

Yeah. Wow. Yeah. Seems seems to be very very nice. But but, yeah, a little bit of toll sometime, I I I could imagine on on the shoulder.

Dominic: 01:03:13

What about oh, yeah. Go ahead.

Andy: 01:03:15

I'm sorry. I was just going to say it it there yeah. There's there's a lot to be done. But I think as long as as people coming to an open source project with a request or a frustration understand that we're we're all just trying to do our best in what what time we have available, those conversations will usually go well. I'm sure that you've all seen the the classic, I've got a problem with my business.

Andy: 01:03:41

It can't succeed until this issue is resolved. I don't believe that you don't think this is a major issue. Well, sponsorship is available if your, you know, financially viable business is critically dependent on this thing that I've given you for free Yeah. I I don't want to be blunt and and unhelpful about it, but perhaps share the love and we can actually progress together.

Dominic: 01:04:03

Totally. Totally. Yeah. That makes sense. Wow.

Dominic: 01:04:07

Andy, that that is that is always interesting. So, Morten, do you have any anything before we we wrap up?

Morten: 01:04:14

No. I I it was very, very interesting to hear, Andy. Very cool projects. I I was a little bit on the back burner here. I don't have as much experience with all these things, so it super interesting to hear about how you how you approach these things and what you have built with it.

Andy: 01:04:28

Oh, cool. Well, absolutely. I mean, everybody's got to start somewhere. And if we just sparked a few people, perhaps yourself included, who will look into what could be done, try out some of the example apps or see what's out there. I just yeah, I hope that we can help people realize what's possible with Go.

Andy: 01:04:45

It's such a productive language, it's really clean, and having said this technical debt, I feel like it's a language that suffers that far better over time, and I think looking back over eight years now, we pushed version one point zero, I think roughly eighteen months into the project. So we're now over six years without a critical breaking change, and I can't imagine having done that with with any other language.

Dominic: 01:05:12

It's cool.

Morten: 01:05:13

Yeah. I mean, any any any project of WORF will have some some some technical debt. Right? You can't really make anything interesting or not. And I mean I mean, probably, theoretically, yes, but in practice, it's it's very hard.

Morten: 01:05:27

So that's but it's cool to hear you did so long without any breaking changes.

Andy: 01:05:32

Yeah. I'm hopeful that we can continue without having to do a version three. In a way, you know, it's a shame that it's it's v two because, you know, if we'd held off just a little bit longer, the trouble is you're always going to find something, and so we aggregated changes that were necessary that were breaking, did them all at once, made v2, and we're now aggregating them again. Here's what we would do differently if we had a fresh like if we could break the API, we have an issue tracking that as well. But so far, it's not so big as to actually warrant doing so, and we're gonna do our very best to never have to break the API for anybody.

Morten: 01:06:10

Wow. Nice.

Dominic: 01:06:13

Yeah. Because let's let's let's be honest. You know, releasing a major version is still kind of a pain for for a lot of people, especially when you have a a popular project like like yours. The the there's there's a lot there there's there's probably a a lot of questions that pop up and whatnot, and yeah. It's it's it's a it's a huge decision to make at this point.

Andy: 01:06:36

Yeah. And I think also that's been reinforced now by all of the training data that's gone into the language models we rely upon, because I don't think they really understand semantic versioning. The further you get from a breaking change, the less likely they are to make that mistake. But I do still get generated code include a version one dependency when it really had no reason to. So there's there's that reason to to to only make additive changes going forward.

Dominic: 01:07:06

Crazy. Crazy stuff. We are we are now building for LLMs, friends.

Andy: 01:07:12

I I think that's not a big deal. As long as we can keep building how we want to build Yeah. And build for them as well, that's okay with me. Just I I mean, I don't know if if you have have got heavily into MCP, but I feel like if we if we've written APIs really well, you know, whether it's web services or or local based APIs for for your language or your your standard library, if we've done that well, an AI shouldn't need us to tell it how it works. So so the concept of MCP, I'm a little bit shaky on.

Andy: 01:07:43

I think we just keep doing a good job, and it will understand it.

Dominic: 01:07:49

I agree. I agree. The and have you have you done anything to your documentation, though? Because I I've I've seen that more and more people that are exposing markdown file for their documentation. I don't know why or but I I I've seen that a lot these days on website.

Dominic: 01:08:05

Links like LLM documentation.

Andy: 01:08:08

We don't have anything LLM specific, but perhaps we were accidentally ahead of the curve. I I believe for many years that markdown is an incredible format because it is it is minimal, but it is just enough sophistication to get across the point that it's making. And all of our documentation is either in Go source code or it's in markdown files that are then rendered onto the web. So the source of all of the truth of our documentation is in flat text files somewhere, and the LLMs can scrape all of that. And I think like any good open source project, all of the websites for Fine are open source and and accessible through the Yeah.

Andy: 01:08:48

The organization's repositories.

Dominic: 01:08:50

Solid. Yeah. Yeah. Yeah. I'm I'm all in all of all that as well.

Andy: 01:08:55

Nice. Yeah. Cool. It's good. It's good.

Dominic: 01:08:57

Oh, yeah. Andy, that that that is great. That is great. I I won't take you too much time, but it was it was very interesting. So if people want to check, you know, it's the it's the year of the Linux desktop might be a good time to start building desktop application?

Andy: 01:09:13

Absolutely. I I think we're we're definitely getting close. And there's enough people, I think, working on this now. Maybe it is LLM or maybe there's just some inspiring changes, but but more people are working in this space. And And I would love to just sort of chat with people about what they're thinking and and have contributions across the board.

Andy: 01:09:31

You know? It's the type of thing where if it gets better for one project, it get better everywhere.

Dominic: 01:09:36

Absolutely. This is this is great. Thank you. Thank you so much for your contribution and for coming to the episode.

Morten: 01:09:43

Yeah. Super interesting to hear.

Andy: 01:09:44

Fantastic. Well, thank you so much for having me. It's been really great to chat this all through. I hope it's been interesting. And, yeah, I look forward to to following up on the chat channel or or meeting meeting some of the the audience or yourselves in person at some point as well.

Dominic: 01:10:00

Excellent. Alright.