>>106515866
I just need a furry wife.

>>106515866
>no generics or collections in standard library
>no namespaces
>no modules
>no method syntax
kys fag lmao

>>106516174
Never needed any of these.

>>106515866
Not watching all that.
C is has it's place for writing portable libraries that can be used from modern languages.
Beyond that, IDK why you would want to use it.

Headers and guards, dllexport/dllimport, typedef, long long int vs int64_t vs LARGE_INTEGER, null-termination, a bazillion build systems...
People act like C is a simple language when it has so much bloat and terrible defaults.
Is stuff like algebraic data types and generics really so scary in comparison?

>>106515866
All I need is a fox gf.

>>106516997
>Beyond that, IDK why you would want to use it.
main reasons that guy uses it is unparalleled portability and
immortalized software. he’s autistic and uses a subset of ansi c

>>106516997
>typedef, long long int vs int64_t
>bloat
bait and 0 iq if the others didn't make it obvious enough already

also not watching a 3 hour video since i already know C is all you need

>>106517259
>main reasons that guy uses it is unparalleled portability
makes sense
>and immortalized software
lol
>he’s autistic and uses a subset of ansi c
makes sense

>>106517272
>bait and 0 iq if the others didn't make it obvious enough already
Having to wrap structs in a typedef because C doesn't have modules/namespaces is bloat.
Writing out "long long" to get an integer that is guaranteed to be "at least" 64 bits is stupid.
stdint.h only exists because whoever created the language made a mistake; "long long" is legacy bloat.
Also, don't ignore the rest. Only midwits who have too much time think shit like header guards, API macros for switching between dllexport/dllimport, and the number of build systems are worth messing with when good languages have module systems, accessibility modifiers, and dedicated build systems.

>>106517478
>Writing out "long long" to get an integer that is guaranteed to be "at least" 64 bits is stupid
stdint exists

>build systems
unity builds and bootstrapping your builds with c itself exists

macros suck but they are necessary glue to fill in the gaps, not having namespaces also sucks but the language is ancient and it’s easy to work around by just using long, organized names

>good languages
there really aren’t any. nothing is even close to as mature as c that doesn’t make fucktarded design decisions

>>106517478
>Having to wrap structs in a typedef because C doesn't have modules/namespaces is bloat.
You don't have to, and I don't. I don't mind seeing 'struct' before my structures, helps remind me that it is actually a struct (or union). I typically just use typedef for things like fixed point arithmetic so I can keep track of which variables are what more easily. That's also not what bloat means, even if you did use it.
>stdint.h only exists because whoever created the language made a mistake;
or because every system is different, you don't necessarily know what your code is being run on but you might still want a specific bit length. stdint.h will take care of that for you if it's implemented (or you can make one if you know how the compiler handles it). Allowing the data length (int, long, etc.) to be flexible allows you to adjust for various systems, whether you're working on an 8 bit, 16 bit, 32 bit, 64 bit, or even a 256 bit CPU.
>Also, don't ignore the rest.
I did because headers and guards are trivial to use, dlls I almost never use, never heard of LARGE_INTEGER but looks like it's just a windows defined thing so who cares, I don't use null terminated strings (I just include the length with all my character arrays), and build systems are unrelated to C itself. An old language will eventually gather a ton of different ways to build code written in it because people are free to write their own software, and over time that accumulates.

>>106518115
>I don't mind seeing 'struct' before my structures
most people typedef and use pascal case, I use all lowercase and don’t mind the keywords

>>106518053
>stdint exists
Should have been the default.

>unity builds
That doesn't solve anything with build system mess
>bootstrapping your builds with c itself exists
no, how is that simple?

The biggest pain is trying to use projects that are designed for different build systems as dependencies.
Instead of being able to use one build system, you need to use different ones for different components.
e.g. I have an Unreal project that uses a custom C library as a dependency which itself depends on libjpeg-turbo.
libjpeg-turbo offers files for CMake, which I use to build my library and then copy over to Unreal to build with UBT.
There is no consistency, even though they use the same compiler (MSVC) underneath for both C/C++.
And you see this sort of thing with many large C/C++ projects: weird build system stuff to implement non-standard patterns.

>there really aren’t any
There aren't any perfect languages but there are plenty that are way better than C in terms of design:
- Rust (still maturing, but really good so far)
- C# (a bit verbose at times, but fine)
- V (haven't tried it, but looks really good)
- Swift (haven't tried it (Windows/Linux user, I use Arch btw), but looks decent)
- Go (only better than C by a little margin; really only for microservices)

Yeah, no shit that the 53 year old language is more mature than most languages.

The only reason to use C over all these is for its ABI which has become the standard for platform agnostic FFI.
Even then, languages like Rust and V offer C ABI compatibility OOTB. So using C depends more on who will be maintaining the project (in my case, the code base is going to a NASA subcontractor so using a smaller language doesn't make sense).

(Also, just want to say that I don't get the hype around languages like Zig or Nim; they look annoying to use)

>>106518475
>Rust
kek

File: bot.jpg (19 KB, 428x534)

19 KB JPG

>>106518671
>kek
ahh comment

>>106515866
C is great as long as you are 90th percentile programmer. Most programmers are too retarded to code in C without memory vulnerabilities.

Go will replace C++/Java, not Rust. Rust is too hard and too long to learn for normies.

>>106518711
>Rust is too hard and too long to learn for normies
agreed
how is it any different from other llvm frontends with the same syntax anyway?

>>106518475
>Should have been the default.
yeah, it should have been, but it was made in a time when that assumption could not safely be made so it wasn't until c99

>That doesn't solve anything with build system mess
it solves a lot of it, actually. if you don't need metaprogramming, or external build tools to generate things the final compilation depends on, you can turn the entire project into a single compilation unit, which effectively eliminates the need for build tools like cmake or meson in the first place

>no, how is that simple?
because it also completely eliminates external c build tools as a dependency leaving the only real dependency as the C compiler you need to compiler the code in the first place?

>the biggest pain is trying to use projects that are designed for different build systems as dependencies.
the problem isn't just build systems, it is external dependencies in general. that's really the fault of the developer introducing the complexity of managing additional dependencies and then offloading that complexity on to the end user, but that's a general problem, not just a C one.

>>106518711
>Go will replace C++/Java
lol, Go will replace C++ how? OSDev and bare metal applications won't touch it and gamedev is practically nonexistent. This is pretty much due to how Go's FFI support is terrible.
Java? Maybe. Go could take over Java's share of server applications, but I doubt it will ever take over GUI and Android app development.
>Rust is too hard and too long to learn for normies.
Eh, maybe, but most low-level C++ development is too hard for normies as well.
I could see Rust overtaking C++ in a decade or two (it is already garnering interest at major companies), just because of the tooling (yeah, the memory safety is neat, but who cares when you can wrap everything in shared pointers lol).

>>106516174
Straw man. You only think you need these.

>>106518816
>yeah, it should have been, but it was made in a time when that assumption could not safely be made so it wasn't until c99
It could have: just reverse the way things are done so you write typedefs for different systems using macros if you need it, instead of stdint where it sets typedefs based on the system to be the correct size.

>because it also completely eliminates external c build tools as a dependency leaving the only real dependency as the C compiler you need to compiler the code in the first place?
Surely there's a better solution than writing your own program for building your project?

>the problem isn't just build systems, it is external dependencies in general
Whut? You expect me to avoid external dependencies? Ah, let me just rewrite a hardware accelerated JPEG compressor from scratch.

Meanwhile, I can just call `cargo add turbojpeg` and have it ready to use right away (still needs CMake, a C compiler, and NASM installed, but there's no other setup involved; or I can just add a pure Rust crate like zune-jpeg).

>>106518977
>Surely there's a better solution than writing your own program for building your project?
Sure, but not for something as ancient as C. Odin and Jai eliminate the need for build systems entirely.

>Whut? You expect me to avoid external dependencies?
No, but I do expect you to take them more seriously when you add them to a project and do the work to include them from source directly when possible, bundle the source with the project and statically compile your project with them because the dependency hell we have now is nigger AIDS. If I need a docker container to build your shitty software, it's because you're a nigger.

>Meanwhile, I can just call `cargo add turbojpeg`
Yeah, I'm sure that'll still work in 20, 10 or even 3 years. This is why software sucks and you're too stupid to even realize it.

>>106519067
>Odin and Jai
You jest?

>If I need a docker container to build your shitty software
Bro, who said anything about docker? I just want to be able to state the dependency and fetch it automatically instead of storing a gitmodule or the source code itself in my repo.
>do the work
I would rather do real work and code my business logic instead of doing midwit busywork. Tools exist to do the stuff that can be done by tools.

>Yeah, I'm sure that'll still work in 20, 10 or even 3 years. This is why software sucks and you're too stupid to even realize it.
Since what C has been doing is working so well lol:
"Oh, time to install 32GB of Visual Studio 2013 since the solution file format changed"
"Let me write a 1000 line CMakeLists.txt file to build all my local dependencies. This is meaningful work."
"Time to copy and paste my updated dependencies over to my deps folder. Commit message for all files: Updated version to vX.Y.Z"
Meanwhile, lockfiles and crate editions just work. Software sucks nowadays because people are using scripting languages for writing their backends, using React for native apps, and splitting every task into a microservice/lambda, not because dependencies are being managed by tools.

>>106519323
>Software sucks nowadays
agreed
we should rewrite everything in rust immediately
I'll make the logo and write up a code of conduct, you guys do the rest

>>106519323
>"Oh, time to install 32GB of Visual Studio 2013 since the solution file format changed"
i feel like most of your complaints are about Windows rather than C itself
with WSL idk how much of a point there is in dealing with windows stuff anymore
maybe there's stuff I'm missing, I guess I haven't tried using opengl with C through WSL or things like that yet, but I haven't noticed any problems so far for normal stuff with WSL

>>106519384
>i feel like most of your complaints are about Windows rather than C itself
Well, we are talking about C's tooling rn, which doesn't exist "officially", it's just whatever your vendor has.
So the experience can and will vary depending on what system you are using.
Which is just another reason why development with C can be so painful:
Wrote a CMakeLists.txt that specifies compile flags for MSVC (maybe specifying the runtime library linkage or omit CRT)?
Well, they ain't gonna work on a platform where your choices are GCC or Clang and you have to cross compile, so better edit that file.

In other languages, you usually never worry about touching such things, and even then, the options are cross platform (mostly, in Rust you can specify platform specific options in a config file, for things like custom linkers).

Or just ignore warnings from your C/C++ compiler about the runtime library having a second copy.

>>106519323
>I would rather do real work
One reason software sucks is because you don't think streamlining the build process by properly managing dependencies YOU CHOOSE to use in your project is important or is somehow below you. You think you can just package manage everything away but that's not how you build software that actually lasts. It's how you make a maintenance nightmare for everyone else to deal with. Meanwhile in the same breath that you complain about all of the dependencies you need for your dependencies to work, you somehow ironically fail to see you are also directly contributing to the problem because "cleaning up my shit for the next person? that's not real work, they can go hunt down dependencies". Fuck you, you get everything you deserve.

>"Let me write a 1000 line CMakeLists.txt file to build all my local dependencies. This is meaningful work."
My entire point is you don't need to do that either. Build systems are a mistake. Incremental builds are a mistake. Having a million individual build objects for the linker to resolve is slower than just compiling the entire thing anyway. People are over-complicating solutions to problems that shouldn't even exist in the first place, especially not now.

>"Time to copy and paste my updated dependencies over to my deps folder. Commit message for all files: Updated version to vX.Y.Z"
Yes, faggot. Don't like it, don't include them. You include them, you do the work so the end user doesn't have to tardwrangle your lazy fucking software. If you want your shit to build in 50 years, the only way is to include all of the necessary source code to compile it to begin with. Obviously, it isn't always possible to include everything, especially if you depend on some behemoth, but at least fucking try when you know you can.

File: m1000x1000.jpg (82 KB, 1000x1000)

82 KB JPG

>>106515866
>C is all you need
TinyC