State of Boo about boo

[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.

[TheWitheredStriker]

Are there any further updates on the state of Boo? As much as I would love to help, I am simply not good enough at coding yet to make any meaningful contributions, especially due to my current lack of expertise regarding compilers. That being said, I would love to spread the word of Boo, so that perhaps the right people may be found.

Have any of @masonwheeler's suggestions been implemented yet? And is anyone actively using the language? I would love for Boo to see a resurgency of sorts. It doesn't need to be anywhere near mainstream; as long as it's not ... well, this.

Once I've grasped the fundamentals of coding and am ready to dive into compiler study, I'll be more than happy to stop by and help out with the language. Until then, I fear I will not be of much help, but I will continue to stick around for any potential updates as well as see if I can find people in my network who might be interested in giving this a look. To whoever is currently using Boo or working on the language, good luck!

[RealDoigt]

yeah the real boolang group has 700+ members. I tried to join under another account and failed. It seems it really is blocked off right now. I've brought it up in the google group to discuss what we should do. In the meantime, I offer people with discord to add me and send me their email address through dm so I can forward the emails to them (because google groups are just mass emails). Edit: Join the discord group instead. Link in my comment below.

[RealDoigt]

Ok so to anyone from the future who sees this, I'm making a new community space for Boo on discord. Join us at https://discord.gg/VG8EYrvZrW

[Ai-N3rd]

Any updates in the current state of the language?

[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?

[masonwheeler]

The lock macro is in Boo.Lang.Extensions, which gets imported into every project. You should be able to use it exactly like you'd expect.

lock myObject:
   do stuff inside the lock

[RealDoigt]

Thank you! I was about to give up; documentation on Boo is very hard to find.

[Guevara-chan]

Well... You want my personal opinion ? We should simply make .NET backend for Nim language and merge projects already.

Seriously, it's the only way out for Boo.

[RealDoigt]

Nim does a completely different thing and has a very alien syntax compared to Boo.

[RealDoigt]

@TheWitheredStriker I suggest you join the Boo google group as there's some activity there from time to time. Recent repos in Boo include my ConsolePaint library, an implementation of my SSON project as well as Rabios' Raylib bindings for Boo.

[TheWitheredStriker]

Awesome! I'll gladly do so.

[TheWitheredStriker]

Can you give me a link to said google group? I can't find it.

[masonwheeler]

https://groups.google.com/g/boolang

[TheWitheredStriker]

Oh yeah, I did find that group, but I can't access it.

Bold text translates to "Content unavailable"

[RealDoigt]

It's normal, there should be an option somewhere to join the group. The content will become available once you've joined.

[RealDoigt]

https://support.google.com/groups/answer/1067205?hl=en

[TheWitheredStriker]

There is no such option.

Attempts to search for the group instead, fail:

Are you sure the group isn't private?

[RealDoigt]

I think you can join from that second screenshot and no the group isn't closed.

[RealDoigt]

it's the arrow button next to the star

[RealDoigt]

But of course you have to join the correct group.

[iliakonnov]

I believe that boo-language group (which also contains only a few members) have nothing to do with the boolang group mentioned earlier in this issue. I had no luck finding boolang using the search.

[TheWitheredStriker]

Alrighty, noted. I'll add you on Discord after work.

[RealDoigt]

You need to join the community discord and look at the pins

[Ai-N3rd]

@RealDoigt Thanks