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/
When making the Inko website I saw a bunch of other language websites (e.g. D's website) use this approach, so I copied the idea. I'm glad it turned out useful :)
I'd like to just add a +1 to this. I had a tough time finding some good code examples and would love to see a small example of code in the readme. Something beyond a hello world, preferably but that's just me
Hey – cool stuff and thank you for taking the time to respond to comments here!
Some questions and feedback:
1. Did you start this project at PopCap and if so, are any of their games developed using a version of Beef? Do you know of any other games developed with Beef? I looked around the site but couldn't find any such information.
2. How would you use Beef with popular game engines like Unity or Unreal? Or is this language mainly intended for engine development as opposed to game logic?
3. Given the focus on developer "ergonomics" if you will, while retaining high performance execution characteristics – are there any representative benchmarking examples where you can showcase both great performance and "nicer" code?
Regarding that last question, a representative example in my mind might be something like a small raytracing engine. Something sufficiently complex that performance matters, but stils simple enough that someone familiar with the domain (and, presumably, a counterexample language like C++) could grok the Beef code and see the benefits in a show-me-don't-tell-me kind of manner. What do you think?
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.
I'm impressed by your C# reimplementation [0]! (Yes, I can tell it is different). Not sure what the aspiration is, but I'd be surprised if you don't have an offer from Microsoft in the next few years (assuming they haven't already tried to buy you out). Unfortunately I can't find any mention of threads/parallelism on your website, which I'm sure are present in the language.
Ps. If you're still looking for worthy features, might I suggest f#'s units of measure [1]? They are enforced by the compiler and stripped at runtime, so they are fairly simple to implement.
Looks nice, unlike pretty much every other language i see posted here and in proggit it has a full tool suite (with IDE, debugger and even profiler) and documentation. It does look like a professional quality product.
EDIT: i think you need to add some information about which systems exactly are supported, especially for Windows where not everyone is running the latest version.
Also what about backwards compatibility? It might be too soon considering a 0.x release but how often does the language break existing code and what are the plans for after 1.0? No break at all no matter the cost, breaks every major version, total breakage regardless of version, ?
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.
May I recommend d's scheme? I personally find it works quite well. Essentially, breaking features are introduced as a 'preview' that you have to opt into with a compiler flag. After a period of some time, it is changed so that the old and new behaviours can co-exist, but a deprecation warning is issued where the old behaviour is found. After some more time, the warning is changed to an error, but with an option flag to change it back to a deprecation. Then, finally, it is removed completely for the compiler.
This makes the maintainers' job a bit harder, but not by a lot, and as a user I find it a nice medium of stability and progress.
I don’t maintain much software with downstream users, but I would expect feature flags like this to make the job also easier for maintainers. It’s a little bit more code, but since you don’t break anything for your users you can take your time and don’t need to rush to push out fixes for new features, since these are opt-in first.
2: "Small" userbase: changes produce grumbling, community adjusts over time, old code is successfully forgotten (deleted + no nostalgia)
3: Very Large™ userbase: even TNT won't change the language
Each of these is relative: (3) has happened with Python (famously explosively), Rust, Go... and also Lua, awk, FORTH. Language size ("volume") seems to have no impact; once a language becomes known for a certain way of doing things beyond a certain scale, trying to go against that (even as the language creator) will land you in a strange, undefined uncanney valley that's not precisely un-idiomatic, but... everyone will still try and steer/corral/etc you back to the "established way".
Obviously (2) represents the perfect ideal here. (Well it wins by default, since (1) is socially depressing :) )
So, one approach could be to try lots of ideas (at a pace that keeps up the creative energy to enjoy the effort) early on.
The key in this case seems to be figuring out the magic threshold point where the community is
- large enough to provide constructive feedback and help the project substantively grow
- small enough to stomach fundamental, relearn-everything-you-learned, changes
- cohesive enough not to be disbanded by the impact of said changes
and carefully ratelimiting publicity and knowledge spread to control ecosystem growth, in a way that does not rein it in.
The dynamics of what defines this balance seem to be specific to each project.
Hey! Just wanted to say thanks for the great PopCap games over the years. I sunk a lot of hours into Insaniquarium, Peggle, etc.
I'm really enjoying this renaissance of "C replacement" languages like Beef, Jai, Zig, Rust, etc. It would be cool to have a table comparing them all, hyperpolyglot-style.
A hint from a "professional": It would help a lot if you'd give a single-paragraph positioning in the field of PLs. In your case at first glance it looks like "first-order (?), monomorphic(?) nominally typed, strictly evaluated, object-oriented (?), ahead-of-time compiled, with a context-free syntax and no (?) macros." As you can see, there are a lot of question marks you could answer ;).
great to see you here! quick question- you wouldn't happen to be BF? One of the first games I played on PC was ARC. Those leagues got me into scripting, which led me to Purdue CS, which led me to my career today.
just wanted to give a shout out to you & JV. you guys had a lot of influence over a generation of ARCers, some of which still play games together. so, thanks, and cool to see this from you. I will check it out and show my engineers
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.
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).
I seem to remember one of the PopCap founders being active on comp.sys.ibm.pc.games, back when Brad Wardell and some of the other later-high-profile designers were in the conversation as well, mid 90s or so IIRC.
Would that have been one of you too? Those were gaming glory days for me, with limited forums for discussion and everyone gravitating to what there was. You got to rub shoulders with some pretty cool people, digitally speaking.
Also, how weird is it that the public net has been around long enough to ask things like if we met on the internet 25 years ago? My mind still reels.
Beyond the excuse to be a useful "dogfood project" of the language, was there any other intentional reason to focus on a custom IDE rather than the Language Server Protocol and multi-IDE support?
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.
An LSP implementation can be fairly useful although if you want to let backend services like sourcegraph code search support your language better. Not to mention other future tooling or doing development with a beefy datacenter machine to have fast compiles or work with large codebases.
I would suggest adding LSP support as a future todo.
I think you should put this in the project readme. I just kind of glossed over the description while reading it before I checked the HN comments, but knowing who you are makes the project more interesting and significant to me.
Sorry this isn't about the language, but I just wanted to tell you that I was born in '97 and during my childhood my mother used to play Bookworm with me every day to teach me reading and spelling.
She also may or may not have had a serious addiction to Bejeweled.
I had forgotten about that for so long, thanks for the childhood memories.
Very cool; I’m looking forward to playing with it. Just wondering - what’s the current state? Is the core language pretty well baked at this point, or is it open to changes?
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.
Since you are working on debug-specific backend, have you considered Cranelift [1]? In case you never heard of it, it was especially intended for fast codegen (because it's being used to compile WASM in Firefox), and Rust wants to be able to use it for their own debug build. If you were aware of it and decided not to use it, I'd love to know what are your rationals.
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.
How do you feel about .NET Core's growing support for AOT, and better manual/stack allocation support with Span<T> in ? If you had to start from scratch would you give native C# another try? What do you think is still missing from the language?
What GUI toolkit is used for the IDE? Is the IDE multi-platform? I tried the Windows application and it had complaints about Visual Studio not being found when building the sample app. What's the dependence on Visual Studio about? Also the IDE died in a unrecoverable way when trying to do a single-step on the first sample application.
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.
Advice from a fellow dev: add a crash handler and set it up for an automatic submission of crash reports (symbolicated callstacks of all threads) via HTTP POST to a server.
Better yet, turn it into something that others can use easily by configuring things like the server to which send the reports.
How much work is it to port the IDE to other platforms?
The IDE is maybe one of the nice/important aspects of this project, but then this really should not be Windows-only. Or maybe that are your priorities, but then I would not expect that it gets much adoption outside of the Windows world, but maybe this is ok for you.
I picked the same and use the menu to build, but I don't have VisualStudio, so perhaps the sample didn't really build. Then I was clicking around the menu and chose the Single-Step option on the menu (F11? F10?) when the IDE crashed.
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.
Do you think Mormons object to coding in Java? Do vegetarians only use bash and zsh because fish is offensive? Do Muslims refuse to deploy snort because their mascot is a pig? Do Christians avoid FreeBSD because of its devil or Unixes as a whole because of daemons?
The only people who will be offended are those who seek to be (and even better: if they're offended on behalf of others which is one of the most patronising behaviours imaginable)
Names are important. For what it's worth, the name 'beef' is peculiar to me. At first I thought it was a joke language like Brainfuck or ArnoldC. Java, fish, snort and cartoon devils are not nearly as culturally charged on many levels as dead cow flesh and all it invokes both good and bad. Where do you draw the line? A programming language called 'Christ'? 'Penis'? 'Dogmeat'? I'm sure you can think of some less obviously taboo. The only people who will be offended are those who seek to be, but that doesn't mean the name doesn't matter.
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/