keywords VS flecs

> I'm not sure here how you differentiate minimalist from restrictive.

The flexibility of the language and its syntax. The more constructs are syntactic, the less minimalistic it is, and Go is a very syntactic language.

> I've always considered Go to be minimalist in terms of available tokens to the programmer: https://github.com/e3b0c442/keywords/blob/main/chart.png

No language on this chart has even a passing resemblance to minimalistic. I don't think anything does when it reaches double digit keywords.

For reference, I believe Smalltalk has 6.

And forth is more complicated because it doesn't really have keywords at all, and barely any syntax, instead it has assembly-coded / runtime-provided words (~functions) and variables. SectorForth (https://github.com/cesarblum/sectorforth/) is down to 8 builtin words, 2 IO words, and 5 variables (milliforth packs those behind a word instead). And so far 2 of the words have been found unnecessary / redundant.

> I like Rust's pragmatism.

Me too.

But Scala is also a very pragmatic language. If you want something academic go for Haskell.

> Allow limited operator overload.

Nitpick: Scala does not have any operators. So it doesn't have operator overloading at all.

Scala simulates operators by infix method syntax.

Instead of writing `1.+(2)` you can just write `1 + 2`. But the later is the same method call as the first one!

> Eschew HKT for a simpler abstractions.

AFAIK HKTs are more or less "just postponed" in Rust, AFAIK.

People would like to add them of course. The discussion goes on forever by now. Some small insight (there is much more when you look for it):

https://github.com/rust-lang/rfcs/issues/324

https://internals.rust-lang.org/t/higher-kinded-types-the-di...

> Don't go in the deep end with type power, nor too much in opposite direction and avoid any complicated feature.

While having a full ML style type system with afine types on top, and quite some other type level mechanics up to singleton types?

Sure sure, no power in here. :-)

> The more powerful feature the more abusable it is, and Scala loves the power at all cost.

Everything is "abusable". This is not an argument.

But that Scala loves power at all cost is simply not true. The contrary is.

Just to cite one of the most influential post in Scala land of all times:

https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...

This, and the BDFL constantly complaining about unnecessary complex code people write speaks for itself.

Scala lately even reduced the power of some features just to prevent "abuse". (Which is partly an overreaction; but that's another story).

> Why would anyone care? The more flexible/powerful something is the harder it will be to parse by humans and tooling.

That's also not true.

Scala has a very small and simple syntax (despite all the language features).

Scala is on the surface much much simpler and much more regular then Rust!

https://github.com/e3b0c442/keywords

(You could also compare the language grammars. This would be even more in favor of Scala in this regard).

Scala 3 looks even almost like Python!

https://docs.scala-lang.org/scala3/book/scala-for-python-dev...

> Plus Scala has the big deal breaker. GC and no custom primitive types.

What a "deal breaker"?

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

You've seen this here in the thread?

Also:

https://docs.scala-lang.org/overviews/core/value-classes.htm...

As soon as Valhalla lands in JVM-land this will be full blown value types without any limitations.

And in Scala Native you can have of course native structs today. (Only that Scala Native isn't ready for prime time just now).

In the long run Scala Native could also run without GC. The Caprese project will bring something that is more powerful than Rust lifetimes. Lifetimes will fall out as a special case of a more general concept.

> > Besides that: The Rust people are looking envious. I've read about some ideas that were more or less a direct copy of Scala's implicits.

> What do you mean exactly?

Implicits get discussed every now and than in Rust land. Even the above Rust internals discussion start with them.

Or this here:

https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa...

Also I've once read something that looked like a brain storming for future Rust features. They came up with more or less implicits (only that they didn't call them like that, so I can't find this any more, didn't bookmark it).

Someone even once proposed directly Scala's implicits for Rust. But this went nowhere as the other people on the forum actually didn't understand them (which was no wonder as the example was quite terrible and the proponent was not really experienced with Scala so couldn't explain it well). People came than to quite wrong conclusions (some of them even mixed implicits in general even the dreaded implicit conversions, which were in fact mostly overused and caused trouble in Scala; but things got redesigned exactly because of that).

Check out: https://github.com/e3b0c442/keywords

In order to actually answer your question in some form: Here’s a list of programming languages ranked by number of keywords.. Looking at this list, consider that PHP used to be considered a beginner friendly language and that Java is often chosen as the first language for new CS students. Your question seems to be difficult to answer!

I've also been enjoying building My First Game™ in Bevy using ECS. The community around Bevy really shines, but Flecs (https://github.com/SanderMertens/flecs) is arguably a more mature, open-source ECS implementation. You don't get to write in Rust, though, which makes it less cool in my book :)

I'm not very proud of the code I've written because I've found writing a game to be much more confusing than building websites + backends, but, as the author notes, it certainly feels more elegant than OOP or globals given the context.

I'm building for WASM and Bevy's parallelism isn't supported in that context (yet? https://github.com/bevyengine/bevy/issues/4078), so the performance wins are just so-so. Sharing a thread with UI rendering suuucks.

If anyone wants to browse some code or ask questions, feel free! https://github.com/MeoMix/symbiants

Flecs does just that: https://ajmmertens.medium.com/why-it-is-time-to-start-thinking-of-games-as-databases-e7971da33ac3

I'm trying to optimize my workflow as much as possible, and came across this thing called an ECS. After doing a little bit more digging I found some decent guides on how you would make one, I also found one premade called FLECS. FLECS is nice and all, but I was looking for something more simple that just has the bare bones of what I need and is also configurable. I haven't been able to really find anything like that, so I was wondering if anyone had an example of maybe their way of implementing an ECS. I know how to go about it, but I'm unsure of exactly what the code would look like.

Since we wanted a common game simulation that would be on both the server and the client we looked into a few libraries that would fit our ECS needs. It was decided we were going to write this common part of our game in C++, but rust was considered. C++ was a familiar language for us so naturally EnTT and flecs came up right away. I had used EnTT before, writing some small demo projects, so our choice was made based on familiarity. In order to integrate with Unity we created a small C interface to communicate between our simulation code and Unity’s C#. Here’s close to what it looked like. I removed some parts for brevity sake.

Repository: https://github.com/SanderMertens/flecs

This is the project: https://github.com/SanderMertens/flecs (query engine implementation lives here: https://github.com/SanderMertens/flecs/tree/master/src/addons/rules)

There's also a performance question. While we can now use Blueprint nativization to convert Blueprints to C++ the result will be a fairly naive version, fast enough for most purposes but not if you're trying to push every bit of performance. This is where you're looking at making sure you're hitting things such as using the CPU cache as well as possible for an ECS system (Look at ENTT or Flecs if you want to see what they're about and why you'd want one), or a system needing to process massive amounts of data quickly such as the Voxel Plugin.

If I knew C++ and I'd heard about it before I started my current project, I would have been tempted to use this https://github.com/SanderMertens/flecs which can be built to WASM. Of course you still need JavaScript in the front end to link to the WASM part. I've recently been using esbuild to bundle my front end code, which does a pretty similar job to webpack, but is a bit faster.

When do think bevy will support entity-entity relationships ? https://github.com/bevyengine/bevy/issues/3742.

Flecs ECS already supports this: https://github.com/SanderMertens/flecs/blob/master/docs/Rela...

For a modern engine you’re probably best looking at Unity’s DOTS. You may also want to check out some of the different open source ECS libraries such as flecs and EnTT are two popular ones for C++, but there’s lots of them. Largely you’ll see lots of different approaches taken, all with their own pros and cons. Not all of them will be performant (some focus more on the design benefits) while others will be optimised for certain use cases. What you should prioritise will depend on your specific needs.