
Show HN: Beef, a new performance-oriented programming language - beefdev
https://github.com/beefytech/Beef
======
beefdev
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/](https://www.beeflang.org/docs/foreward/)

~~~
kensai
Sorry, quick and dirty question. Why did you name it "Beef"? Very creative
name. :)

~~~
virgil_disgr4ce
The first thing I thought of was 0xBEEF ;)

~~~
TimTheTinker
Or 0xDEADBEEF :-D

------
maerF0x0
Another "tip" for helping your language grow. I highly recommend you look at
how the golang bootstrapped itself and aim to replicate.

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.

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

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

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

------
Gene_Parmesan
Congrats on the release. This looks like the first C and/or C++ replacement I
might actually give a significant whirl. I enjoy programming in C as a hobby-
grade thing, but it gets challenging organizationally fairly quickly for the
sort of full applications I usually build. And I'm also a big fan of the C#
"mouthfeel," so to speak. I have tried Rust, and while I'm a fan of its design
goals, etc., fully wrapping my mind around the ownership/lifetime system is
just not something I have the mental capacity for right now. I don't use these
systems langs enough professionally (read: at all) to justify the labor cost.

This also seems pretty damn polished for it being the first time anyone
publicly has gotten a look at it. I mean, a full IDE on day one is nuts.

I know Beef seems sharply tuned for game dev (another hobby of mine), but do
you see Beef as being usable for general purpose systems/application
development? Is there anything about it that would discourage its use for a
standard desktop GUI app? And because I'm curious and haven't seen this
answered elsewhere, is the Beef IDE also written in Beef, for some tasty beefy
dogfood?

edit: Nevermind on that last question, I found it answered in the guide (in
the affirmative). Nice!

~~~
mwcampbell
> Is there anything about it that would discourage its use for a standard
> desktop GUI app?

Complete lack of accessibility support, particularly for blind users via
screen readers, in the included GUI toolkit. _Please_ don't use this for any
application that people will be required to use in their job or education.

~~~
beefdev
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/](https://www.beeflang.org/docs/corlib/)
but should perhaps be more predominantly stated.

~~~
mwcampbell
I did eventually find that notice in the documentation, after I posted my
comment (and sent you an email). I should have read more of the docs first.

Still, I wonder why you chose to write your own GUI just for the Beef IDE (and
installer) rather than use an existing general-purpose GUI. Were you aware of
the accessibility issue?

------
AndyKelley
Zig author here. Welcome to the club.

How do you solve the IDE features ("fast and trustworthy refactorability (ie:
renaming symbols)") in the presence of conditional compilation?

btw your name is an anagram of "beefitrian"

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

~~~
AndyKelley
Damn, sorry, wasn't trying to call you out; rather hoping that you had thought
of something I didn't that I could steal from you.

I think starting with an IDE from the very beginning was a smart move.

For what it's worth, here is my current vaporware plan to solve this problem:
[https://github.com/ziglang/zig/issues/3028](https://github.com/ziglang/zig/issues/3028)

I would be curious to see your thoughts on this, especially if you end up
trying to tackle this problem in Beef.

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

------
TheSockStealer
People who write Go are Gophers. People who write in Rust are Rustaceans.
People who write in Beef are Beefeaters? Carnivores?

Asking the tough questions here.

~~~
1wd
Beefcakes?

~~~
ilikehurdles
I like this one the most.

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

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

~~~
Lerc
This seems very similar to the FreePascal approach.

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.

~~~
masklinn
> This seems very similar to the FreePascal approach.

Also identical to Swift or C# (the latter being an explicit inspiration
according to TFAA comments upthread).

~~~
Lerc
I guess that makes sense given the provenance of C#

------
metaculus
How is it "Performance-oriented"? Is there a special language construct that
is exclusively for performance?

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

------
0xBA5ED
This project would benefit greatly from a bulleted feature list with the best
features at the top. The lofty goals should be _under_ that imo.

~~~
Scarbutt
[https://www.beeflang.org/docs/foreward/](https://www.beeflang.org/docs/foreward/)

------
HoppyHaus
Looking lightly at some of the code and the screenshot provided, I'd like to
compliment on the look of the language. A lot of the newer languages coming
out mess with the "normal syntax" way too much, which discourages me from
learning it. Beef actually looks like I could sit down, and learn the features
of the language, rather than relearning a new syntax that wouldn't translate
well.

I wish you luck!

------
vmchale
It looks like it's not memory safe? What does this offer over existing
options?

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

~~~
vmchale
> value performance over total memory safety

Is there any evidence this is a tradeoff? What of linear types?

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

~~~
MrBuddyCasino
> Rust, Ada, and (it seems) Beef sacrifice performance for memory safety here
> by having runtime bounds checking

Its not all black and white though. Using iterators, bounds checks can often
be elided by the Rust compiler.

------
sida
May I ask something that could be rude, how have you been paying the bills if
you have been working on a language full time for the last 5 years?

~~~
wallawe
From wikipedia[0]: "Electronic Arts announced it was acquiring PopCap for $650
million with an additional $100 million stock option."

He's probably got enough runway for a couple centuries..

[0]
[https://en.wikipedia.org/wiki/PopCap_Games](https://en.wikipedia.org/wiki/PopCap_Games)

------
mntmoss
Hello - the IDE focus looks very attractive from an indie-engine developer's
perspective(small scale development always gains the most from having unified,
consistent tooling). Will this be a customizable environment to e.g. assist
working with asset dependencies?

At a glance I don't have any other major remarks. It looks very much like it's
on the same general trajectory as Zig, which is probably a good sign that that
design space is in the right ballpark for low-level real-time systems. There
is some attraction in having automatic memory available for application-level
tasks with more indefinite boundaries(editing tools tend to develop compiler-
like qualities which in turn creates a need for more introspective style),
though it's probably outside the scope of this language and might be suitable
for a scripting-layer approach instead.

------
scott00
Love the concept. If the author is hanging around, are you working on this
full time, or is this a side project?

------
karmakaze
What's the concurrency model and what thread/coroutine support is available or
planned? I see some supporting classes in the System.Threading namespace.

~~~
beefdev
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++.

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

------
axilmar
Sorry but I cannot stand the separation of structs/classes and 'classes' being
'by reference' and structs by value types. It's the reason I don't like D.

C++ makes a lot more sense: the type declaration is not coupled to specific
allocation patterns by default, which to me is a lot better choice than
structs and classes ala D.

~~~
gmueckl
Rhis distinction also appears in C# in exactly the same way and I don't find
it that hard to use. Also, Beef allows you to explicitly allocate objects on
the stack via "scope:". So being by vale or by reference is a default rather
than set in stone.

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

------
novok
Do you think you will add nullability / optionals into the the type system
along with ADT types? (Think swift enum's with associated types). I think
structurally they are fairly simple, but very powerful.

~~~
beefdev
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...](https://www.beeflang.org/docs/language-
guide/datatypes/#enums)

------
blacksqr
Any performance benchmarks vs. competitors?

~~~
beefdev
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".

~~~
blacksqr
How about starting with something simple, like a fibonacci sequence
calculation?

More examples:

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/)

------
auiya
Not to be confused with BeEF, the long-running Browser Exploitation Framework.
[https://beefproject.com/](https://beefproject.com/)

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

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

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

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

------
PudgePacket
I love it. Curious if you have written up anywhere your thoughts on Rust, and
how you think Beef differs in the development of Games.

Best of luck, looking forward to following it's progress!

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

~~~
mathgladiator
Also, I love the name. Is it anyway in relation to a strip club?

~~~
reaperducer
I took it as "beef" as in "complaint."

Like he had complaints about other languages, and instead of moaning about
them on the internet, he went out and made his own language.

------
maxilevi
This looks like it has all the missing performance oriented features I wish I
had while I was developing the engine of my game[0] using C#. I will
definitely try it out for my next game/prototype!

[0]
[https://store.steampowered.com/app/1009960/Project_Hedra/](https://store.steampowered.com/app/1009960/Project_Hedra/)

------
rhodydog
I like the idea of beef, c# like syntax but compiled. One question which I
couldn’t find a answer to on the website, can beef be used to create shared
libraries such as dlls? I’m thinking this could be a serious replacement for
C/C++. I’ve tried go, it’s interoperability with the outside is not very good,
and rust requires too much of a learning curve.

~~~
beefdev
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...](https://github.com/beefytech/Beef_website/tree/master/BeefTools/BeefInstall/StubUI)

------
pingyong
The way append allocations work makes me think that you can't have classes on
the stack? That seems at odds with the design goals of making the language
suitable for high performance applications - I mean sure you can use structs
for everything but at that point you're kinda giving up the benefit of using a
modern language.

------
sida
What is the long term vision for this language?

For us to pick up a new language and potentially use it for work, I need the
confidence that this language is going to stick around and have a user base.

Go and Rust benefitted from being backed by Google / Mozilla.

Whereas, Beef doesn’t even have a corresponding game engine. Have you thought
about you will grow the language usebase?

------
animex
Why a custom IDE vs. a VSCode integration? Or is that the business model?
License the IDE?

------
kreco
A "perforance-oriented" language without benchmark. That's something.

------
MattRix
What are your thoughts on Unity's Burst compiler? It allows for writing C#
code that is compiled to code that is (theoretically) as performant (or even
more so!) than regular C/C++ code.

------
jariel
This looks amazing.

Questions:

1) Why your own IDE and not VSCode or something?

2) Can you tell us how this varies from Rust in terms of practical
applications?

3) C++ integration support?

4) MacOS?

I really like your pragmatic ethos on this, it looks like it was designed to
be used not talked about.

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

~~~
jariel
Thanks. By c++ integration support I meant able to use C++ headers and link to
C++ binaries.

This is really a great project, very pragmatically oriented, I wish you well.
It's hard for any new language to gain momentum without underlying platform
buy-in (i.e. Kotlin became 'a thing' when Google adopted it for Android). But
I hope you can find an angle.

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

~~~
exikyut
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).

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

------
dj2503
At the language level, it feels that Beef has more concepts and is more
complicated than Jai. I don't know which one is more expressive and more
readable when actually used.

------
zelly
What is your opinion on Blow's Jai programming language?

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

------
rishav_sharan
Can you add a scoop based installer for windows? That way it will be easy to
update the compiler.

------
skrebbel
FWIW, hats off for the installer UI design.

------
throwaway675438
Well done!

A small suggestion to rename the language to "dogmeat" instead to align even
better with your meat logo. Filename extension could be ".dm".

------
NonEUCitizen
Do you support P/Invoke?

~~~
gmueckl
No. This language isn't running on .NET. Interop with other libraries is
accomplished via C function call conventions. This goes both ways in Beef.

~~~
beefdev
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).

------
skrebbel
I'm blown away by the completeness of this. The IDE is extremely full
featured, albeit a little weird in places (eg scrolling with my laptop
touchpad basically doesn't work). Love the Windows installer. But wow, go to
definition, refactorings, debugger with great UX, callstack, etc.

Also love the example game. It's written so cleanly that I learned a thing or
two about 2d gamedev just from scrolling through the code.

I love the little pragmatisms in the language, eg:

    
    
        for (let entity in gGameApp.mEntities)
        {
            if (let enemy = entity as Enemy)
            {
                 // .. do something with each enemy
            }
        }
    

That if/let/as combo there is something I'd have loved to have in many
languages.

Also hats off for switch/case without break. Finally! I also love how you're
mixing C/C++ "global enum value names" convenience with namespaced safety:

    
    
         public static Result<(char32, int32)> TryDecode(char8* buf, int bufSize)
         {
              ...
              return .Err; 
              // not Result.Err, because the return type is given in the signature
         }
    

I know that these little syntactical things are not the key challenges of
language design, but obviously they're the first things I see, and I like the
amount of attention you've given them. You really only have the opportunity to
get them right at the very beginning.

I think the docs are a little sparse still (but that can be expected, of
course). Eg:

\- I found it hard to parse this:

    
    
        public Random mRand = new Random() ~ delete _;
    

There's docs about it here [https://www.beeflang.org/docs/language-
guide/datatypes/initi...](https://www.beeflang.org/docs/language-
guide/datatypes/initialization/#destruction), but the "delete _" part isn't
really explained. What's that underscore? I can infer that it probably means
"this value", but I can't find it back.

I love that you made it easy to destruct fields like that, right there in the
initializer expression, btw. Will probably kill the need for 90% of destructor
methods out there.

\- Apparently this converts floats to ints:

    
    
        (.)(mX - entity.mX)
    

Or at least it does in HeroBullet.bf:15. I'm thinking maybe this does
something similar as `.Err`, in that the dot makes it cast to whatever the
expected type is in the function being called? I'm not sure though, it looks
like a super powerful feature, maybe :-)

Finally, I believe .bf is also used for that other super convenient and
performant language, Brainfuck. I doubt that causes any practical problems,
but then again, why not just .beef?

~~~
beefdev
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".

~~~
skrebbel
"Really really" is a very good reason.

Come to think of it, this is an excellent opportunity for even broader
interop! Just make the compiler parse any series of, say, 5+ consecutive
!?,.+-[] characters not as a parse error but a Brainfuck expression! What
could possibly go wrong?

Wrt the "_" and the ".", if those are documented at all, maybe make the other
sections in the docs (eg the one on destructors) link back to there. I didn't
read the docs from top to bottom, instead preferring to refer to them when I
saw code I didn't understand. I bet I'm not the only one that likes to learn
like that. Note that everything I write here is intended as a friendly
suggestion and feel free to ignore all of it. I'm just a random guy from the
internet.

Finally, wrt casting: I've always found that C-style "(type)" casts are weird
and messy and don't fit the rest of the feel of the code. I wonder why you
took them over? You also have "as" for dynamic-casting, and personally I think
those are a lot more readable. Did you consider stealing some ideas from
Kotlin and TypeScript wrt this to unify the two? Let me know if I'm stepping
over a creative boundary here, but I'm personally quite mesmerized by Kotlin's
!! operator[0], which simply forces a value to be not-null and throws
otherwise. That's essentially what "(int)foo" does in Beef when foo can't be
casted to an int, correct?

Then, if Beef had such an operator, then prefix casts would be semantically
equivalent to "(foo as int)!!", right? Or maybe even the super-nice-on-the-
eyes "foo as int!!" if precedence rules allow. Obviously a naive compilation
of that would be slower (a dynamic cast followed by an if-null), but it seems
like a pretty simple optimization to add.

Maybe "foo as .!!" could even be shortened to "foo!".

Given that you have int? and ?? and ?. already, I could imagine you considered
something like this already and decided against it? Sorry for the rambling :)

Again, great job! Really looking forward to playing around with it more. Still
totally blown away by the completeness of all this. I can't understand how a
single person can pull all of this off on their own time.

I was a bit puzzled by the SDL2 wrapper by the way (SDL2.bf) - I can't find
any place where it refers to a .lib or even a .dll file. How does this work? I
tried to find a Visual Studio-esque "project settings" screen with deeply
hidden list of .lib files but to no avail. How does Beef know where SDL is?

[0] [https://kotlinlang.org/docs/reference/null-
safety.html#the--...](https://kotlinlang.org/docs/reference/null-
safety.html#the--operator)

------
zadkey
Looks pretty cool.

------
kaetemi
Looks nice.

------
ossworkerrights
Would be interesting to describe in more detail what makes it performance
oriented.

~~~
beefdev
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)

~~~
0xBA5ED
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.

~~~
themacguffinman
Not the author but a few I gathered from reading the docs:

\- no exceptions

\- mutable strings with optional pointer access

\- no GC

------
celticmusic
How does this compare/compete with Jonathan Blow's language?

~~~
beefdev
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++.

~~~
jcelerier
> 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](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...

~~~
RazrFalcon
I'm using QtC daily too, and it's far from perfect.

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

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

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

See this talk if you're interested in this kind of things:
[https://m.youtube.com/watch?v=7_7ckOKZCJE&list=PLgC1L0fKd7Uk...](https://m.youtube.com/watch?v=7_7ckOKZCJE&list=PLgC1L0fKd7UkVwjVlOySfMnn80Qs5TOLb&index=4&t=0s)

~~~
steveklabnik
(The work is also directly inspired by the C# work)

~~~
littlestymaar
That's what I meant when I said it was inspired by Roslyn. Did I miss other
things from C# that Rust is borrowing* here?

* pun obviously intended

~~~
steveklabnik
No, I just cannot read, sorry!

~~~
littlestymaar
Ahah no worries ;)

------
brlewis
For those who don't like the name, think of it as the verb.

~~~
ainiriand
What do we do with the icons?

~~~
brlewis
Imagine them as a view inside living muscle.

------
adamc
Looks like another C/C++ language-family product for sure.

What I _want_ is a Lisp with Python-level libraries.

~~~
kensai
Julia. Not exactly Lisp, but the concepts are there. Plays well with Python.

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

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

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

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

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

~~~
skohan
Sure it's expensive, but by simple I mean it's probably one of the things a 5
year old could list if you asked them what kind of foods there are.

------
TristanDaCunha
Does it have to be named after dead animal flesh?

~~~
reaperducer
There are at least three other meanings of the word "beef."

Four, now that it's a programming language.

~~~
mottosso
The logo is an image of a steak. :)
[https://github.com/beefytech](https://github.com/beefytech)

------
crucio
Why celebrate and embrace animal cruelty by using this name? It's very off
putting

------
DarkWiiPlayer
(Note: I'm not complaining about this in general, just giving my opinion based
on the way I happen to do programming)

> which has been built hand-in-hand with its IDE environment

This is a red flag for me. What this implies is that the design of the
language is likely heavily based on the expectatio that it will be used with
the given IDE.

Basing a language on C and C# in 2020 seems like a very uninformed choice to
me. Sure, C is a great language, and C# is very successful, so they must be
good right? But I suspect that line of thinking is also what made the
languages as successful as they ultimately became.

In a world where even javascript treats 0 as false, because it's what C did,
whenever I see a programming language doing things "the C way", I just assume
it's cargo cult language design, because most often that's what it is. That's
not to say that there can't be good reasons for doing things the way C did
them; after all, C did most of them for a good reason.

As for the C# part; other than it also falling into the cargo cult language
category that copies C without understanding C, I don't really like it's idea
of object orientation (which is really just javas idea of OO with a fresh coat
of paint). What syntax it copied from C is acceptable, but tell me a modern
language that doesn't have somewhat acceptable syntax. Even functional
languages don't look like lisp anymore (except lisp itself, of course, which
makes up for its inconvenient syntax with other advantages).

~~~
MattRix
These are really bad reasons to not use a language.

Anyone who makes a language that is not like a popular language (ex C or C#)
should have to do a lot of justification for it, not the other way around.
Change for change's sake is bad.

In other words, if you can make a language that does something new, without
having to have new syntax or paradigms, that is much better.

~~~
DarkWiiPlayer
> Anyone who makes a language that is not like a popular language (ex C or C#)
> should have to do a lot of justification for it

Of course; but that's expected. My point is that this _always_ applies, but
sometimes "C does it, so I'm doing it as well" is treated as a good reason for
things when it really isn't.

Javascript, for example, treats 0 as false in if conditions. This made sense
in C, which had no dedicated Nil-value and used the Nullpointer for that
purpose, so 0 meant both the numerical zero and nil.

Javascript, however, has a dedicated nil-value, so 0 really only stands for
the number zero, which isn't any less a value than any other number, and thus
has way less reason to be treated as falsey.

So, in this example, while C had a good reason to do a thing, that reason just
doesn't apply to JS. Maybe there are other good reasons that do apply to JS,
maybe they just did what C did without thinking, maybe a bit of both.

But it does underline a opint: There should be a reasoning behind every
language decision; one that specifically applies to the language in question.
And I do believe this isn't the case with many C features.

