linkdd

  - on chess.com you can premove multiple times, each premove consume 0.1s on the clock
  - on lichess, you can premove only one time, but it does not consume time on the clock

Also, from personal experience (so this is only anecdotal), the most toxic players (insulting in the chat, or ragequitting, ...) I met were on lichess.

Comments of the form "X is better than Y" are subjective and do not add any value/information to the discussion.

Never truly finished it, but it works well :)

What I'm criticizing is the extra step of me having to write the .c files anyway to avoid bloating the obj files, which should have been done by the library in the first place.

The "numbers argument" is a fallacious one.

No, "how you are supposed to distribute a C library" is not my opinion, but the experience/observations of the last 50 years of engineering. Why would we even have a .so/.a/.lib/.dll format for libraries?

As I said in a sibling comment, those are not header-only libraries. It's poorly packaged .c/.h in a single file that we happened to name with the .h extension.

It's not a header, it's a header+implementation. And it's bad practice, and any decent C developer will tell you so.

It is bloating my ABI if I'm not careful, and it makes distributing more cumbersome when it could/should be straightforward.

That's just not how you are supposed to distribute a C library, this is a poor design that clearly states "I don't know or don't care how to package my code".

  #define XXX_IMPL
  #include "xxx.h"

  #include "xxx.c"

  - I like my object files (.o) to only contain what they are supposed to contain and nothing else
  - I don't want to have to keep track of where did I put the `XXX_IMPL`

Now, the library gives me a .h and a `#define XXX_IMPL`. So to avoid making the mistake of defining XXX_IMPL more than once, I'll have to make a .c myself for each file of the library, and then I still need to write the CMakeLists.txt/Makefile/whatever.

This is just wasting my time for no good reasons.

I linked the imgui repository because that's what they do, they give you the .c/.h and you decide how to build it. You just have to copy/paste, no time wasted.

> Just copy paste the source code in your source tree

And/Or make a simple CMakeLists.txt like this:

  cmake_minimum_required(VERSION 3.22.0)
  project(mylib C)

  file(GLOB_RECURSE MYLIB_SOURCES
    ${PROJECT_SOURCE_DIR}/src/*.c
  )

  file(GLOB_RECURSE MYLIB_HEADERS
    ${PROJECT_SOURCE_DIR}/include/*.h
  )

  add_library(${PROJECT_NAME} STATIC ${MYLIB_HEADERS} ${MYLIB_SOURCES})

  target_include_directories(${PROJECT_NAME}
    PRIVATE "${PROJECT_SOURCE_DIR}/include"
  )

It will simply force me to make a `.c` file for every `.h` and define it there.

Why not simply distribute the .c/.h like imgui does, or lua, or many many others? I'm already copy/pasting your .h files, I would not mind copy/pasting .c files and adding them to my build system, since that's what I'm gonna do anyway to make sure i do not define `XXX_IMPL` multiple times.

Header-only libraries truly only work in C++ when it's all templates anyway.

The ones present looks good, though I was looking for a responsive navbar one (since that's a component I reuse in 99% of my projects).

I suck at CSS (I know the language, but I'm not a designer). It's like painting, I know how to take a brush and put paint on a canvas, but whatever I do is just ugly. This is why for frontend stuff, I like to rely on frameworks like https://bulma.io

Tailwind is a nice framework, but it requires me to know how to make something beautiful, which I'm unable to. So frameworks like this one are more than welcome!

Rust is still backward compatible (old code will compiles on newer compiler versions) so you won't be rewriting what already works.

You won't use unsafe that much (especially once the hardware parts have been abstracted), see the link I gave you as proof.

The advantages of Rust are not pointless:

  - the type system
  - the ownership/borrowing/move semantics
  - the ecosystem
  - the build system
  - the way you can contain the memory-unsafe parts in a small/controlled API

Go, Dart, Carbon, Mangle, am I missing some?

I'm not criticizing, I would not dare as I'm creating my own language as well :P

I managed to make a very very simple OTP-like framework with Trio: https://linkdd.github.io/triotp/

Is a Monty Python reference, what follows is actually, completely different. They did not lie :)

Yeah we managed, I never said the opposite. I only talked about why I liked header-only libs: because I just copy/paste the source in my source tree, regardless of the build system I use.

If I'm using CMake, and a library is using autotools, I'll have to rewrite the lib's build system, and maintain it. I'm too lazy for that.

I do also like easily embeddable tech like imgui, or lua, where you can simply copy the source code in your source tree.

  mv mylib.h mylib.c
  gcc -c mylib.c -o mylib.o

After further research, there is no scientific proof nor studies that would demonstrate the effectiveness of this method.

I would not underestimate the placebo effect, but a method where the name is a trademark, and can only be taught by people part of the organization seems too fishy.

If it is so effective, why is it not part of psychology curriculums?