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!

Yes- the Windows installer actually does this -- the UI is a BeefLang DLL that is extracted and dynamically loaded. Source code for that part is at https://github.com/beefytech/Beef_website/tree/master/BeefTo...

Also, to be clear- the custom GUI library that the IDE uses is NOT a general-purpose GUI library; it is a support library for the IDE and other BeefLang tools. A true general-purpose GUI would be quite a lot more flexible and also much more complicated... which is not something that is intended for this particular GUI library.

This is mentioned on https://www.beeflang.org/docs/corlib/ but should perhaps be more predominantly stated.

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

I was speaking more about when you have to conform to Nintendo's Switch build system (whatever that looks like - NDA) and you can't control much of that.

If you do have more control then you're in a much better situation, but crossing language boundaries can still be tricky.

Generally you end up having to write "wrapper" code to make those language boundaries palatable. There are code generators like SWIG to handle those things, and some languages like Zig handle importing of c headers, but if the C++ library your trying to use is returning a std::shared_ptr then that's not going to be a very pleasant construct for you to attempt to work with in any language besides C++.

If you can split your code sections into simple and clean C-like interfaces then the job becomes much, much easier.

Hadn't heard of it yet, will check it out.

Coopetition for sure.

Hi Andrew- of course I've been following Zig. Thanks for your trailblazing efforts in the "C replacement" space.

It's true that symbols in 'false' preprocessor blocks will not be caught. Maybe it's best said "if the compiler will find the symbol when you compile, then the symbol renamer will find it when you rename". Which is definitely not true for most symbol renames I dare to attempt in C++ IDEs.

A LSP didn't give me enough control over the IDE environment to create the development experience I wanted. I was also very interested in building a very good hot code swapping environment and that's not possible with a generic IDE/LSP.

I'm a co-founder of PopCap Games. Sold to EA in 2011.

There are nullables (like C# nullables), same syntax: "int? a = null;". There's also algebraic data types like Swift's enum. Quite a lot like Swift's enum, actually. See bottom example in enum section: https://www.beeflang.org/docs/language-guide/datatypes/#enum...

The most obvious choice would be async/await support - no specific plans yet, though.

The concurrency model is, like C++ or even C#: sequential consistency for data-race-free programs (SC-DRF). No green threads or anything crazy, no 'message passing', just normal system threads, normal locks, you control how you access memory yourself. You do synchronization just like you'd do in C/C++.

That would have been Jason Kapalka - he was a video game reviewer before becoming a game designer.

The GUI is custom. The IDE is Windows-only at the moment, but there's also a command-line compiler for other platforms. VS is required for linking (even when using the LLVM linker).

I'd be interested in more information about the IDE crash.

Search for "attack retrieve capture". It's a multiplayer game from 1997 that I made with a friend in college. That friend and I co-founded of PopCap Games with another game designer we met during the development of ARC (actually, our "producer" on the game when we licensed it to TEN.net).

Good question. For one, there's also a custom optimized-debug backend that's used by default for Debug builds which is a lot faster than LLVM. Secondly, there's incremental compilation with an object cache so minor changes only general minor rebuilds.

For a clean release build, however, LLVM will dominate the compile time as expected. Compared to C/C++, however, there is less duplication of ODR'd code (ie- methods defined in headers such as template methods) and less debug information duplication so backend time is lower.

There's a lot of overlap ideologically. One major difference is that I'm an IDE fan and Jonathan dislikes IDEs. That can really percolate through a language.

BeefLang had an IDE on day one, and I think it'll show. One of my goals was to show how good a good IDE experience can actually be to someone who is used to working in C/C++.

Wow. That's amazing- yes, I am BF from ARC. I haven't heard from an ARC player in some time -- maybe ARC inspiring you to get that Purdue CS degree counteracts me and JV dropping out of Purdue.

JV just texted me the other day to pitch ARC VR actually. He went the VR route, founding Pluto VR after PopCap.

Anyway- let me know what you think of BeefLang!

1) I started this project a few years after leaving PopCap. This is the very first public release - only a couple people have seen it before now so there hasn't been a chance for anyone else to build anything with it yet.

2) This is intended for both engine development and game logic. Using alternate languages with Unreal or Unity is nearly impossible at the moment- likely Rust will make inroads there before BeefLang.

3) Good idea.