Currently the examples are buried multiple pages into the documentation, making it harder to evaluate the project at a glance
They have a nice little dropdown in the top corner, right there on the front page, that lets you see little code snippets. I really like that.
Should slightly more accessible code snippets have any influence on my choice of language? Probably not. But I like it nonetheless.
Is love to see a presentation on it.
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?
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.
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.
[0] https://www.beeflang.org/docs/language-guide/datatypes/
[1] https://fsharpforfunandprofit.com/posts/units-of-measure/
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, ?
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.
1: No users: infinite flexibility
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.
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.
Also you reminded me that the Insaniquarium Screensaver was the original cookie clicker.
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 ;).
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
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!
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.
I would suggest adding LSP support as a future todo.
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.
- since you're using LLVM behind the scene, how do you manage to have low compile time ?
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.
Kind of curious about performance benchmarks vs C# and C++. Did you post that somewhere?
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.
I'd be interested in more information about the IDE crash.
Better yet, turn it into something that others can use easily by configuring things like the server to which send the reports.
I did this for SumatraPDF (https://github.com/sumatrapdfreader/sumatrapdf/blob/master/s...) and now I think it's a must for writing desktop software that runs on other people's machines.
A shockingly low number of people report crash reports.
I know because I show a message box telling them to submit a bug report for a crash. I get plenty of crashes but no bug reports.
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.
Please don't call inline functions mixins; that word has an established meaning in OOP.
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.
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)
Your half right about the devils.
Beef however is per definition a cow killed to be eaten.
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/