beefdev

It's very open to changes - this is just the initial public release. I'm looking forward to great ideas from the community.

Console support important. That being said, there's a question of what console support means. For a programming language, that generally just means the compiler needs to be capable of generating binaries for the given target processor. The issue of how to interact with the hardware itself and how to participate in the toolchain provided by the console vendor is much more difficult and is outside the scope of the language/compiler.

The ideal case is for an engine such to embrace Beef and work through those issues.

Chucklefish was an early(ish) adopter of Rust and tried to maintain an XBox/PS4/Switch toolchain but eventually abandoned it. Rust is probably a good example of a popular "alternative language" that may pave the way for BeefLang and others to work their way into those spaces.

Thanks- A Cargo-like system is the long-term trajectory the language is on now.

Let's just pretend it was a pun.

Yes, this is right - there is what is essentially a fully-functional "garbage collector" but its only job is to detect leaks in debug builds. Well, it also is used for detecting illegal memory layout changes during hot code changes...

One may say "then why not just make the GC optional like D", but when you design a library you really need to either design it for a GC or for manual memory management. Even for the basic string type - if Beef was a GC'd language then String would be immutable, but it's not so String is mutable. Totally different designs.

Great question - I've thought a lot about backward compatibility but I don't have a good answer yet. The whole Python 2 vs 3 nightmare has given me a couple sleepless nights though.

There's a split between class and struct. Classes are reference types and have more 'features', and structs are a lot like C structs - you have complete control over their layout and allocation.

There's future plans to add more high-perf sugars like automating some SoA and AoSoA layouts, but you can do all that manually right now.

There are some optional memory safeties, including real-time leak detection, but this language targets an audience who value performance over total memory safety.

For someone looking for a C replacement where memory safety is absolutely critical (ie- open server applications) then Rust may be a better fit.

Performance-oriented implies a type of tradeoff made during design decisions - that tradeoff also means the language is weaker is certain ways than languages such as Javascript, Python, Ruby, etc.

Generally that would mean: - More static, less dynamic - No GC - Lighter abstractions - More directly conforms to hardware (even when it create a 'less clean' interface)

Author here. I'm the engineering co-founder of PopCap Games. I left PopCap after the EA acquisition, and I've been working on this project mostly full-time for the last five years.

Before Beef, I was developing game code in C# and engine code in C++ and I felt C# was just much more pleasant to work with - faster compile times, better IDE tooling, better errors, etc. Then it struck me that none of the things I liked about C# really had anything to do with the JIT or the GC, and it may be possible to create a "best of" merging between C# and C++.

I know there are other "C replacement" contenders out there - the differences are probably best explained through Beef's specific design goals listed at https://www.beeflang.org/docs/foreward/