Betatalks the podcast

In this episode, we speak with Isaac Abraham. He is the founder of Compositional IT and author of the books 'Get Programming with F#' and 'F# in Action'. We talk about programming with F# and how it compares to C#. What are their differences and similarities? We discuss why F# is not yet a widely used language.  What made Isaac push through all the difficulties when getting to know F#? What advantages did he enjoy? What made it productive and rewarding? And how does it work with Unit Testing? We also share experiences about working with and switching between different languages, for example from F# to C#, or C# to Typescript. And, he elaborates on the SAFE Stack initiative - Saturn Azure Fable Elmish - and the benefits of working with it. Furthermore, we talk about the value of functional programming and Azure Container Apps - the service Isaac is most excited about.

About this episode, and Isaac Abraham in particular: you can find @isaac_abraham on Twitter, check out his website and find his very interesting books here 'Get programming with F#' and 'F# in Action'.

About Betatalks: have a look at our videos and join us on our Betatalks Discord channel

00:00 - Introduction
02:42 - Friend of the day
04:07 - Explaining F#
09:21 - What made Isaac use F#
14:23 - The difference between F# and C#
18:58 - Mix and match between C# and TypeScript
22:20 - What is Fable?
33:45 - Totally random question
35:00 - What is the most impressive Azure service?
41:08 - The best old Azure service
45:42 - Closing

Introduction - 00:00

Oscar
Hey there, welcome to Betatalks, the podcast in which we talk to friends from the development community.

Rick
I am Rick.

Oscar 
And I am Oscar.

Rick
Oscar, what have you been up to lately?

Oscar
What I've been up to, I've been busy. But I did something really fun. We had one client, I have two teams. And some of the guys on the team are actually, we also have some girls on the team. But some of the guys are in Serbia located or they're remote workers, mostly responsible for test automation. But they were over for a week. So you had the whole team at the office. So we did some fun. We had some drinks, you know how it goes. But we also cut out the full day to do workshop of mob programming.

Rick
Mob programming program. So we know programming, we know pair programming, and now there's an entire group of people.

Oscar
Yeah, so we had the two teams with their product owners. I gave him the introduction, showed some comments from Woody Zoo. I don't know if you know, but he's kind of the grandfather of this idea, I think. And we started wanting to just started experiment and learn from it. And yeah, full teams, product owners, everyone. We had one computer in a room. And we had one of our surface hubs as a big screen. And the one typing is, is the driver, the rest are navigators. And we had one story to complete from start to finish. And our goal was to actually finish and have it in production end of the day, kind of a hackathon thing. But the actual mob programming is really enabling people to cooperate, cooperate and solve problems, ask questions and answer the question straightaway as a group, and then like, every 20 minutes, the keyboard goes to someone else, and even product owners were typing some code. And the funniest thing, of course, is like no, no, go back there insert a line at 77 and a half, so that you know that if you need to between these two lines, and explaining the product owners, what are braces, brackets and angle brackets? And that was a bit confusing, but we had a blast and at the end of the day, yeah, had some dinner and drinks after that.

Rick
But of course, of course, the big question is, did you meet the goal? Did you have something in production at the end of the day.

Oscar
One of the themes definitely met the goal in finally knowing what they wanted, and it was already halfway the day. And they actually wrote some decent code for it. And the other team actually went full un like full enter. And like 10 minutes before the end of the day, we ran the code first time in production that was shipped was done. And it was a pretty big story on the backlog actually, that's awesome. It was awesome. Like cool teams is great.

Friend of the day - 02:42

Rick
Who's our friend of the day?

Oscar
Our friend of the day is Isaac Abraham.

Rick
Isaac Abraham is the founder of compositional IT and author of get programming with F# and F# in action. He is a .NET MVP in both the UK and Germany, and a .NET developers since .NET 1.0 with an interest in cloud computing and distributed data problems. He specializes in consultancy, training and development, helping customers adopt high quality functional first solutions in the .NET platform. Welcome, Isaac.

Oscar
Welcome.

Isaac
Hey, great to be here.

Rick
It's so great to have you. So you're positioned in the UK?

Isaac
Yeah, actually just moved back here about six weeks ago. So I've been in Germany for the last few years. But now back in the UK full time.

Rick
Is it the idea that you go back and forth? Or are you staying in the UK now?

Isaac
No, no, I'm staying here. I mean, we still have some customers in Germany. So I'm sure I'll visit them from time to time. But yeah, and I'm back in full time.

Explaining F# - 04:07

Rick
Living in the UK. One of the things that that stands out in your bio, is the fact that you work with F#, even you, you are the author of get programming with F# Now, F# in the field, where I work in is not a language that I come across in production a lot. Probably you do. But could you for the people listening who might not know what F# actually is? Give us a short intro?

Isaac
Sure, sure. So I just described F# as a general purpose programming language, the same as C# or Java or Python in the sense that you can write you know, web applications, database applications, back end services, the main differences and it runs on the .NET platform. So the same as C#, or VB .NET, I guess, the main differences about how you actually structure code, some of the defaults that the language has in comparison to say C# or Java. But otherwise, to be honest, it's not that much different in terms of what you can do with it. It's more about the syntax of the language and the sort of the path that guides you down in terms of how you organize your code.

Rick
So it's probably a different way of thinking about your code and functionality it should hold. Right.

Isaac
Exactly. Right. Exactly. And to be fair, if you've been doing sort of more recent C#, you probably see some of the ideas coming into that language as well, I guess Java to an extent.

Oscar
Yeah, definitely I, all the things I apparently like in the new C# and people are telling me well, why don't you just go to F# then because this is from there?

Isaac
Absolutely. I think, certainly the last few versions of C# and I still, you know, I've probably spent more time coding C# and F# in my career. So I still have kind of an affinity to the language, and I still keep an eye on what's happening with it. And suddenly, the last few releases, there's kind of a lot of, you can see a lot of sort of precedents in terms of F# and there's nothing wrong with that F# takes features from C# as well. You know, that's always, you know, you look at other languages, I guess, to see what what's working well, and you try and incorporate it into your language. But then suddenly, the last few releases, I'm seeing, you know, things like pattern matching and records and things like this, that are coming into C# now.

Oscar
And you see, you see that, to actually be a bit more stateless, having immutability and stuff that is definitely a thing you see now, C# grading really, like short code, which some C# developers find hard to read, but yeah, comes naturally to me, then, yeah, you're gonna say, right.

Isaac
Yes, and I'm gonna resist the temptation disabled to say, but um, it's interesting, like, yeah, some of the syntax in like, the new C#, I sort of get some of it because it's kind of some of it is a bit similar, at least in concept F#. But ironically, I think F# is always had this reputation of being, you know, super complex language really powerful and stuff. But I actually think C# now, it's got more features in it than F#. I think F# probably has, you know, if you'd like that kind of pattern matching and record style, you know, state static functions approach, then pretty much that's what F# optimizes for it lets you do that other, stuff. But it's, it's probably got a smaller feature set now, then C#, which is, the last few releases, they've really started to put a lot of features into it.

Oscar
in C#, a bit more difficult to make a decision, especially if your codebase that's a few years old, to suddenly start introducing all these concepts, because it will either make a mess or trigger you into a rewrite of everything you did before.

Isaac
Yeah. And then you run the risk as I did some years ago, where the rest of the team sort of they see your part of the codebase. And it's like, oh, that's Isaac code. It's like, it doesn't look like any C# I've done before. So you know, that must be Isaac's code.

Oscar
Easy blame tool.

Isaac
Yeah, exactly. But, um, in that case, that was like the trigger for me, like, maybe I should start looking at F# a bit more now. Because, yeah, the C# I'm writing seems to, to not be what everyone else was expecting. I mean, this was an, you know, probably C# three days, C# four days when, when Link was out. And that's when it really started getting into that kind of style of programming,

Oscar
Where you're into the text version or the chained.

Isaac
I started with the text one, the four in and then I moved over to the to the pipeline, fluid style.

Rick
I even, especially in the start, sometimes I had to start with the text mode, and then translate that into the other mode because of at a very early start. Sometimes for me, it was hard to think of the chained one.

Isaac
Yeah, thank God for ReSharper.

Rick
Yes.

Isaac
I actually from the start that like I love that model, like and since then I cannot read the code anymore. Even. Like yesterday, calling of mine was, was debugging some code or was optimizing some code, but apparently it was a bit old. And I think I wrote it 12 years ago or something. And he's like, can you help me? What is this doing? Exactly? And he showed me a statement like that. I have no clue. Really, it's it looks so alien in a piece of C#, it does just floating around just syntaxes string there somewhere.

Rick
But it might help now in in stuff like Cousteau, where you have k QL as a query language.

Oscar
That I also love. Yes, that's a good one. But I like these kinds of really efficient tools. But sometimes a bit of raid is like I'm after I'm done. Am I the only one knowing how to read this now?

Rick
You want to be expendable, right?

Oscar
Yeah, that would be nice.

What made Isaac use F# - 09:21

Rick
But Isaac you just talked about the trigger for you to have a look at F#. But what makes you push through because I know people who have started looking at F# and then did like to start up or to default projects. And they looked at the code and they said not for me and they went away. So what was it for you that made you push through on actually getting to know F# and actually getting stuff out there running on F#?

Isaac
Yeah that's a good question. I mean, I guess there was probably two or three factors in there. Firstly, I went through exactly that journey. I think it took me three times to kind adopt F# the first few times, I probably did exactly what you just said, I did like file, new project, tried it did something like add two numbers together and then said, Yeah, this is cool. And then I sort of never touched it again for a few weeks. And then tried it. I mean, in those days, it was it was much harder to I think adopt F# because the documentation wasn't all there, the community was a bit sort of less, less well, sort of organized as it is today, Microsoft didn't really know what to do with it. So there wasn't really much from them, the tooling was way worse than it is today as well, it wasn't bad, but it was like compared to C# it was it was much, much worse than today. So you really had to want to stick with it to sort of power through as you say, I think at the time, I was getting kind of frustrated is probably the wrong word. But I wasn't happy with what I was doing in C#, like, I'd went through this whole kind of thing of learning about solid and all the design patterns. And then I started doing TDD. And I was able to like, my code was better, you know, I was getting less bugs from my customers and manager was happy with me and stuff. But I was thinking, you know, it's still taking a lot of effort to get this kind of code to a high quality. Is there anything else out there? So that was kind of the trigger, really for me. And then I started trying F# and I kind of what I really did was I think I gave myself a couple of projects. There was something I was trying to do, I think at the time, I wanted to write an app. That was it was something like if you're in the pub, and you want to know can I get another beer before my train arrives.

Rick
Already sounds like a decent app.

Isaac
Yeah, so it was something like that. So to do that had to like download all the train timetables and the UK Government published all that, sort of the National Rail timetables, and it was like, right, how far does it take to walk to the nearest train station? And then it was like, right, you know, as soon as 20 minutes for a beer, then can you make it sort of thing. And I said, let's, let's at least do the core business logic in F#, you know, the modeling and so on. And can I do it, and I sort of started it and packed away at it. And then within like, you know, probably a couple of weeks of evenings, bashing my head against the wall, I got something that I was pretty happy with. But even then for quite a long time I said, you know, F# is great. For the back end, it's you know, probably you have some functions that you call in from C#, but you still use C# to kind of orchestrate your application, you do it for the important stuff. And maybe just for some calculations, you'll use F#, and then gradually, probably over a period of a year or two, I finally sort of lost that kind of assumption that hang on a minute. Why can't you do this stuff in F# actually, you can talk to a database, and F# is just ATO .NET at the end of the day, what's the difference sort of thing? And once I sort of got over that sort of mental hurdle, actually, a lot of things started to become a lot clearer for me then. And that's when I really started to see the benefits of F#.

Rick
Well, it's actually very recognizable because people I've talked to that do a bit more in F# and I explicitly say a bit more. They always say yeah, it has its own use and its own valid use case or user story. While I hear you say you could do potentially anything there.

Isaac
That's right. I mean, I'm I kind of got to that point when I was like, well, if F# works for this small bit. And you know, I'm doing some calculations, and I'm doing some domain modeling in there. And some validation. Why couldn't I apply that same, you know, the same techniques to reading from a database or accepting JSON in an HTTP request and making sure that the correct fields have been filled in or modeling some some something that's more customer facing, rather than maybe something that's a bit more abstract. The truth is, you can definitely do it. And you probably should, to be honest, I mean, I can only speak from my own experience. But suddenly, I was I found F# to be way more productive and rewarding. Like, I felt that I could get more done. And I had a lot more confidence when I was writing code in F# and in C# not that I'm sort of saying C# is bad or anything. But for me, I found F# was just seem to get to the heart of the problem I was trying to solve with a lot less. A lot less fluff or rigor. Yeah, ceremony. That's the word. Yeah.

Oscar
And how is it with, for instance, unit testing and see a big difference there.

The difference between F# and C# 14:23

Isaac
The biggest difference for me was that I stopped using TDD. So we still use unit tests. And you can use the same unit frameworks like x unit and unit and that just works. The biggest difference, I think, is that F# introduces the script model. So I don't know if either of you have used like LINQ pad in the past. So F# kind of has that. But it's kind of a bit more than LINQ pad. Whereas with LINQ pad, you kind of type a script, you hit f5 or whatever, and it runs the whole code through. Whereas with the F# scripts, you can code a little bit and then sort of write let's create a function and test it out. And then in the script as you're typing. You can try Some other stuff out or maybe create some types and explore a domain without needing a console test rig or, you know, unit tests to really try things out, you can just start typing and you have a little sort of rapidly like a read evaluating printer, where you can get really fast feedback. So for me that kind of plus with eshops type system that the two things together kind of meant I didn't need TDD as much to like, nine times out of 10, after I'd finished coding, I would try it and it would normally work. But we'd still write unit tests for like regression. So if we come back in a few months, we make some changes, we still want that safety net.

Oscar
But does it then I think what you're describing is even pulling the coding already in your thought process where you normally would think about it and maybe write the test first. You're while thinking about it, because your code is so close to your thought process, you can actually start experimenting, and by the time you're done, you're actually already done.

Isaac
Yeah, yeah, I agree with that. There's kind of a couple of things about that. One is that with with C# and object oriented languages, in general, in the past that I worked on, I tended to as you say, sort of think about the problem first, and kind of take a top down approach, like what of my class is going to look like where's the relationships between them with F#, I kind of ended up turning it on its head. And I just said, Write, let's write a really simple function that just does one little thing. And I'm not even going to worry about how I compose it together later, I'll deal with that at some point later, this is write one function and get it to work and create the types that that function needs, you know, it needs a record as an input, and it's going to give back some other data or whatever. And then I'd write another one and another one, and then you sort of plug them together. And it just naturally seems to just sort of compose together quite nicely. Because it's everything is generally just functions calling other functions. You don't really have that kind of class hierarchy with maybe inheritance or interfaces, you can do it that you tend not to. And it tends just to be here, the simple functions, let's make another function that calls these other ones and composes them together, nine times out of 10. That may just look fairly procedural in some way, but it actually works really, really well.

Oscar
And does it then also, if you're back writing C#? Did it also influence the way you write that? And think about that?

Isaac
Yeah, yeah, I remember, when I was still kind of working in both languages side by side, I'd start to try and do things that you can do naturally in F#, and either you couldn't or still can't really do so easily in C#, and people would say, I can see what you're doing their eyes. But that just doesn't make sense. That feels really weird. The syntax I find quite difficult now in C# as well, because some things in F# either you'd like you don't need semicolons. You don't need curly braces, you don't even need parentheses most of the time or type annotations. So when I go back in C#, I sometimes really struggle with that. Just trying to remember where to put the curlies. And, like in F#, it's kind of like TypeScript where you do the symbol first, and then you put the type annotation afterwards. Whereas in C#, you say, you know, int x, in F#, it would be x colon int. So just sometimes I'll write I'll struggle even to write the method nowadays, just because I've lost that muscle memory.

Rick
It's the same for me when I work with TypeScript a lot, and then C#. And then if I mix those two in one project, I already have that. So.

Oscar
yeah, to use. The trick is like write all my TypeScript in Visual Studio code. And once I'm in visual studio, I know writing C#. So using another part of my brain apparently, then, yeah, but yeah, sometimes also, thinking like TypeScript. And then in C# is like, why I have to do this. Like, oh, all those backing fields and stuff. I love the constructor way where in TypeScript, you say, Oh, this is private, whatever, in your constructor. Yeah. And the field is already there.

Rick
Yeah. Yeah. I mean, why don't we?

Oscar
That's my, my CCR feature that I want.

Mix and match between C# and TypeScript -  18:58

Isaac
That's another one that the F# is actually has. Yeah. Just out of curiosity, let me ask you guys a question then. So you know, TypeScript got a really powerful type system. And it's got some really nice features in it. So how do you find that going back? Not back. But when you're flipping between the two languages? Do you start in your head, like trying to model stuff using certain features in one language that that just don't exist or wouldn't make sense and the other, like Union types or things like that?

Rick
That's actually a good question.

Oscar
And both ways. Definitely both ways. You're always only seeing the things that you're missing, of course. For instance, I'm in C# also. Oh, like, I've actually been have a small list for C#, but one of them would be a love in TypeScript that I can define string Enums. Yeah, like, that saves you so much hassle, and it's actually you don't have to translate it or interpret it or like, how do you throw it over the line, not as numbers. It's really declarative. So there are a few things that I really like And these days in, in TypeScript, and the whole async await, start started working. So we are moving away from the old observable. And now promises are coming back because you can actually await them now. Yeah, that makes so much sense. Because the chaining sometimes in those in that RX was getting out of hand sometimes.

Rick
It does. But then but then it brings the two closer together again, right?

Oscar
So more confusion for us.

Rick
Even less clear what language we're actually working with. No, but yeah. For me, I think it's, I used to have these couple of projects where I would I did mix and match between C# and TypeScript a lot. To be honest lately, especially since well, just like Oscar, I'm now working as a principal Cloud Architect most of the time. It's, it's either discussing and strategic stuff, or it's having a initial implementation or showing how stuff is done. Which means I don't get to switch too much between Typescript and C#.

Oscar
Well, you're forgetting the hobby projects, of course. But.

Rick
Again, yeah, well, to be honest, there, I switched from a couple of SBA frameworks that we don't we used to use now to using blazer web assembly, which makes it even easier because now everything is C# so.

Isaac
I was just gonna ask you about that. Like, do you still see C# as like the back end and TypeScript for the front end? Or do you look at web assembly or using like TypeScript with node on the back end?

Rick
Yeah, I'm doing quite a quite a few things in web assembly now, even at customers where they have made strategic choices to have web assembly be the front end for the long run. However, we do see quite a few companies that that don't dare make that choice yet. So they are now still more towards JavaScript based frameworks. Since if one framework dies, they still have JavaScript, which should still be relatively easily migratable. But yeah, you know, it razor has been here for quite some time now. So even if blazer, web assembly tends to die off, probably work hasn't been lost all the way.

Oscar
Oh, it's more than more of a model than then actual implementation of your code in the end. Yeah. And it's like with what we had another podcast with about bicep which is wrappingRM and like TypeScript, wrapping JavaScript, of course. And I want to go into that, because we were talking about F#. And I saw on your Yeah, and your company website, I think in a blog, you're speaking about the safe stack. And first I thought about sales. Thank God, about fable, actually, which is, like an F#, is that a transpiler?

What is Fable? - 22:20

Isaac
Yeah, yeah. So it's, it basically, its primary use is basically F# to JavaScript transformation. And it's, it's really nice. What I like about it is it's not a framework, it's literally just at its core, it's a transpiler. So you can give it an F# script or an F# project. And you can say, you know, .NET, fable, my project, and you'll get backed up JavaScript file with that code in it. And then on top of that, people have built a whole ecosystem, including safe stack. So there's kind of, you can do like interop, between JavaScript and F# really nicely with fable. So, you know, JavaScript has dynamic, you know, anything goes sort of thing with that. But whereas F# is pretty, you know, it's quite a strict type system, and it's got static typing everywhere. But the way they've done it in Fable is really nice in that, like, types will sort of map quite nicely across. But then if you need to sort of the escape hatch, and like do some dynamic typing, then you can still do that with fable. So it doesn't try and hide away the nature of JavaScript. It just tries to provide a bridge for you so that you can write stuff in F#, but still use all the JavaScript libraries that are out there. So it's a bit different, I think, from blazer, which is not sure it's entirely a walled garden. But it's a bit more of like a framework and its own kind of echo system. So you've got, you know, sync fusion, and all the other ones creating like Blaser libraries and UI frameworks,

Oscar
You stay in the language part a bit more with your solution. Yeah. And then of course, we're building towards another language.

Rick
Yeah. And then of course, with IoT, they do tend to compile straight into web assembly. But still, but yeah.

Oscar
The whole, the whole framework in there. So the stuff you're not typing, so that there's a small difference. This, this seems a bit more like TypeScript is then also built on top of the type bindings that origin for TypeScript bill.

Isaac
Yeah, so there is a like a coaching tool that you can say, Here's my TypeScript binding create me an F# binding doesn't work in every case, because TypeScript has got certain features that abstract doesn't have and vice versa. But it will usually get you 80 to 90% of the way there. And to be fair, there's a reasonably large set of sort of, I wouldn't say, you know, nowhere near as many as TypeScript because you've got the whole definitely type thing. But there's a decent set of bindings in F# for most JavaScript libraries. And to be honest, if you need to, like use one that's already out there. Once you've done it once, you can create a binding pretty quickly. It's not like a huge overheads like create entire classes. Most of the time we see people that need like bindings, they'll use probably 20% of the surface of an API for 95% of what they do. And so you know, we'll normally help people, right, you know, let's get you over the line, we'll get the basic one out. And then over time, we'll iterate and make slightly bigger versions of that wrapper.

Rick
We dove relatively straight into fable. But for people listening who aren't exactly sure, could you maybe give a high level introduction of what's safe actually is except for a scaled agile?

Isaac
Yeah, so, so safe. The acronym actually isn't so important now what it means but it was basically, when fable came out, what we started see was that you can do F# on the client and on the server now. And wouldn't it be great if there was a kind of a more opinionated way of doing that, that helped people write these applications, if they're, they want to do F#, they really like it. Let's see if we can create a stack that really puts F# at front and center rather than, you know, oh, we've got an object oriented framework that F# can use, we wanted to say like, can we write a stack that really takes advantage of everything F# can do all the way from top to bottom, and really fits nicely with the way that F# is designed to, to work. So I'm talking about like immutability, expression oriented design, declarative, those sorts of things that you would expect from for an F# application. So we ended up I think we're in a really good place where we were kind of sitting on top of runtimes, and platforms that are super productive, the super mature, like SP .NET, core on the back end, and JavaScript and React on the front end. So these are like big libraries, they're not going to go away tomorrow sort of thing. And then on top of that, we've got like F# sort of adapters that kind of give you this F# first experience. And we'll let you then still use these platforms underneath that. So for example, with ASP. NET Core, we're not using like web API or MVC, we've got a library called giraffe. That basically lets you it's almost like, if you've seen that, the newer airspeed on that with the minimal IPOs, the minimal API's, they're basically that's how people have been doing F# on ASP. NET Core for a long, long time. Like basically, here's an endpoint, hook it up to this function, and building pipelines like that, and then composing these routes into bigger routes. So we've got a list of these routes that are dealing with customers, and another list of routes dealing with orders, let's compose them into a bigger API sort of thing. And then on the front end, we basically looked at the Elm library language, which is kind of a, it's kind of similar to F#, in a sense. And basically, someone's written a very similar sort of way of writing applications for F#, on top of React and Redux. So you get this kind of F# first experience, you can do things like type sharing, and even function sharing. So you can like have a shared file that lives on the client and the server, maybe for validation, or maybe for your, you know, your types that you want to send on the wire. And obviously, when you hit Compile, you'll get the .NET version on the server and the JavaScript version on the client. But as far as you're concerned, you don't have to worry about the, the mapping and the and the transport between the two. Because it's that taken care of for you basically.

Oscar
All the sounds are also similar, like you're telling Rick working in Blaser, and I really like this is we need an opinionated model, where we can just be productive in. So every layer needs to be accounted for and, and then in your favorite language and even thought process in this case, because the language is different. It makes sense that you need a couple you need a, like a family of, of tools that go together to give you a stack where you can be productive from the start.

Rick
And especially if that's the case, I mean, I think I think that's actually a transition we went through in our line of work, where, let's say 10, 10, 15 years ago, you did you did your thing. You did one thing, and that was what you did. I mean you did Microsoft enabled or you did Java, or you did but you did one and then all other things were bad. And then even within one company, we did one thing. And now more and more we're looking at using the right tools that empower us to do the things we need to do in a timely fashion.

Oscar
And yeah, but still and then like with that, you know, like a lot of different stacks and frameworks but you know, like, I need this group to be productive. If I'm looking back at what was it maybe like 2014, or something, we were really hip and going forward into Angular and all kinds of frameworks. And every week we had a new one. But back then you had so much over engineering in those frameworks. And you needed to spend your first two weeks setting up the proper Webpack collections. But now, these tools also Angular, like, I'm still working a lot with that, like it comes out of the box, you can, okay pulls down a lot of good before you really started have been NPM installed.

Isaac
JavaScript there.

Oscar
But that's JavaScript. But you can start and it will build and everything's baked in, because the set of tools that you need this, this tribe of tools almost, is there, and you can plug in and plug out what you want. But at least there's some guidance there to get running.

Rick
Yeah, and I think we're still in our infancy as far as tools, technology and software development in general goes. But, but we are making some decent steps. Last couple of years.

Isaac
I think the need to get up and running quickly, is becoming more and more important, like developers just don't have the time or patience. If there's so many out there that already just get you up and running quickly. If you can't download a new framework and sort of start seeing results in just a few minutes. People just give up and then I'll go back to what I'm doing. So it's if you're going to do introduce a new platform or a new technology, I think it's got to, you've got to be able to show that result relatively quickly.

Oscar
Yeah. And also like the next developer next to you picking up the code or the new member on the team. Not having a complex, what exact version of what tool you're missing, just getting up and running and start coding like in that is so important, indeed there is no time to wait.

Isaac
Yeah. Interestingly, one of the reasons kind of why we started working on safes, that we knew that you could do this, but basically a lot of the F# devs that we worked with, I guess it's to an extent not dissimilar with, with other languages as well, you know, your focus on the back end, you're doing your C#, or your Kotlin or Java or whatever. And then you need to do something on the web. And it's like, oh, I don't know JavaScript. I don't know TypeScript. Or maybe you don't know JavaScript. And it's, particularly if you're coming from like a, you know, a statically typed world, where you've got this compiler that's helping you like going to JavaScript, the fear factor can really be a big bottleneck for people to start adopting, like browser development and web development. So we wanted to try and remove that, that, that fear factor as well and say, look, you know, F#, you know, how to write types and records and functions, you can keep doing that. Now, you don't have to give that up. And but the differences, of course, the runtime is different. So you can have to learn about the JavaScript ecosystem, you're gonna have to find, you know, webpack.js, living in your folder structure, and so on and so forth. But at least when you're writing code, that kind of that that's that problem is more or less solved. Now. You don't have to learn the language.

Rick
It moves away to the background, it's there, but you don't have to worry too much about it.

Isaac
Yeah, and certainly, if there's a framework are a set of libraries that gives you that up front, then you can start to at least try it out and typing, you may not know what's going on behind the scenes initially, that there's this thing called fable that's rewriting your code into JavaScript, and you know, what's going on with hot module replacement with Webpack and stuff, but you don't need to know that to start with. And we've got customers have asked that have been using safe stack and they really have barely touched it underneath any of that stuff. But they're still able to write applications for their customers, which trust is a win.

Totally random question - 33:45

Rick
Yeah, I can imagine it's a big one. Oscar, do you know what time it is?

Oscar
Is it time for a totally random question?

Rick
It is time for a totally random question.

Oscar
Isaac, when was the last time you last facepalmed?

Isaac
I probably do that quite regularly.

Oscar
During this call.

Isaac
The proper lather the last proper facepalm I did was I was in Germany a couple of weeks ago, doing a training course. Thankfully, it was in English. I had a flight back and got to the train station in the morning. It was like nine o'clock and thankfully I had a good four or five hours to get to the airport but got to the train station and it was just surrounded with police tape. And I was like what's going on here? And they're like, Yeah, police action. We don't know when the train stations can be open again. And I just like that's like typical my luck sort of thing. And I basically get a cabinet I got to the airport in time, but it was it was a long journey going around like half of Germany to get there in time. And I probably should have picked a different airport.

Oscar
Wasn't the plan indeed.

Isaac
Exactly. So It was like, bump

Isaac 

The proper lather the last proper facepalm I did was I was in Germany a couple of weeks ago, doing a training course. Thankfully, it was in English. I had a flight back and got to the train station in the morning. It was like nine o'clock and thankfully I had a good four or five hours to get to the airport but got to the train station and it was just surrounded with police tape. And I was like what's going on here? And they're like, Yeah, police action. We don't know when the train stations can be open again. And I just like that's like typical my luck sort of thing. And I basically get a cabinet I got to the airport in time, but it was it was a long journey going around like half of Germany to get there in time. And I probably should have picked a different airport.

Oscar
Wasn't the plan indeed.

Isaac
Exactly. So It was like, bump

What is the most impressive Azure service? 35:00

Rick
I think we touched upon it already just a little bit. But I would like to go a little bit deeper into Azure and everything cloud. You work with Azure, right? Because I think the A in safe is Azure for cloud-based systems. What's your? What's the service that has impressed you most over the last couple of, let's say, months or years? As far as Azure goes?

Isaac
Yeah, the one I'm most excited about is almost certainly container apps. Which I think it's not a preview. It's in them. I think it's now.

Oscar
And during building. Yeah, it's yeah, yeah, yeah. So.

Isaac
I've been using I've been using for a few months. Now, during the private preview as well, it's the thing I think Azure has always lacked was just a decent general purpose compute service. Like, I've got this, this code I want to run. And I want to get a scale. And I want some of the benefits that like the App Services got. But it's not a web app. You know, it's just some background service that is maybe taking messages off the queue, or something you could do with like, the old container services, or Kubernetes, and stuff. But if you just wanted something a bit simpler than that, there was there was a middle ground, I think missing. And we've been trying at the fact that it's got a lot of good support for for things like that data, as well. I always try and avoid saying data in case people think, oh, it's got support for SQL database or something.

Oscar
Not that one. The other one, not did not an RM,

Isaac
exactly, not the micro-RM. But those sorts of things as well. Pretty excited about just because I mean, they seem to be investing a lot into it, they're already starting to take features from the App Service and put it into that as well. And the biggest challenge we always have when we're using like the app services, we've got some process. And normally, you know, you've got an HTTP request. And it's normally you can respond in, you know, sub second synchronously, whatever. But then suddenly, you've got this process that we need to do some background processing, how do we host that component, then? And then you've always got, well, maybe we should just host it in the app service as a separate process. And we'll use web jobs or something to communicate with it. Or maybe we use functions, that functions doesn't work. So well, in my experience, if it's a really long running process, and it's got its own issues as well.

Oscar
So what if you use premium functions, just pay more.

Isaac
Yeah, exactly, exactly. But for us, like, I'm really excited with it, because it just looks like it's, it runs on Docker. So you can run it locally as well, you know, you get that safety net as well. But it just looks like it's going to be like the best place to just run general purpose compute integer, which I think they didn't have a great story up until now.

Rick
Yeah. And I think what you said that it might hit the sweet spot between App Services on one end and AKs on the other, since AKs, brings brings more complexity in trying to manage everything. And with container apps, it's like you said, it's relatively simple way of hosting an application on a container. And it's, it is still different from container instances, I think it's called Yeah. So the Yeah, I agree with you on the fact that this might as well be the sweet spot between all of those different services where they now also have a general-purpose compute tier available.

Oscar
And there's a lot of overlap, of course, because, for me, it was I'm really used to writing things in functions and durable functions, and indeed, long running processes in premium. But for me, for a lot of APIs, I'm using, um, like, App Services a bit to either is centered or like an App Service. Linux is always a bit odd. This seems to be like, first class container, simple hosting, because of indeed AKs. It's super powerful and does what it needs to do. But all the things you need to do in there are every time exactly the same from this, the most of the solutions are building like a couple of APIs and binding some stuff together. And yeah, it has so many knobs and switches to, to work with that. It's really overkill, I think.

Isaac
Yeah, I think the interesting thing is, well, if you compare it to functions, and I know you don't have to use functions in this way, but if you look at all the docs and stuff, particularly on the .NET side, it's all geared around the SDK, you know, the functions SDK and everything. It's almost like you have to learn how to use that just to use functions.

Oscar
Yeah, it's almost it's a framework by itself, at some point became really heavy. Yeah, there's a lot of history in there. You You got into conflicts with of course, JSON .NET different versions

Rick
here, but also with the introduction of .NET five. Next two, we have the isolated one. Yeah, but those are all still Not entirely out there, right? Since only .NET. Seven will have durable functions in the in process.

Oscar
It is, indeed but it's been a really opinionated framework works really well. If you're like, well, we have a lot of workloads, small things kicked off by service bus or whatever. Yeah, really events tell it works pretty well, if you're used to that thing. But sometimes if you want to get a thing done, he's like, I need to use this SDK binding setup. It works perfectly in a demo, but real life, sometimes these are too limited. But yeah, it's good to have another tool that at some point, like, Okay, this is now going too far for this one. Let's move on to the next. And I think this will definitely fill a gap where your, your amount of control over the actual app you're running is almost 100% with also a maximum amount of Don't worry about the infrastructure its running on. Yeah. I do think it's the sweetspot.

Rick
We all agree. So.

Oscar
Oh, nothing to talk about.

The best old Azure service - 41:08

Rick
No, but yeah, that's, that's okay. So that's on the question. What service has maybe surprised you most lately, now listening to you that potentially is also to service you all running? Mostly on? What is the best old service that there is? That's just been there for ages, and it's just that suitable? Suitable go to thing that always just works? Do you have any,

Isaac
I guess the tea classics are going to be stuff like Azure storage, which it just works. And they've made it better over the years, which I like, even things like tables, which are Microsoft seem to be wanting to sort of kill a few years ago. I mean, they were never going to kill it. But it was like, you would look up like Azure tables, and they obviously spent a lot of money on their SEO and you'd get like, sign up for Cosmos dB. You lost your money. And, you know, they've got the sort of the the adapter layer. But like even something like tables, which was like, you know, that was one of the earliest surfaces even. I don't know how far back your as your experience goes. Like, I remember the Silverlight portal. And I think tables were even around then.

Rick
Yeah, I think so. And then, what you said, I think there was actually a turning point a couple of months ago, where we used to have table entities in a separate library, then it went into Cosmos DB as your data table, so they actually pulled it out to make it look like it's agnostic.

Oscar
But last last year, I think we have three iterations on every SDK of Azure. I'm using the old one again, apparently. But it's the newer old one.

Rick
I once I once used a preview version of an SDK. And then I was contacted by the team developing the preview. And they said, we have a preview version of an SDK that actually adheres to how we think an SDK should look. So yeah, I'm already using the Preview. No, we're redefining the preview you're already using redefining it to be a new preview. Okay. Okay.

Oscar
Yeah, but the tables, indeed, the focus became cosmos. Because they moved, they needed to implement the API and like, okay, let's give the SDK then also to that team, but that kind of was a mess, indeed, also, for functions. Becaus+e it has a lot of dependencies built in. And now it needed to drag, drag into another dependency to actually get the new table working.

Rick
And there has been one version of the functions runtime that actually broke if you had storage and Cosmos simultaneously because it didn't know which version of table to choose

Oscar
But I think it's functions one timeframe. But yeah, indeed, like, but the tables is so powerful, I'm almost thinking with, it was too good. And they accidentally priced it too low or something. It's so versatile.

Isaac
You know, it's got its limitations, you know, can't easily index it. And you know that backup story wasn't great at the time. And you know, there's a finite limit on in terms of performance based on the storage account. But if you live within those constraints, and to be fair, you know, a load of time, you just need a tabular store, of here's a load of data, just put it in this stable store. It's so good. You know, it scales naturally as long as you get a decent charting done.

Oscar
Well, that's the thing if you can get your design and you can get really creative with that and get like enormous solution for, for pennies. Working because like I was working on some projects with a colleague is like I think they will Table Storage would be cheaper and more efficient than than SQL. We just asked some redundancy and save things, different ways to be able to read. And the colleague came back like Yeah, but I only have the partition key and the row key to to actually do some things like no, you also have the table name to generate in line. So we have a third dimension and like we build something, and it was really super cheap to host, while the same thing in SQL would require us to have like six tables. And that was a simple solution in the end. But there was so much traffic on it constantly. That would be like, like 1000-fold the cost to be able to host that. Yeah, I'm really a fan also on also agreeing, direct.

Closing - 45:42

Rick
Yeah, again, again. Well, the thing is, I have the feeling that we could talk on for hours, but we are nearing the end of this episode. So Isaac, is there anything that you would like to get back to or that you would like to add or we missed, or that's really important that people know.

Isaac
The only thing I'll plug is the my second book, F# and action, it's just entered me now. So if you don't mind me plugging it, you can get it on Manning. It's only up for a week or two, but it'll probably be finished in the next couple of months.

Rick
We will be sure to add a link in the description to that book, for anyone interested in getting to know how to work with F#. And then with that, I would like to thank you very much for being our guest.

Isaac
Thanks a lot. It's great to be here. Thanks a lot for being such great hosts.

Rick
Thanks

Oscar
Thank you for being

Rick
Thank you for listening to Betatalks the podcast, we publish a new episode every two weeks.

Oscar
You can find us on all the major streaming platforms like Spotify, and iTunes.

Rick
See you next time.

Oscar
Bye.