Beyond C#

First of all, I personally love C#, but I’m sure there are many developers who prefer other languages for good reasons.

We all are now happy that with S&box we finally moved from Lua (which was mindblowing at the time) to C# which seems to be the best option today.

But we don’t know what will happen tomorrow and what great languages will dominate the market and developers’ preferences, it would be great to make sure it is as easy as possible to compile other programming languages to something S&box will handle to keep the platform attractive and actual for many years.

Is there any comment to be given on that topic currently and/or any future plans?

2 Likes

I don’t really think C# will be “outdated”, even if new languages apears, they will never replace it to the point it became unattractive for the platform like you said.

8 Likes

I second @Matyas. Even lua is still to this day great at what it does. Maybe lacking some aspects of oop, but i’d say it surpasses even some modern scripting languages.

5 Likes

i dont think that would make sense to either change the coding language later on (will break everything) nor to add support to multiple languages as it would bloat the core and would make it harder to maintain

you should be able to add support to other languages for yourself tho (afaik)

1 Like

Unity and Oxide already showed that having support for multiple languages is not a good idea and results in a lot of maintaining that is not worth it. Both removed support for the other languages and support only C# now.

If you really want to use a different language, you can already do so just by using a different .NET based language. Garry said that we can basically do anything on the server, so it should be possible to load addons from assemblies written in any .NET compatible language. He also said that the server sends the addons to the client as assembly instead of the source code form, hence this would work on the client too.

Some .NET compatible languages are PHP (via PeachPie), Python (via IronPython), Visual Basic .NET, etc.
Here is a complete list of all .NET languages.

There are limitations with this approach: The way how Facepunch does RPC’s won’t work without their own C# compiler, as they have modified the compilation process for that. You will have to manually call RPCs instead like calling normal methods. Code generators would also very likely not work. You would also have to come up with your own hotloading solution.

Source:
image
and
image

4 Likes

This is good to know, thankyou Trojaner, if anything we can always create a decompiler to transform the assembly language into a higher more interpretable form.

By assembly I’m referring to .NET .dll files, not the assembly language. I know it can be confusing.
You don’t have to deal with the MSIL bytecode, only if you want to create your own language / compiler.

1 Like

I know that there’s a thing called CIL, and I don’t think supporting spicific languages other than C# out of the box is a good idea

Just wanted to check if we’d be able to compile some CIL-compatible language other than C# (either officially or by a custom CIL-compiler) and use the resulting assembly as a S&box addon

We can get compilers and transpilers from whatever to whatever, but it’d be much nicer to be able to compile other languages to some form of usable bytecode instead of trying to transpiler it to C# plain source first

1 Like

Like mentioned, this is very likely possible on the server. If not official, it won’t be hard to mod it so it loads your own assemblies. You can also send addons from the server to the client as assemblies, garry himself confirmed this. What you likely can not do is upload it to e.g. workshop or whatever they are going to use, as chances are high that only C# will work this way.

1 Like

Personally I would much rather have multiple languages that you can use. For example C++ or C would be nice and not only C#.

2 Likes

you can call c++ code from within c#

not sure what the benefits of doing so is though…

Personally, the decision I make in whether or not to buy S&box will be heavily based upon how much I can leverage the power of Rust in developing for the game. If I cannot take advantage of the powers of fearless concurrency, zero-cost abstractions, move semantics, guaranteed memory safety, threads without data races, trait-based generics, pattern matching, type inference, all with a minimal runtime, then I don’t know how anyone can be reasonably expected to create safe, reliable, and ultimately enjoyable and useful addons for a game–particularly one like S&box. Even if I need to use a little bit of interop with C# (even though the thought of it alone makes me nauseous) then it will all be worth it so that I may use Rust.

4 Likes

re: Rust in s&box

Theoretically you can compile a cdylib target w/ Rust and link against it dynamically in C#, or any other .net runtime.

Beware though, like you mentioned, you’ll be stuck writing a bunch of glue code to interact w/ C# in Rust and vice-versa. Probably more work than it’s worth- but the rust ecosystem is ripe with tooling around automatic bindings generation. I found a crate that can spit out C# bindings via some Rust macros.

The problem is you’re going to be stuck with writing safe wrappers around C# and s&box implemented constructs anyways. Structures you want to pass down to C# and vice-versa have to be c-compatible which makes your rust code ugly. Managing memory is also a concern, given that .NEt uses a GC and rust’s memory model is unmanaged. On a more optimistic note, the community could maintain a crate (much like the web-sys and js-sys) that provides bindings for s&box-related constructs.

Most of the same issues would be present in trying to link any other compiled language to the game’s runtime. To run an interpreted language like Lua or JS, you’d have to get that running via a native binding, then somehow load scripts in that environment after initializing said interpreter. Maybe there are some C#-native interpreters for these languages but you’d probably outweigh any benefits of writing in those languages with the speed implications of running a half-baked implemented interpreter.

I imagine all these ideas would “just work” on the server- there are obviously security issues with being able to send that down and load blob binaries on the client.

On that note, I think it’d be worthwhile to look at implementing a WebAssembly (WASM) runtime. This would allow both servers and clients to execute binary-compiled code (from many languages) at god-speed and in a sandbox. You wouldn’t be able to access system threads, filesystems, or traditional tcp/udp network stacks, but I think it’d be a great asset when you need to crunch a lot of numbers or do some normally-expensive routines (… like flood-filling, path-finding, image manipulation, etc). Wasmtime is picking great traction and there’s even some work done to spawn an engine in .net (google Wasmtime and wasmtime-dotnet, sorry- reached the max links allowed for my first post!)

2 Likes

WASM support in some way would be neat, totally agree

Now I’m scared because I can’t work out whether you guys are joking

5 Likes

Is it because wanting anything other than what we are already promised (a hotloading C# layer) is dumb or because all of the above is achievable to some extent and we’re making it sound like something requiring a lot of effort for no reason? :grinning:

Option one

2 Likes

Haha, got it. Well, in any case it’s C# which is great, if anyone will desire something else it’ll be a fun journey for them fucking around with transpilers and shit. Thanks for clarifying in any case :smiley:

UPD:
Nerds will always want to do things in ways they’re not really supposed to, no matter how great of an API you will design for them, they’ll find ways to do things in a crazy non-standard way. Not that it’s good or bad or something everyone should do, it’s just a fact

3 Likes

Just because its achievable it doesnt mean that should be achieved tho

1 Like

I totally agree on this. We have C#, what else do we need? It’s a powerful language and will serve the purpose well.

1 Like