Yup. And not necessarily a new Lisp - Common Lisp, with SBCL implementation, is plenty fast enough. It's just the library and tooling ecosystem that's lacking.
I've been learning and using Julia the last few weeks (coming from an OOP background). I highly recommend it. I mainly write highly mathematical programs and utilities to process some data or another. So far I've knocked out some smaller programs and started translating a larger library to learn about the type system. I haven't dug in to UI bindings yet.
Why? SBCL implementation of Common Lisp is very usable for performance-oriented tasks; it compiles to native code, and with sufficient nudges, you can get pretty tight assembly out of it.
Clasp implementation of CL would be another choice, it leverages LLVM for compilation.
The problem is with the library and tooling ecosystem.
If you're going to do SIMD, you have to care about memory alignment. If you're going to do high-performance without SIMD, you still wind up caring about things like cache misses. So you'd want a Lisp that 1) lets you control memory alignment, and probably 2) that doesn't garbage collect. At that point, is it really a Lisp?
Now, you may say that "performance-oriented" doesn't have to go as far as SIMD or caching tweaks. And that's true. But if you want a performance-oriented language that can reach all the way up the performance curve, I don't see it being Lisp.
Depends on which parts of Lisp you're interested in. You can go as far as writing Lispy assembly (SBCL does), which gives you control over memory and is not garbage collected.
As someone desiring a performance-oriented Lisp, this is something I'd like. At runtime, I can handle memory myself ($deity knows I often do that when writing performant code). What I want to have is the friendly, homoiconic Lispy syntax, the ability (and the ease) to write code that writes code, and perhaps to have these facilities available at runtime.
Also, memory alignment isn't an entirely foreign concept to Lisp, it just rarely has been a focus. The long living irony that the etymology of the names of very common Lisp functions `car` and `cdr` themselves are a lingering artifact of 36-bit word memory alignment on an ancient IBM system architecture.
My experience with Clojure was that you spend a lot of time looking at Java-level exceptions. It doesn't really hide the Java dependencies. It's an OK lisp if you want to combine it with Java, but if you don't... not so good.
It looks like the author of this language is using it for game development. What features does Beef provide that other languages don't from a performance perspective? It looks like it has a class & object style. Does it give you tools to control memory layout of those allocations for performance? I know some game devs have commented that the reason C++ classes aren't used in their entity system is memory locality & latency issues.
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.
You should probably do some perf analysis to show how Beef performs vs C / C++ for game related tasks.
Also it would be awesome for you to make a few code samples / tutorials on how to get started with game development with Beef. I'm sure it would attract a lot of people to your language if you show some "proof" it is a nice language for gamedev!
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)
I'm guessing they were asking for some _specific_ features/techniques of Beef that contribute to achieving your design goal. The design goal itself is made very clear.
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/
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.
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
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 :)
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.
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?
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.
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.
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.
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.
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.
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 ;).
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.
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.
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.
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'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.
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?
Couldn't see any other comments about it, but close to a third of Indians are vegetarian not to mention all of us who don't partake in meat for various reasons (ethical, environmental, health etc). Unless the goal was to appeal to the anti-PC crowd, perhaps a more welcoming name?
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.
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.
- avoid custom installer like this, while it looks cool, it kinda give an "amateurish" look
- avoid custom IDEs, i'd rather see a CLion/VS plugin; you just waste your time creating something people don't want to use, they want to use their favorite editor
- allow top level functions, so i don't have to create a freaking class to have a main()
- let me do:
// Press F5 to compile and run program
using System;
namespace HelloWorld
{
class Program
{
// look how it is nicely aligned
let myint: int = 4;
let myfloat: float= 4.5f;
let test: MyType;
static void Main()
{
writeLine("Hello, world!");
}
}
}
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.
It's better to manually hoist the bound checks so that they happen before any critical loop. The compiler often can't do this because it has to preserve the partial effects of where the failed bounds check happens, but that's generally not what you really want; if anything, you'd rather fail fast.
Linear types (and affine types, as in Rust) only buy you some memory safety (preventing use-after-frees, and memory leaks although that's not really a safety issue).
The more important part of memory safety is preventing out-of-bounds accesses. Rust, Ada, and (it seems) Beef sacrifice performance for memory safety here by having runtime bounds checking. (Though there is not much performance cost to this and all of those have options to turn off runtime bounds checking anyway.)
The only performance-oriented language I'm aware of that is fully memory-safe at compile time is ATS‚ via a combination of linear types and dependent types, and using ATS is… cumbersome.
leaks aren't unsafe though. Things like bounds checking and aliasing guarantees are like 90% of the memory safety issues you care about, and those can be performant.
> Leaks can be detected in realtime with the debug memory manager. Reachable memory will be continuously traced at runtime and memory which is no longer reachable but has not been properly freed will be immediately reported as a leak...
Sounds like it doesn't have a Garbage Collector, but a "Garbage Detector" that's only active for debug builds?
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.
All these 4 points are valid and did help golang but I think what took golang to the moon was:
- the immense success of docker based on it which made everyone build their devops tools in go (kubernetes helped too later)
- a very solid and stable http library included in stdlib (plus other networking goodies to easily run your own ssh endpoint in a few lines of code)
tl;dr to get your language some traction, make it solve at least one problem much better than the competition and have someone build a super popular open source project on it.
I think also out of the box standard library features. You can make production ready web apps. Also their initial approach to getting / sharing packages imho is useful.
So a decent package manager would do wonders. Rust has Cargo which does builds and packages. D has dub as well.
Definitely recommend making code sharing / reuse a breeze.
Thank you for working on this awesome project. One additional commentary I always make is that I wish Go and Rust had even a basic editor like the one Racket has: you can edit, and compile. You beat me to that suggestion so I'll keep an eye on your project.
Is there any possibility that you'll include some efforts towards doing back-end networking with this language as well? I could see multiplayer games needing servers after all.
Awesome, I love seeing new languages (and I hope to share mine in good time). I didn't see it, but a good tutorial introducing new ideas would be good.
The code might be brilliant but the biggest obstacle to adoption is probably the name and the logo.
All I can think is "beef begins to smell after a couple of weeks" and it's hard to overlook that mental imagery when evaluating the vast array of good options in the programming language space.
It may also be considered culturally insensitive to a noticeable percentage of software engineers, which could hurt the adoption rate.
> If the author does not consider it culturally insensitive, then there is no problem.
The author can do what he wants, but if he wants adoption, then it would behoove him to consider cultural sensitivity, especially if it is offensive to enough people to stifle adoption.
I would say that paragraph 2 is completely wrong. Why would you want to filter out people who are culturally sensitive from your community? Because you don't want to have to consider alternate viewpoints?
It would behoove the above poster to consider cultural sensitivity in selecting to use the word 'behoove', which contains 'hoove', which is a delicacy from cows in some cultures, as well.
And can I choose my own culture? Like say "this is what I endorse and believe in" and that be my culture? Or does this only apply to policically registered "-ism" classes (race, religion etc)?
If so, I belong to the culture that considers it insensitive to shit on things for light-hearted naming themes as if they are of any relevance next to a million other adoption metrics that are more objective, assuming the author even cares to weigh adoption vs creative license in the first place.
No one needs to "flip their shit" in order for it to be a bad name. I just don't like the sound of the word, for example, and that unpleasant feeling ends up tainting my opinion of the product.
If yes, then either you didn't care much in the first place, or you are indeed, flipping your shit.
And no one said it was a bad name, but that it could be considered culturally insensitive - two ambiguities away from actuallybeing the thing it mightconsidered to be.
It's a bit more than that. I'm a vegetarian, so obviously I have a bias, but I think it's objectively true that the beef industry in America is in a pretty bad place. I consider it "horrific", personally, though reasonable people disagree.
Would "veal" be an acceptable name?
When I think of eating beef in 2020, I think of a person whose freedom to eat whatever pleases them is more important than human health, suffering of intelligent animals and the environment.
Allow me a bad analogy. If I interviewed someone for a senior engineering role but they went out of their way to mention that they had named one of their children "Stalin" -- that would be kind of a red flag for me.
So to me, naming your pet project "Beef" is kind-of tone deaf at best.
And at worst, it's thumbing your nose at political correctness: "Haha I named my project Beef because beef is great and fine and if you disagree you're thin-skinned and blindly following the crowd."
I think the issue is a lot more complicated than that.
I'm Vegan and the name doesn't bother me at all to be honest. I do not agree with the downvoting of parent though, as his reasoning is er.. reasonable.
Is it? Was the question about how acceptable would "veal" be as a name implying that it would not be acceptable at all? What about “lamb”? Or “pork”? (PORK is the long-awaited Well-Done BEEF, according to https://www.cs.cmu.edu/afs/cs/project/ozone/www/object-syste...)
Just append " lang" when you Google it. And I'm pretty sure religious food prohibitions don't generally extend to using software that happens to share a name with the prohibited food.
This complaint makes the top 3 comments on every post about a new programming language. It's tiresome.
Emphasis on notable percentage. That percentage is likely so small that it is easily enough to ignore. It is also not close enough to a "protected class" under USA law (and I assume many other countries too), that is totally fine in the legal sense to ignore those people for the purpose of programming language awareness.
I'm a huge fan of C#, so this really caught my attention!
But I also have to say that the name logo are... offputting. I don't know why exactly; I'm not a vegetarian or religious or anything like that, and the name doesn't bring anything negative in particular to mind (hell, I love eating beef!), but it just feels... wrong somehow.
I am a carnivore, but the name rings pretty well for me. Beef is a simple food: it's not fancy and it doesn't need to be dressed up to be enjoyed. It's also enjoyable on a visceral level, and can hurt you if you're not careful with it. If this language lives up to promise it seems like it fits.
Not sure where you live, but in Europe beef is expensive, certainly "simple food" is not the first thing that springs to mind! I'm sure I've read somewhere it's one of the more expensive meats to produce, per kg, especially compared to chicken and pigs.
Is there planned console support? I assume that's the hardest group of platforms for any engine to target, and is part of why Unity and Unreal have such a stranglehold on the market.
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.
Fellow dev here, I think you're wrong on this part:
> 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.
I've been looking for a language that would allow gradual transition from C++ for example. If you have a C++ SDK, you could still write your whole engine or just some modules in Beef.
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.
A deep ethical concern for the treatment of animals is far older than computing: http://www.jewfaq.org/animals.htm . The cow is sacred to hindus, of which there are 1.08 billion.
stop assuming the problem is with people who care deeply about something and not people who tell them to shut up in public.
You are almost certainly not eating animals to survive, you are doing it because you think it's normal and are either not aware that there is another way, or have chosen to ignore it. It is absolutely unnecessary for most people in first world countries to consume meat, there are easy to access alternatives that are better for the environment, animals, and quite possibly your health.
If you look at the screenshots it is clearly referencing dead animal flesh with the IDE icons.
"Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents."
It is valid criticism of the name, even if you and others don't personally agree, please remember that. We all know that the naming of a product can have an effect.
If you find any proven cases where a vegan was inspired to start eating meat because of this name, I look forward to seeing your investigatory blog post.
All kidding aside, even if you are against the idea of being a carnivore, the name of a programming language does not promote such a thing.
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++.
> 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++.
I wonder what you find lacking in the current C++ experience. e.g. with the IDE I use (QtCreator), I can quickly refactor things across million-lines codebases, perform a decent set of more advanced refactors (https://doc.qt.io/qtcreator/creator-editor-refactoring.html), auto-generate boilerplate code, I get in-line hints, lints and warnings while I type all with clang-based auto-completion...
personally I think the best IDE in the world is Visual Studio for C#.
I think Rust has the _potential_ to be better, but it's years off and requires the rust community to change how they think.
I'm interested in the IDE due to the authors claims, but I don't really see him making this IDE better than VS + C#. If he can, that would be amazing though.
> I think Rust has the _potential_ to be better, but it's years off and requires the rust community to change how they think.
The said change already happened and Rust devs are currently refactoring in depth their compiler to make it IDE-friendly (taking a lot of inspiration from Roslyn). This is tons of work though and even if it's currently going well, it won't be there before next year.
I haven't reviewed your language, but from a fellow software engineer, congrats on your work! It takes a lot of grit to make a programming language. I hope to make one as well one day. If you blog about your experiences about the non-technical challenges, I would definitely read it.
Does it have interactive features? Like messing with game state in a REPL while the game's running? The IDE looks really nice... made me wonder if it had something interactive as well.
Not OP, but I can definitely +1 this idea. It's a sorely missed component that must be thought through and implemented/specialized for literally every project (done in C/C++/etc anyway).
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...
I love the concept of this language! Even though a lot of attempts have been made, I think no one has really filled the "more ergonomic C" slot yet, and I would be happy if this manages.
I am sorry to see semicolons though. I have never missed semicolons after moving to languages where they're not required, and it's always a bummer going in the opposite direction.
What's the concurrency model and what thread/coroutine support is available or planned? I see some supporting classes in the System.Threading namespace.
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++.
If you go the route of async/await support - I went through the arduous process of figuring this out for zig (for which I think our design goals are nearly identical), and went through a couple different iterations. I have experience with using LLVM's coroutines API and abandoning it to codegen them manually. Would be happy to have a brainstorming chat with you sometime if you're interested.
I would appreciate it if more languages had something like ucontext_t or byuu/co, because I don't enjoy tagging every call site with "await" whenever I change a method to do something that might consume some time (and every call site of those functions containing call sites too, and so on), and because I do enjoy being able to write code that uses speculative execution (like for time-travel netcode for a 2d fighting game) without manually converting all my imperative code to a state machine like a compiler should do.
I am a bit of a snob, maybe, but I've come to think one of the bare minimum features for any language is copyable coroutines.
292 comments
[ 0.20 ms ] story [ 351 ms ] threadWhat I want is a Lisp with Python-level libraries.
https://github.com/hylang/hy
Clasp implementation of CL would be another choice, it leverages LLVM for compilation.
The problem is with the library and tooling ecosystem.
Now, you may say that "performance-oriented" doesn't have to go as far as SIMD or caching tweaks. And that's true. But if you want a performance-oriented language that can reach all the way up the performance curve, I don't see it being Lisp.
As someone desiring a performance-oriented Lisp, this is something I'd like. At runtime, I can handle memory myself ($deity knows I often do that when writing performant code). What I want to have is the friendly, homoiconic Lispy syntax, the ability (and the ease) to write code that writes code, and perhaps to have these facilities available at runtime.
From then on you will be known as the "where's the beef guy"
https://www.youtube.com/watch?v=Ug75diEyiA0
it's very relevant if you've ever done low level debugging, which is likely what you'll spend your time doing developing games
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.
Also it would be awesome for you to make a few code samples / tutorials on how to get started with game development with Beef. I'm sure it would attract a lot of people to your language if you show some "proof" it is a nice language for gamedev!
It's tempting to give this a go, but there are so many languages out there... Maybe I'll try a Ludum Dare in it.
Also identical to Swift or C# (the latter being an explicit inspiration according to TFAA comments upthread).
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)
- no exceptions
- mutable strings with optional pointer access
- no GC
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/
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.
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.
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.
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.
- 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.
[1]: https://github.com/bytecodealliance/cranelift
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.
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.
Kind of curious about performance benchmarks vs C# and C++. Did you post that somewhere?
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 ;).
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.
https://langserver.org/
I would suggest adding LSP support as a future todo.
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/
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.
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.
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.
- avoid custom installer like this, while it looks cool, it kinda give an "amateurish" look
- avoid custom IDEs, i'd rather see a CLion/VS plugin; you just waste your time creating something people don't want to use, they want to use their favorite editor
- allow top level functions, so i don't have to create a freaking class to have a main()
- let me do:
// Press F5 to compile and run program
using System;
namespace HelloWorld {
For someone looking for a C replacement where memory safety is absolutely critical (ie- open server applications) then Rust may be a better fit.
Is there any evidence this is a tradeoff? What of linear types?
Bound checking often is the reason rust performs worse on some benchmarks. Though I wouldn't consider this a problem at all since it can be disabled.
The more important part of memory safety is preventing out-of-bounds accesses. Rust, Ada, and (it seems) Beef sacrifice performance for memory safety here by having runtime bounds checking. (Though there is not much performance cost to this and all of those have options to turn off runtime bounds checking anyway.)
The only performance-oriented language I'm aware of that is fully memory-safe at compile time is ATS‚ via a combination of linear types and dependent types, and using ATS is… cumbersome.
Its not all black and white though. Using iterators, bounds checks can often be elided by the Rust compiler.
https://www.beeflang.org/docs/language-guide/safety/
> Leaks can be detected in realtime with the debug memory manager. Reachable memory will be continuously traced at runtime and memory which is no longer reachable but has not been properly freed will be immediately reported as a leak...
Sounds like it doesn't have a Garbage Collector, but a "Garbage Detector" that's only active for debug builds?
Also, testing helps detect bugs, but cannot guarantee security.
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.
No thanks. We already have enough of those.
Golang provided:
* a tour of go + go playground to allow easy testing of the language + immutable sharing links
* effective go to explain how to use the language beyond the syntax/grammar
* strong opinionated choices on things that dont matter (go fmt)
* a strong opinion about non-breaking changes in the language + stdlib
and a number of other things. IMO a language is only as good as it's community.
- the immense success of docker based on it which made everyone build their devops tools in go (kubernetes helped too later)
- a very solid and stable http library included in stdlib (plus other networking goodies to easily run your own ssh endpoint in a few lines of code)
tl;dr to get your language some traction, make it solve at least one problem much better than the competition and have someone build a super popular open source project on it.
So a decent package manager would do wonders. Rust has Cargo which does builds and packages. D has dub as well.
Definitely recommend making code sharing / reuse a breeze.
Is there any possibility that you'll include some efforts towards doing back-end networking with this language as well? I could see multiplayer games needing servers after all.
PS: There's a typo in the Design Goals list - "Compliled (no JIT delays)"
Like he had complaints about other languages, and instead of moaning about them on the internet, he went out and made his own language.
Even a few code examples of some language features right there in the README would go a long way
All I can think is "beef begins to smell after a couple of weeks" and it's hard to overlook that mental imagery when evaluating the vast array of good options in the programming language space.
It may also be considered culturally insensitive to a noticeable percentage of software engineers, which could hurt the adoption rate.
Everyone has their opinion; If the author does not consider it culturally insensitive, then there is no problem.
I think there may be a hidden benefit in pre-filtering the community for "developers who flip their shit over naming"..
The author can do what he wants, but if he wants adoption, then it would behoove him to consider cultural sensitivity, especially if it is offensive to enough people to stifle adoption.
Arguing over meat-related naming is exactly the kind of "alternative viewpoint" I have no time for, i.e I would say it's completely wrong.
Many can play at this game.
If so, I belong to the culture that considers it insensitive to shit on things for light-hearted naming themes as if they are of any relevance next to a million other adoption metrics that are more objective, assuming the author even cares to weigh adoption vs creative license in the first place.
That's totally unfair, but it's how people work.
If no, it has no effect,
If yes, then either you didn't care much in the first place, or you are indeed, flipping your shit.
And no one said it was a bad name, but that it could be considered culturally insensitive - two ambiguities away from actually being the thing it might considered to be.
Would "veal" be an acceptable name?
When I think of eating beef in 2020, I think of a person whose freedom to eat whatever pleases them is more important than human health, suffering of intelligent animals and the environment.
Allow me a bad analogy. If I interviewed someone for a senior engineering role but they went out of their way to mention that they had named one of their children "Stalin" -- that would be kind of a red flag for me.
So to me, naming your pet project "Beef" is kind-of tone deaf at best.
And at worst, it's thumbing your nose at political correctness: "Haha I named my project Beef because beef is great and fine and if you disagree you're thin-skinned and blindly following the crowd."
I think the issue is a lot more complicated than that.
Just my admittedly-biased two cents.
I'm Vegan and the name doesn't bother me at all to be honest. I do not agree with the downvoting of parent though, as his reasoning is er.. reasonable.
Is it? Was the question about how acceptable would "veal" be as a name implying that it would not be acceptable at all? What about “lamb”? Or “pork”? (PORK is the long-awaited Well-Done BEEF, according to https://www.cs.cmu.edu/afs/cs/project/ozone/www/object-syste...)
By the way, there is also https://beefproject.com/
This complaint makes the top 3 comments on every post about a new programming language. It's tiresome.
But I also have to say that the name logo are... offputting. I don't know why exactly; I'm not a vegetarian or religious or anything like that, and the name doesn't bring anything negative in particular to mind (hell, I love eating beef!), but it just feels... wrong somehow.
I really don't think that many people would make that connection.
Is C# culturally insensitive to deaf programmers?
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.
> 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.
I've been looking for a language that would allow gradual transition from C++ for example. If you have a C++ SDK, you could still write your whole engine or just some modules in Beef.
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.
second, this name was likely influence from a programmer meme that's probably older than you: https://en.wikipedia.org/wiki/Deadbeef
please quit being so sensitive for no reason.
stop assuming the problem is with people who care deeply about something and not people who tell them to shut up in public.
If you look at the screenshots it is clearly referencing dead animal flesh with the IDE icons.
https://news.ycombinator.com/newsguidelines.html
All kidding aside, even if you are against the idea of being a carnivore, the name of a programming language does not promote such a thing.
Four, now that it's a programming 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++.
I wonder what you find lacking in the current C++ experience. e.g. with the IDE I use (QtCreator), I can quickly refactor things across million-lines codebases, perform a decent set of more advanced refactors (https://doc.qt.io/qtcreator/creator-editor-refactoring.html), auto-generate boilerplate code, I get in-line hints, lints and warnings while I type all with clang-based auto-completion...
- It still can't handle most of the CMake projects.
- Refactoring/autocompletion/go-to-definition doesn't work on a heavy-templated code.
- Clang must be patched to work correctly (at least code analyzer doesn't work out of the box).
- Code generation sometimes produces malformed code.
- No ANSI escape codes support in terminal/output.
- Random crashes.
IDEA with Rust plugin is years ahead.
I think Rust has the _potential_ to be better, but it's years off and requires the rust community to change how they think.
I'm interested in the IDE due to the authors claims, but I don't really see him making this IDE better than VS + C#. If he can, that would be amazing though.
The said change already happened and Rust devs are currently refactoring in depth their compiler to make it IDE-friendly (taking a lot of inspiration from Roslyn). This is tons of work though and even if it's currently going well, it won't be there before next year.
See this talk if you're interested in this kind of things: https://m.youtube.com/watch?v=7_7ckOKZCJE&list=PLgC1L0fKd7Uk...
* pun obviously intended
I think when rust tooling gets "there", it's going to be able to do some really cool things that no one else can do.
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...
I am sorry to see semicolons though. I have never missed semicolons after moving to languages where they're not required, and it's always a bummer going in the opposite direction.
Asking the tough questions here.
Keeping with the animal theme here
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++.
I would appreciate it if more languages had something like ucontext_t or byuu/co, because I don't enjoy tagging every call site with "await" whenever I change a method to do something that might consume some time (and every call site of those functions containing call sites too, and so on), and because I do enjoy being able to write code that uses speculative execution (like for time-travel netcode for a 2d fighting game) without manually converting all my imperative code to a state machine like a compiler should do.
I am a bit of a snob, maybe, but I've come to think one of the bare minimum features for any language is copyable coroutines.