Managed vs Unmanaged Code - Part 1
Managed vs Unmanaged Code - Part 1
Chronicles of .NET runtime - Part 7
This one was, in all honesty, eating me alive. My plan was to start writing about Memory Management, Stacks and Heaps in .NET, but then I figured it’d probably make sense to open up with a backstory of Managed (and Unmanaged) languages. Should have been a simple one; almost. What I thought would be a night or two job, turned into a week-long journey of trying to unfuddle the shit out of WHAT EXACTLY does Managed vs Unmanaged mean. Well, I think I finally have an answer ready, but before I tell you the answer, I first want to share how I got there. And this article is about that.
If you are a newcomer, this article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t read any of the past articles - I’d recommend you start from the beginning.
I hope you enjoyed the infographic. But I have to disappoint you now - it’s incorrect :) Well, to be more precise - mostly incorrect. Ouch.
Here’s the deal - I used to think that Managed vs Unmanaged refers to the fact whether the language has Garbage Collector or not. Which kind of made sense and I’m sure at least some of you share these same beliefs.
Then I started investigating and looking around and I figured that it actually refers to MORE than the Garbage Collection. It refers to languages that have a “Manager” that takes care of your shit. Oh, did I say “shit”? I meant - resources. Logistics, as some would say. And in a way, it was true. Managed Languages DO have some kind of manager that manages stuff for you.
Next, I started thinking about the proper analogy. Because one thing I love about my bitesized articles is that I always try coming up with a simple analogy that would engrave the concept in your brain. What came to mind was “singers”. They could be “freelancers” and manage all of their gigs on their own, or they could hire a manager to take care of their crap while they focus on their art. And the analogy made sense because you could point blank ask “so, what’s better?” and the answer would be the most disliked answer ever produced - “it depends”. And it really DOES depend. Being a freelance artist gives you a freedom, possibly more money, more control, etc. But it comes with some costs, right? You have to manage way more crap than someone with a dedicated manager. You could really bounce back & forth and I’m sure you could generate tons of pros & cons for both.
The analogy and this whole graphic made a lot of sense. But something didn’t really click. So, C# is managed language, VB.net is managed language, Java is managed language, Python, Ruby and PHP would likely fit under the “managed languages” umbrella as well. On the other hand - C and C++ are unmanaged languages. They give you a full access to memory and whatnot. Well, yeah, just like freelance artists - they allow you to do whatever the heck you want. It all fits. Almost.
Then I started producing some questions that I couldn’t really find a proper answer to - “is Rust a managed language”? “What about Go?”. The answers weren’t really clear to be honest.
I came around a Quora post that claims that “Unmanaged Languages” compile to Native code, whereas Managed ones compile to Bytecode. That makes sense. So that means that Rust and Go are also Unmanaged, right? Almost.
Rust, I guess you could say fits the “Unmanaged” category. It compiles to machine friendly bits, it doesn’t have garbage collection, you are allowed to do whatever the heck you want … it all fits. Perfect. But Go fucked me up :) Go, even though I never really used it, claims that it manages your resources for you. In a way. And it has Garbage Collector. But it also compiles to native code. What the actual fuck? What the fuck are you, Go? Are you Managed or Unmanaged for hell’s sake?
The fact that I couldn’t answer this question really meant one thing - I didn’t have a complete picture of what this all means. And like I said at the beginning - it was eating me alive. What’s more, I just couldn’t proceed with Bitesized Articles before I answered this question. I HAD TO answer this question.
I eventually came to learn that “Managed Code” was a term that was coined by no one else but my current employer - Microsoft :) The earliest reference I could find dates back to April 2003. Yes, that’s 20 years ago! And it was a reference that “explains” the idea behind the term, so I guess the term itself was coined even earlier. I’m guessing that it originated with the whole CLR and CLI thing, but I yet have to check this out.
Managed Code refers to the code that compiles to Common Intermediate Language (CIL), often referred to as Microsoft’s Intermediate Language (MSIL) or just Intermediate Language (IL). And yes, it’s that damn thing that I keep ranting about from the beginning of this series. Managed Code is a code that compiles to Intermediate Language and gets executed by Common Language Runtime (CLR). That’s it. That’s the whole point. Nothing to do with Garbage Collection or whatever. No. It’s all about Common Language Runtime (CLR) and Intermediate Language. And yes, that explains the meaning behind “Managed C++” - it’s C++ that compiles into Intermediate Language and can be executed by CLR.
What this further means is that the graphic from above is barely wrong :) It’s wrong because it missed the point of “Managed”. And that’s why I named this one “part 1”. In “Part 2” I will do the proper honors and explain this exactly as it is.
Until then, if you enjoyed this, you might also want to subscribe :)
I’d also appreciate if you share this with your colleagues:
Thanks a lot for reading!
Other articles from the CLR series: