Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State of Boo #201

Open
systocrat opened this issue Oct 2, 2019 · 37 comments
Open

State of Boo #201

systocrat opened this issue Oct 2, 2019 · 37 comments

Comments

@systocrat
Copy link

systocrat commented Oct 2, 2019

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
Copy link
Contributor

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
Copy link

HugoP707 commented Nov 3, 2019

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
Copy link
Contributor

@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
Copy link

HugoP707 commented Nov 3, 2019

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
Copy link
Contributor

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

@HugoP707
Copy link

What version of .NET does booc compile to?

@masonwheeler
Copy link
Contributor

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
Copy link

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

@masonwheeler
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

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

@masonwheeler
Copy link
Contributor

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
Copy link

Is there an equivalent of the Lock keyword for Boo?

@masonwheeler
Copy link
Contributor

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
Copy link

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

@Guevara-chan
Copy link

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
Copy link

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

@TheWitheredStriker
Copy link

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
Copy link

@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
Copy link

Awesome! I'll gladly do so.

@TheWitheredStriker
Copy link

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

@masonwheeler
Copy link
Contributor

@TheWitheredStriker
Copy link

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

image
Bold text translates to "Content unavailable"

@RealDoigt
Copy link

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

@RealDoigt
Copy link

@TheWitheredStriker
Copy link

There is no such option.

Attempts to search for the group instead, fail:

image
image

Are you sure the group isn't private?

@RealDoigt
Copy link

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

@RealDoigt
Copy link

it's the arrow button next to the star

@RealDoigt
Copy link

RealDoigt commented Mar 30, 2022

image
But of course you have to join the correct group.

@iliakonnov
Copy link

iliakonnov commented Mar 30, 2022

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.

@RealDoigt
Copy link

RealDoigt commented Mar 31, 2022

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.

@TheWitheredStriker
Copy link

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

@RealDoigt
Copy link

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
Copy link

Ai-N3rd commented Mar 22, 2024

Any updates in the current state of the language?

@RealDoigt
Copy link

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

@Ai-N3rd
Copy link

Ai-N3rd commented Mar 23, 2024

@RealDoigt Thanks

@tigercoding56 tigercoding56 mentioned this issue Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants