State of Boo

[systocrat]

My apologies if this is answered somewhere else, as I've definitely missed it.

The master branch for Boo doesn't appear to have been committed to since November 2018.

What development is currently happening for Boo, if any? I'd like to get familiar with and use the language for new projects, but if it isn't actively being maintained I'm worried that eventually it will become 100% obsolete and I'll end up having to rewrite my projects later on.

Additionally, if more hands are needed, where would a new contributor start?

[masonwheeler]

It's mostly a "more hands are needed" issue. No one's heard from Rodrigo or Ivan for a few years now. I'm actively using Boo in various projects, but they're taking up enough of my time that language maintenance ends up on the back burner.

The most important things that need to be done right now, for a new contributor with experience in compiler design and low-level .NET architecture:

• Support for .NET Standard is urgently needed. This means two major architectural-level changes to the compiler:
  • It needs some way to read reference assemblies for system code rather than automatically targeting whatever it's currently running under.
  • It needs a new, supported way to write out assemblies to disc, as Reflection.Emit.Save is not supported by the .NET Core team and they have no plans to support it.
• Visual Studio support is urgently needed. Right now, the biggest blocker is the way Boo loads all referenced assemblies into memory because:
  • Visual Studio language support uses a parser to provide Intellisense and analysis
  • This parser runs in-process
  • Boo loads referenced assemblies into the compiler, which is running inside the Visual Studio process
  • If some of those referenced assemblies are other projects in your Solution, as they frequently are, then those assemblies are loaded into VS's process, and can't be rebuilt without unloading them
  • There is no way to unload a loaded assembly without shutting down the process, or at least the AppDomain
  • There's no obvious, clean boundary in the architecture where the Boo parser could be moved to its own AppDomain
  • Loading referenced assemblies into memory does need to happen, because it's necessary for macro expansion.

This is kind of a "perfect storm" of factors that makes getting VS language support working into a difficult problem. Any help would be welcome.

[HugoP707]

Hello, I am interested in maybe getting into boo rather than ironpython and writing compilers is something I have wanted to learn, so if you could give me some reasons to use boo rather than ironpython (basically because I am not sure yet).
And most importantly, any references to learn to write compilers, (possibly fully developed tutorials, maybe to .net bytecode but I don't care, and possibly in python/ironpython or rather unlikely boo).
I would love to support this language independently of me going to use it or not.

Thank you and I hope the best for boo.

[masonwheeler]

@Albus70007 There are many similarities between Boo and Python. The major differences are:

1. Static typing. Boo is designed to use the .NET type system, which improves correctness and ease of development. It can be put in "ducky" mode if you really want Python's duck typing experience, but by default it's got essentially the same strong typing guarantees as C#.
2. Metaprogramming. With macros, AST attributes and meta methods, Boo is heavily built around the idea of allowing you to extend and customize the language to make it more suitable to the specific problems you're solving. In fact, many things that in other languages are core language features are implemented in Boo as macros, such as using and var.
3. Support. IronPython is officially dead these days, while Boo is only mostly dead. 😛

[HugoP707]

IronPythons last commit was 22 hours ago, Boo's one was 12 moths ago, so i would say Ironpython is maturing while boo dying, wouldnt you?

[masonwheeler]

Wow, really? I was not aware that IronPython development was ongoing. TIL.

[HugoP707]

What version of .NET does booc compile to?

[masonwheeler]

Whatever version of the framework it's currently running under. That's a limitation of Reflection.Emit that it would be nice to work around at some future point.

[HugoP707]

How could i change that?
And btw, are there floats in boo, because i dont find them.

[masonwheeler]

The standard float types single and double are supported. C# has a type keyword float; Boo doesn't, but float is just an alias for single anyway.

As for fixing the compiler, we would need to replace EmitAssembly with an alternative implementation that's not based on Reflection.Emit. Probably the best candidate right now is Reflection.Metadata.

I tried to do something similar a few years back, replacing the EmitAssembly step with a CCI-based emitter, but then CCI got deprecated and un-supported and I could never get debug info generation to work, so I ended up abandoning that. You can still find the branch here for reference purposes, if you're interested.

[HugoP707]

men, using boo is as hard as just developing something great with it, anyway, i saw some other issues, are you (since you are basically the only one that uses boo except me) going to try the boo to c# transpiler as a replacement to the current compiler or you are sticking to the actual one

[masonwheeler]

I'm sticking with the current one. I'm just a bit busy at the moment and haven't had time to work on improving the compiler lately.

[HugoP707]

ok, but i might try to do it myself, just to see how it goes and distract myself

[masonwheeler]

All right. Do you have any previous compiler experience? (If not, diving head-first into something like this is a great way to learn in a hurry!)

Probably the best bet is to make a copy of EmitAssembly.cs, remove the using System.Reflection.Emit line, replace it with whatever the applicable namespace is from System.Reflection.Metadata, and replace things with as close of exact equivalents as you can find. That way, you keep the structure and the domain knowledge of the existing writing code, which is in a known-good state.

Once you get everything to compile, you'll be about 60% of the way there. Then you have to make sure all the compiler tests pass, which will help you track down the subtle bugs. During this phase, ildasm and peverify will become your best friends in the world, with JetBrains DotPeek (or similar) coming in a very close second, if you have it.

[RealDoigt]

Is there an equivalent of the Lock keyword for Boo?