beefdev

BeefLang will report leaks as they occur, not when the program shuts down. There's a tracing "GC" in debug mode for detecting unreachable memory in realtime. It's also used for reliably detecting use-after-free since memory is held when there are references and released when the last reference goes away -- again, a debug-only feature.

Thanks for the mention, Gene. Thanks for being an early adopter, and keep those bugs and feedback coming in!

As far as performance vs C - there's not a lot of features that incur dynamic dispatch: virtual method calls, dynamic casts (as/is keywords), and direct interface dispatch. When you use interfaces as generic constraints, those monomorph into static dispatches unless the implementing method itself is virtual.

For C-style code, however, the performance should be the same as the C equivalent in Clang. File a bug if it isn't!

To me, an "inlined" method already has a specific meaning -- it's a type of optimization that does not infer a semantic difference to a normal method.

Well, they are not functions and they are not macros. It seemed appropriate to overload the 'mixin' name, but it's not too late to find a better name.

Even if Beef supported class mixins, I would say "there's class mixins and method mixins". D does something similar with template mixins vs a mixin statement that compiles strings as code.

Thanks. Will change to 712.0Mb on next update.

Hah. Yes, actually I did. I wrote a C#-to-C++ transpiler and a VM wrapper with a concurrent GC. This predated Unity's IL2CPP by about 6 months.

Compile times were a big issue, and the little edges of the language and libraries were problematic since they were built around a JIT. Then it struck me that I don't really care about the JIT, and the reason I liked C# had nothing to do with the GC, and it would be much better to just make a slight variation of C# that was statically compiled and without a GC.

I just followed along all the obvious next steps from there, and here we are 5 years later.

1) VSCode was not able to accomplish the development experience I wanted, but I would certainly support a BeefLang language server for VSCode (and other editors/IDEs).

2) Like C, BeefLang idiomatically allows certain types of safe data patterns that the Rust checker would disallow since they cannot be reasonably statically proven to be safe. If you want to conform to Rust patterns then use Rust. If you don't, then BeefLang is another choice for you.

3) Do you mean if the IDE supports C++? It used to support Clang autocompletion and such, but it just wasn't anywhere near the quality of VS Intellisense so I just took it out and I still use VS for C++ editing.

4) Command-line compiler only.

Seems great - I'll copy as many good ideas as I can. The root goals are very similar, but some issues in preference have resulted in very different approaches to meeting those goals.

Thanks for the checking out the language thoroughly, that's appreciated.

With "delete _", you are correct, the "_" refers to "the value in question", which is mRand in that case. When you have a switch statement, the "_" refers to the value being switched over.

The "." type is a special type meaning "the expected type here". So that's explicitly casting to the expected type, since an implicit cast from float to int is not allowed.

And yes, my apologies to Urban Müller for overloading his file extension, but it seemed the chances of that actually being a problem for someone were acceptably low and I really really preferred ".bf".

It's as fast as C, since anything you can express in C can be expressed in BeefLang.

The real question is how fast an idiomatic expression of an identical complex program is in both language. Well, that might not even be the question- it may be more like "if presented with a problem that requires writing a program, what are the characteristics of the solution to that problem if the language chosen is X vs Y". Maybe?

Anyway, I don't think anyone has figured out how to properly compare programming languages yet in that way other than "try it and see if it works better for you than other things you've tried before".

Hm- maybe your experiences are different, but for projects I've worked on, the game state is way too complicated to be usefully inspected and manipulated with a REPL. Especially if you are doing any sort of data-oriented design such as SoA or ECS.

There are quite a lot of other complicated factors such as "what thread does this run on?" and "when?". When you are debugging and hit a breakpoint then you basically have a REPL in the Immediate window...

This is correct - P/Invoke is not required because all interop datatypes can be expressed in BeefLang, whereas C# does not allow certain types of datatypes in structs (IE: pointers to structs, statically sized arrays).

Ah- for BeefLang that's less of a problem since even unreachable code is typechecked (without code generation). But yeah your problem sounds very hard. I guess I don't fully understand why you would only want reachable functions to be listed in documentation...