For sure, the compilation times can get pretty bad with Scala, although I haven't found it too terrible on smaller prototype projects (I agree its still quite slow compared to some other languages though).
These day's I've been using Bloop (https://scalacenter.github.io/bloop/) which makes Scala compilation super fast. It keeps a hot compiler running in a daemon and takes incremental compilation to a whole new level for Scala, truly a game changer for me.
But the last version with major changes was C11, nearly a decade ago. Even that was almost entirely backward-compatible, other than a few very specific cases like removing the inherently dangerous `gets` function from the standard library. And even that removal followed formal deprecation several years earlier, and widespread advice not to use it at all for many years before that.
Put another way, while the C language has evolved, you can still compile C code written several decades ago using modern tool chains with an excellent chance of having it work immediately or at worst needing some very minor changes.
It’s depressing that some of the comments in today’s discussion are praising Clojure because code often still works after 5 years. Obviously that is itself a good thing, but is only 5 years now a remarkably long time for code to still work?
There is very little that has changed that isn’t backward compatible, though, and what there is has mostly been in areas that no sensible programmer should ever have relied on in more than toy programs anyway, like inherently unsafe functions or undefined behaviour. You probably have to go back to C99 prohibiting some things that used to be implicit and therefore to code written over two decades ago to find “real” exceptions to that. Compared to many “modern” languages, I’d say that’s still an excellent track record for longevity and compatibility.
Toy programs like Linux kernel, once an heavy user of VLAs, which only GCC and clang ever implementated, while everyone else just moved from C89 to C11 without ever caring about them.
Sorry, I’m not sure I’m understanding your point here. Are you claiming that variable length arrays have been removed from C in recent standards after they were added in C99? Or is your objection that some compilers are very slow to support language features even after they have been standardised? Or something else?
It was dropped from C11, moved into optional annexes and all commercial compilers that were yet to be fully C99 compliant just moved to C11 instead, without bothering with optional annexes.
The world of C compilers isn't only GCC and clang.
Something being dropped is not the same as making something optional. In this case, the latter action was an explicit recognition of the reality that many compilers never fully implemented the previous standard anyway.
The point here was about backward compatibility. What standard C99 code is not also standard C11 code? What used to compile a few years ago but won’t compile today? We all understand that there are some minor exceptions, but I think it’s fair to say the answer to both question is not much.
Any use of Annex K functions, gets(), any code that is considered semantic invalid under C11 memory model, or gets wiped away with the new UB cases from C17.
Maybe an unique historical opportunity for a tool "good enough" to do the job, seizing the widespread adoption possibility, and letting no room in this ecological niche.
That is, yes, there is room for stable languages, but it’s already fully occupied. So only languages targeting market with a mindset open to "better moving continuously anywhere than risking sclerosis" can flourish.
Stable is not frozen. Yes, C got updates, it doesn’t mean they introduced large sets of features, which is what this thread is about. C did not incorporated much things over the years, unlike C++ for example.
The introduction of the C11 memory model was a huge change. Superficially, only a small amount of features was added, but the impact on writing parallel/concurrent code in a portable way is hard to overstate.
When I go to a store and buy Milk the carton doesn't say "Milk made by Cows". When I go to buy Milk/Milk-substitutes from other sources they'll be called "Almond Milk", "Goat Milk", etc.
It seems like you stop saying "made by Cows" when it's not surprising that the Milk you'd be buying is from cows.
I write software in Rust, so to me it is relevant to learn about new libraries and frameworks that are written in Rust.
There are enough existing and new game engines and frameworks that if the title was simply “Bevy: A Game Engine”, then I might not have bothered to clicked on it only to find that it was written in C++ or Lua or Python or what have you. I use other languages too, mind you, it’s not that – it’s just that aside from Unreal, Unity and Godot, the only other game engine or framework that I am interested in knowing about at the moment is one that is written either in Swift or in Rust.
Conversely, stating it upfront also allows anyone that does not want to write in Rust to avoid this particular game engine at the moment.
It's to get adoption by that particular group that uses X and has to deal with the issues of that domain and the default language they all use ... It's a way of saying: you could be doing all your _real_ development in Rust
> Since when it's been the most interesting thing about the software in which language it's been written in?
Presumably because I'm going to be writing the same language when I interface with it. Rust can export to a C API but if I'm using Rust myself the API is going to be better.
It's interesting if it's truly unexpected. For example, there's a game that's been in development called Black Annex that's written in QB64 which looks quite complicated for having been written in a BASIC variant. But for Rust, which is commonly advertised as a C/C++ replacement, it seems unnecessary. I think that developers include that information because they don't feel that Rust's traction isn't being given enough recognition.
The first thing I look for in a game engine is what language it's written in. The second thing I look for is what language(s) it lets the user write games in.
In this case, the thing we're talking about is a library that uses Rust data types and interfaces.
It might be possible to create language bindings for C or C++ (or whatever language you want to use), but the docs on the website seem specifically targeted to Rust users. So for now, the only people likely to be interested in using this are Rust developers (though people coming from other languages might find the general design interesting).
OP here: without being clickbaity, the idea was to choose a title that gave people some idea of why they might want to read about it. And titles can’t be that long.
I’m told Bevy does really interesting things with traits, for instance, but even that is too long for a title.
I think the people rationalizing are wrong. You're right that you see a lot of posts with "X is a Foo written in Rust!".
A few years ago I saw a bunch about Go, too. That seems to have died down.
But I think the real reason is that people are excited to use Rust for "real stuff". And a lot of Rust fans don't get to use Rust at $dayJob or whatever. There's also a bit of naysayer criticism that it isn't a practical language, etc.
So, no, it doesn't really matter that something is written in Rust. It's just Rust fans being hyped up about it. It might be a little annoying, but replies like yours aren't really any better, honestly.
Because it implies that it is extendable/scriptable in that language.
Unity and Unreal, for example, are not scriptable in Rust. Anyone interested in writing games in Rust would surely be more interested in an engine that supports it.
I think it's actually pretty common that when a fairly typical thing is written in a newer/modern/less common language, it's often stated as "X written in <new language>"
I had the same experience yesterday. Tried to setup a personal account to access a group and next time I logged in I got the same message about not following their "Community Standards". How is that possible? I didn't even do anything yet! Continued for them to review the ban but I had to stop on the very first step where they asked my phone number since I'll never give them such an information. Now the whole shit is stuck and I cannot even remove my account without giving them my number.
Isn't this just a phishing scam? This should be illegal.
