271–280 of 475 posts
Earlier quoted context omitted.
I'm over here with TTS: Underlining in a terminal rarely translates to audio. It isn't the only consideration that needs to be made, when making things clear.
except nobody has to cater to every worst case scenario
Earlier quoted context omitted.
The single best feature (and I would say the _core_ feature separating it from C) that C++ has to offer is RAII and zig does not have that. So I don’t know which good parts of C++ they kept. Zig is more of its own thing, and they take from wherever they like, not just C++.
> So I don’t know which good parts of C++ they kept. comptime is a better version of C++ templates.
The power and expressiveness of the C++ compile-time capabilities are the one thing I strongly miss when using other languages. The amount of safety and conciseness those features enable makes not having them feel like a giant step backward. Honestly, if another systems language had something of similar capability I’d consider switching.
Earlier quoted context omitted.
Rust is not free of trade offs and you're not helping the cause the way you think you are. Just a few off the top: - Rust is a much more complex language than C - Rust has a much, much slower compiler than pretty much any language out there - Rust takes most people far longer to "feel" productive - Rust applications are sometimes (often?) slower than comparable C applications - Rust applications are sometimes (often?…
That's fair, but to me what drags C and C++ really down for me is the difficulty in building them. As I get older I just want to write the code and not mess with makefiles or CMake. I don't want starting a new project to be a "commitment" that requires me to sit down for two hours. For me Rust isn't really competing against unchecked C. It's competing against Java and boy does the JVM suck outside of server deploymen…
.PHONY: all
all:
cc -o progname -std=c99 -pedantic -Wall -Wextra -Wpedantic -O0 *.c
I do agree that the general experience of Rust is a lot better. But I also think a lot of C projects have overcomplicated build systems that aren't really needed.
Despite what some people religiously think about programming languages, imo C was so successful because it is practical. Yes it is unsafe and you can do absurd things. But it also doesn't get in the way of just doing what you want to do.
I don't think C was successful. It still is! What other language from the 70s is still under the top 5 languages? https://www.tiobe.com/tiobe-index/
Earlier quoted context omitted.
> I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. When I say Rust is harder to use (even after learning it decently well), what I mean is that it's still easier to write a pile of C code and get it to compile than it is to write a pile of Rust code…
If you're using VS Code then you can add `"rust-analyzer.check.command": "clippy"` to your `settings.json`. I assume there's a similar setting for rust-analyzer in other editors.
Earlier quoted context omitted.
> Try doing C with a garbage collector ... it's very liberating. > Do `#include ` then just use `GC_malloc()` instead of `malloc()` and never free. Even more liberating (and dangerous!): do not even malloc, just use variable length-arrays: void f(float *y, float *x, int n) { float t[n]; // temporary array, destroyed at the end of scope ... } This style forces you to alloc the memory at the outermost scope where it is…
At first I really liked this idea, but then I realised the size of stack frames is quite limited, isn't it? So this would work for small data but perhaps not big data.
It is easy enough to increase, but it does add friction to using the software as it violates the default stack size limit on most linux installs. Not even sure why stack ulimit is a thing anymore, who cares if the data is on the stack vs the heap?
Try zig, it is C with a bit of polish.
> it is C with a bit of polish. I am fast becoming a Zig zealot. What I've discovered is that while it does regularize some of the syntax of C, the really noticeable thing about Zig is that it feels like C with all the stuff I (and everyone else) always end up building on my own built into the language: various allocators, error types, some basic safety guardrails, and so forth. You can get clever with it if you want…
forth, you say?
I fully understand that sentiment. For several years now, I have also felt the strong urge to develop something in pure C. My main language is C++, but I have noticed over and over again that I really enjoy using the old C libraries - the interfaces are just so simple and basic, there is no fluff. When I develop methods in pure C, I always enjoy that I can concentrate 100% on algorithmic aspects instead of architectu…
About 16 years ago I started working with a tech company that used "C++ as C", meaning they used a C++ compiler but wrote pretty much everything in C, with the exception of using classes, but more like Python data classes, with no polymorphism or inheritance, only composition. Their classes were not to hide, but to encapsulate. Over time, some C++ features were allowed, like lambdas, but in general we wrote data clas…
Earlier quoted context omitted.
At first I really liked this idea, but then I realised the size of stack frames is quite limited, isn't it? So this would work for small data but perhaps not big data.
Yea, usually the stack ulimit is only a few KiB for non-root processes by default on linux. It is easy enough to increase, but it does add friction to using the software as it violates the default stack size limit on most linux installs. Not even sure why stack ulimit is a thing anymore, who cares if the data is on the stack vs the heap?
I'm kinda in the opposite camp. After doing a bunch of VB in my tweens and teens, I learned Java, C, and C++ in college, settling on mostly C for personal and professional projects. I became a core developer of Xfce and worked on that for 5 years. Then I moved into backend development, where I was doing all Java, Scala, and Python. It was... dare I say... easy! Sure, these kinds of languages bring with them other pro…
For Ex: I still has no idea what clone() does, how does it interact with memory, on heap or stack , does it create a new instance, or just modify metadata of that object. Sometime creating a new instance is a big no-no because it takes a lot of memory.
Same thing with "ownership transfer", is variable freed at that moment, etc.
I bet i could find answers on internet, but rust has like 500 std functions, so the task is tedious