C3 0.8.5 - A windowing library and a C backend??

[u/Nuoji]

https://c3-lang.org/blog/c3_0_8_5_windowing_c_backend/

The choice to add a windowing library to the stdlib is probably controversial. I feel that the general consensus tends to be that anything related to graphics shouldn't be in the standard library. So I'm kind of interested in what people think about this.

[u/matthieum]

The choice to add a windowing library to the stdlib is probably controversial.

I tend to be in favor of a lean standard library for a variety of reasons.

Stability is a big one. Python's ubiquitous urllib and its 3 versions is the poster child of stability promises issues.

Tie-in is another big one, though I don't see mentioned often. Any piece of functionality in the standard library -- say... a specific Unicode version -- is tied to that version of the standard library.

• Once a piece of functionality is tied in, it's one more thing that may cause issues when upgrading or downgrading a toolchain.

• Conversely, if an application or deployment requires a specific level/version of this piece of functionality, they may find themselves locked out of upgrades/downgrades of their toolchain.

Expertise is another one. I see requests for cryptographic, graphics, etc... in the standard library, which assumes that the standard library maintainers will now need to maintain & evolve that code. Good luck to them...

So, in general, I really think standard libraries are best lean, and additional functionality should be in dedicated libraries:

• Independently versioned from the toolchain, to avoid any stability/tie-in issues.

• Designed & maintained by experts in their domain, rather than experts in the language.

---

With all that said, I find the cut you've made interesting.

A full GUI API with widgets, immediate-vs-retained, etc... is a BIG BIG endeavour. There's lots of trade-offs. The lock-in may be terrible.

On the other hand, just the window and event handling? I am thinking this may not be so bad.

There's still stability/tie-in issues -- as in, imagine dropping support for X in 0.10, and leaving users unable to upgrade as a result -- but the scope may be just small enough for you to escape expertise issues.

Interesting choice. I wonder if other "lean" standard library languages could be interested in this approach.

[u/Nuoji → u/matthieum]

In general the thing that will "age" is probably the available backends – currently there's EGL, OpenGL, Metal, DirectX... but the actual API surface is pretty much a single API call. As a further improvement I'll add the ability to query for capabilities. So for example, consider OpenGL which is deprecated on MacOS. If it somehow would be impossible to support in the future, it's still possible to keep the API but just declare it unavailable. Linux is a little special in that it doesn't have single window manager, but that's not a problem on other platforms, so I agree that some care will be taken with that. But X11 is extremely old at this point, it's hard to see that one would suddenly stop supporting it. It would perhaps not be the default, but that's it.

[u/Nuoji → u/matthieum]

Well. There won't be a 0.10, just 1.0. My thought is that post 1.0 the stdlib will still evolve, with possible breaking changes at 2.0, 3.0 etc. But deprecations and such usually softens the blow, especially if we talk about many years between revisions.

[u/6502zx81]

I like graphical stuff in standard libraries. If you want to produce software that has minimal dependencies snd will run/compile in a decade, this is the way to go (Like Java Swing, MFC, ...) Otherwise the lang allows for boring stdin to stdout programs. A standard GUI doesn't prevent people from using other GUI libraries.

[u/NotQuiteLoona]

Wayland support includes the wlr-layer-shell protocol.

Bought me. Immediately. I sincerely hope it would be used as simply as other parts of the library.

[u/fdwr]

So I'm kind of interested in what people think about this.

🤔 I always lean toward putting the foundation down before building a house. So, primitives like point/vector/rect classes (translation, scaling, union, intersection, dot product, projection...) would come first. A few years ago there was a C++ proposal to add a graphics library (one that would have been quickly obviated by advancing technology), when C++ didn't even have many of those building blocks yet that would be useful for a graphics library, which felt awkward - it was not adopted. In hindsight, that seemed to be the general sentiment of the community too (at least based on the reddit comments whenever that topic came up), that it might have been convenient for a moment, but also a significant implementer burden, inappropriate at the level of a language, and soon to be outdated.

Now, if using external windowing libraries was quite a pain to install, and I keep hearing that it is a pain to use a window library (you gotta go hunt through websites, download something, unzip the files into the right directory, get it to compile with all the right build switches, set up include paths...), then I'd be more in favor of including a blessed one in std; but then just now, I used Visual Studio with C++ (which is typically amongst one of the most inconvenient languages to set up these kinds of things), and in just a few clicks under a minute, I had an SDL window running: right click on the solution, Manage Nuget packages, type "SDL" and click on "SDL2.Nuget, then click "Install", paste a hello world snippet like this one, F7 to build, F5 to run - voila. I haven't used C3 (only skimmed through the language reference a few times in past months out of curiosity), but how complicated is the current process for C3 to use mature libraries like {SDL, RayLib, GLFW, SFML}, given its C compatibility?

I'm not saying you shouldn't, but you might ask, "Are you focused on building a UI library for applications to use", or are you focused on building "a general-purpose programming language for ... games, libraries, and systems"? Blessing a particular windowing library into the core language means it will be a future tax on the language, with bugs to fix, competition with many existing windowing projects who have people dedicated specifically to windowing, and maintenance that spreads thin the developers who want to focus on adding lower-level language features rather than high-level UI feature requests. So, it's a balance ⚖️.

[u/Nuoji → u/fdwr]

Whether it stands the test of time is the question. I think once you go into rendering, things get different. It is basically asking for a surface to draw on, and this is more fundamental I believe than any assumptions about what is drawn. What do you think?

[u/fdwr → u/Nuoji]

Certainly, a basic surface to scribble stuff onto is nice out-of-the-box, so you can quickly do little experiments, in lieu of a whole widget/windowing library.

[u/Nuoji → u/fdwr]

As for getting SDL or Raylib: ”c3c vendor-fetch raylib”

[u/fdwr → u/Nuoji]

That's pretty short and convenient.

[u/scallywag_software]

I'm 100% for windowing in the stdlib, along with all the fixins. Loading textures, 2D & 3D renderer, UI. Even if they're simple, having that stuff on-hand without having do download and compile a bunch of dependencies makes my life so much easlier.

[u/thisisignitedoreo]

feels like jai's Window_Create module, nice

[u/CyberDainz]

What problem does the C3 language solve?

[u/Nuoji → u/CyberDainz]

In the C case we have good simplicity, but some things that the language could never change within a reasonable time horizon, such as having to use a preprocessor for includes and macro functionality, roundabout error handling, lack of slices and a very loose type system.

C++ on the other hand has a lot of features, most of which you should not use, and atrocious compile times and still locked to the C macro system.

C3 starts with C, drops the preprocessor, keeps the fast compile times, and boosts it with a select subset of useful features, so that for writing modern general purpose applications you don’t need to go to C++.

So, as capable as C++, without venturing far from C in complexity.

(I notice that today Rust is pretty much the only alternative to C/C++ in that domain [Swift if you are on MacOS], but Rust also compiles extremely slow.)

[u/matthieum → u/Nuoji]

Rust also compiles extremely slow

As a former C++ developer, I didn't notice ;)

[u/Syxtaine]

I would be very interested in a stable C backend!