Rob Ashton
Software Developer
Glasgow, United Kingdom
Actions
Rob is an ex-enterprise .NET consultant and has the scars to show for it - however for the last decade he has been working with a small (distributed) remote team as a full time Erlang+Purescript+Rust developer in the media streaming industry.
Primarily residing in Glasgow and trying to resist the temptation to live on a diet of deep fried mars bars and whisky, he has tried on several hats outside of programming, entering barista competitions (where he tried to set the judges hair on fire), playing miserable country music at festivals (nobody got hurt - physically) and baking sourdough breads and pastries (gained 15kg over lockdown).
Now he's back to talk all things FP, surely nothing can go wrong.
Links
Area of Expertise
Topics
Erlang.NET - Mixing Visual Basic With Pleasure
Over lockdown I had a bit of a revelation - it was a month until April and .NET Core was being spoken about quite a lot on Twitter, in particular the ability to host it anyhere you could write a bit of C.
Erlang can talk to C code, .NET can talk to C code? Surely some bad things could be possible? I enlisted the help of a friend and set about writing a bridge that would allow a .NET developer to write code against the Erlang back-end in their .NET language of choice (mine being Visual Basic).
It worked! Some of the hacks were glorious, shipping anything using it to production would be grossly irresponsible but it worked!
In this session we'll go over exactly what is needed to host .NET core inside a native application, what the rules of communication with that .NET code are exactly and at the same time we'll look at some of the games we had to play to get this to play well inside the Erlang VM because some of them were so bad they were impressive and it's time they got shared with the world.
Can your language do this?
For the last few years we have been doing all of our commercial work in Purescript on both the back-end and the front-end.
Explaining exactly *why* we choose to work with this language is a hard proposition, nobody really wants to hear about functional programming except people who already do functional programming and there isn't much point in talking to people that do functional programming because all they want to do is talk about functional programming.
So, in this session we're going to skip any pretence at giving an "intro" and just dive right into all the really cool things that Purescript can do that C# (and even F#) cannot - it is as simple as that. Every feature that will be demonstrated will be something that we lean on heavily in production software with an emphasis on how cool those things are and what their equivalents in a language like C# would be if you wanted to replicate them.
There will be some simple code examples that everybody can understand and then there will be some code examples that ... aren't so simple but demonstrate how the developer can gain so much compile-time power in modern languages that it should possibly be illegal.
Can your language do these things? No, it probably cannot - but knowing what features are out there can shed valuable perspective on your own platform and that will be the takeaway for this talk.
Zero Support In Production
For the last several years, I have been working in a very small team, both building and deploying/supporting bespoke products that power upwards of half a million live video events a year, as well as forming the backbone of various television services across the UK. For some of our customers, it has been half a decade since we received a support call and indeed it is a virtual non-happening that anybody has to get out of bed to solve a problem in production. A lot of this results directly from our use of Erlang+OTP, and there are then wider patterns that have arisen across our code-bases and even the manner in which we provide support to our clients.
In this session, we will be using examples from our real-world projects to demonstrate how we build, deploy, and then support hundreds of services and hundreds of thousand of events a year in across both the cloud and our on-premise as well as also covering how our software stack ensures that on a bad day, our services carry on delivering content even when servers are catching fire or somebody has spilled coffee on the datacentre power supply.
Relevant subjects covered in this talk: Docker, Erlang, Etcd, Elm, high density computing, Microservices, devops
PURESCRIPT ON THE BEAM; TYPED OTP FOR GREATNESS
After nearly a decade of writing our software in Erlang, our codebases have started getting unwieldy despite our best efforts to manage this through other disciplinary methods. (That and dialyzer, but there are limits!)
So we did what any sensible company would do, and hired "the Purerl guy" and set about working out how we could use the Purescript to Erlang compiler he'd written to help us with this. To that end since, we have already shipped two products and quietly open sourced a selection of the libraries we have built on top of Purerl to support those endeavours.
In this session we'll start by looking at the super happy path (our ideal world) for end-to-end Purescript before going into detail on how some of it is implemented, the weak spots and pitfalls currently present and some of the huge hacks that are possible when using Purescript FFI to bind against "native Erlang" libraries.
Safe Language, Reliable Runtime - Purescript on the Erlang VM
Erlang is an ancient language sitting on top of a very well engineered and battle-tested platform for building distributed systems.
It lacks type safety, it lacks sugar, it lacks freshness and can be impenetrable to newcomers - and yet we've spent the last half decade happily writing successful enterprise products with it despite the language's shortcomings.
As a consequence of this length of time however, the shortcomings of the language have started becoming clear as the size of our code-base starts to make it hard to safely introduce change - we need types, we need explicit side effects and we need those things now!
Enter Purescript - a language primarily used for compiling to Javascript, but now with an Erlang backend! Monads! Effects! Maybe?! Either, Typeclasses oh my.
How do these two worlds even interoperate, how far are we from being able to build whole applications in Purescript on the Erlang VM? Find out in this talk - a new age of reliable engineering is upon us.
Functional UIs with Purescript + Halogen
Curious about Purescript but don't know where to even start? Been to other functional programming talks but been put off by talk of monads, monoids, typeclass hierarchies and category theory? Not in this session! We will be explicitly avoiding the noise and going right into demonstrating what buttons to press to make things happen - there's always time to go reading later!
Rewind! It has been several years since our company ceased all greenfield JavaScript development and therefore said goodbye to "undefined is not a function" forever - first starting with our forays into Elm and then progressing on to Purescript as our confidence grew and we wanted a bit more power over how our UIs were constructed.
We have been impressed with what we have found, especially with how easy some of the libraries have made the act of safely transforming data into UI and have ended up settling into the world of Halogen as we crank out largely defect-free applications and enabled us to avoid ever having to look at our client's Jira installations..
In this session we will be introducing Purescript the language as well as the basic tooling used to support development with it before going on to show explore the use of Halogen and Aff to display data and send back commands from and to a legacy .NET application - keeping it practical and easy, you'll never want to write a line of JavaScript again.
Erlang for .NET developers
Erlang can seem a bit impenetrable at first glance, especially if you are just starting off in the world of functional programming. Not only is the language seemingly esoteric, but the libraries and build tools available can feel somewhat overwhelming when all you want to do is build a 'hello world' app. Well - if you've ever looked at Erlang from a distance and wondered what the fuss is all about, this talk is for you.
We will cover the absolute foundations of getting an application started and how the various aspects of that fit together, as well as real world topics such as package management and how the release toolchains work so that anybody attending this session would be able to leave and apply this knowledge straight away a the office - best of all, we'll cover the material from a .NET standpoint and talk about these concepts in relation to their counterparts in the .NET ecosystem; this is a down to earth and practical session without heaps of functional prior knowledge being required.
OpenTelemetry 101
OpenTelemetry is *the* new (and hot) way to observe your applications in production - both language and platform agnostic, this exciting specification offers the promise of being able to easily observe what your services and dependencies are doing and how they are interacting with each other over time.
Being able to embed instrumentation code in third party libraries without tying the user of those libraries to one particular implementation is game-changing as it means it will soon become the norm to build libraries with observability built-in as a first-class citizen. On top of this, Otel provides a common language/framework to integrate with specific implementations such as Nagios, Splunk, Prometheus, Zipkin without having to then write code specific to those systems.
In this 101 session we are going to jump right in to explaining the basic concepts and tools available within this ecosystem (both tracing and metrics) why you'd even want such a thing to exist and how to get started with it in your platform(s) of choice.
We will witness the use of OpenTelemetry when tracing requests through a distributed system comprised of microservices from initial web request down to database access and demonstrate how it is possible to write code to instrument *everything* whilst deferring decisions about how this data is actually used in production.
This is going to be *the* way to bake observability into systems going forwards - get involved!
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top