Definitely something to be championed, although I suspect this is a matter of perspective. I find Python packages to have refreshingly few dependencies compared to packages in the JS ecosystem, although compared to the Swift ecosystem which I’m somewhat familiar with, they do tend to have a few more.
I appreciate your perspective! It's interesting to consider how the built-in libraries of a language can influence its ecosystem. Python does have a rich standard library that often reduces the need for external dependencies. In contrast, JavaScript's ecosystem has evolved around web development, where modularity and flexibility are prioritized, leading to a proliferation of packages.
One of the most commonly cited drawbacks about C (limited standard library and package management) is something I’ve grown to enjoy when working in a well-loved C codebase.
Instead of learning and working with bloated tool chains, every tool in the repo has been built or added carefully for the task at hand. Simplicity provides a lot benefits over time.
Even though I love 3rd party tools (SDL my beloved) I still find novel uses in the C library. Especially for string-related problems people say "just do it from first principles". Sometimes snprintf is enough for my debugging!
Maybe I'm missing something, but what is painful to set up with C toolchains? On almost every *nix, (g)cc, vi(m) and make are enough to be dangerously productive. Sure, you can overcomplicate stuff with modern IDEs and IDE-like tools, but that is out of the realm of the usual C toolchain.
Are you really putting make and CMake in the same bag? POSIX make and Plan 9 mk are incredibly simple, compared to autotools/CMake; even BSD/GNU make, with all their extensions, are quite simple.
Personally, after having gone through a lot (GNU make, sh script + POSIX make, CMake + conan at work), I think a simple POSIX 2024 make + pkgconf(ig) really is enough for simple programs; and Windows devs can use WSL or whatever.
Dependency management in C is the hell that you and your dependency make it, alone. You can try to copy a .a file and a directory of headers into your project, or you can try to make a massive graph of 1000 dependencies that needs a SAT solver to untangle.
Dependencies are hell in JavaScript, Haskell, and Python too, but you don't notice because the computer works through the most common hells automatically... so developers don't hesitate to create hells. In C, they hesitate.
i've started building my C projects with zig, it works quite nicely and has decent support for pulling in C dependencies as well (e.g., https://github.com/allyourcodebase/libxml2)
As in SIGSEGV dangerous? C is a language so simple that together with the lack of libraries it'll drag you down to problems you were not going to stumble into in most alternatives.
Sure, eventually you'll get your own scars and learn the hard way lessons that will stick and give you better intuition on how things work, but I don't feel there's need to keep using C these days beyond learning and doing specific low level stuff.
This reads remarkably tongue-in-cheek, especially when combined with the "dangerously productive" remark a bit later, but: navigating the maze that is picking a C runtime, a libc implementation, a compiler or potentially compiler frontend and backend, a linker, a build tool, a dependency manager, and then figuring out the linking, figuring out the dependency management, figuring out the building process, tackling version control crap (setting up submodules) if needed, then rinse repeat for every single project ever. And if you're targeting not just *nix, but also platforms people actually use (Windows), then this gets especially nasty.
Not your project? Well then you get the chance of taking a deep dive into a random assortment of these, taking up however much of your time. Or you'll just try building it and squash errors as they come. Such a great and sane toolchain and workflow.
All of this is of course completely excluding the very real factor of even knowing about these things, since being even slightly confused about this stuff is an immediate ticket to hours of research on various internet forums to even get to know what it is that you don't know - provided you don't just get sick of all this crap and move on to some other toolchain instead, or start the rote reproduction of some random dood's shitty guide, with the usual outcomes.
> navigating the maze that is picking a C runtime, a libc implementation, a compiler or potentially compiler frontend and backend, a linker, a build tool, a dependency manager, and then figuring out the linking, figuring out the dependency management, figuring out the building process,
You're misrepresenting this somewhat: all but two of those items listed need you to only "pick" a compiler and (as parent said) use Make.
The dependency manager is a problem yes, but lets not misrepresent everything.
It comes up more when you try stuff multiplatform.
Another thing I didn't touch on is the massive compatibility tables for language features one needs to look out for, in case they plan to make their code work on multiple mainstream compilers, which is arguably the prudent thing to do.
I really don't think that considering the C/C++ build story as complex and frustrating would be misrepresentative.
> I really don't think that considering the C/C++ build story as complex and frustrating would be misrepresentative.
Who was talking about C++? This thread was about C, right?
(It's possible that I didn't read very closely upthread, but I'm almost certain that we were all talking about C).
I actually agree that C++ can be a pain in the rear, especially for multiplatform, and you have to pick all your options, etc.
But C? Not so much. Even on multi-platform.
As GP (or GGP, or GGGP, I forget how far upthread it is) said, with C all you need is a compiler, an editor and Make. That's pretty much still true, even if you're using third party libraries.
The compilers require a bunch of arcane flags to actually do something useful, so you pretty much need some kind of build system or at least a shell script.
I have been a Gentoo Linux aficionado for decades. When you set it up you define a set of CFLAGs and CXXFLAGS etc. Those are your globals, your defaults.
I am also a human. When I deal with another person I have never met before, I have a set of defaults. I override them as required.
gcc (at least) only requires an input and will behave reasonably and generate: a.out.
You might like to pass -O2 for something a bit more complicated. Beyond that then yes you will need to get into details because any engineering discipline is tricksy!
> Beyond that then yes you will need to get into details because any engineering discipline is tricksy!
When you have multiple files in your project or are using external libraries, pretty much any other programming language will know what tt do. Only C requires you to manually name them in the compilation command even though they’re already named in the file you’re compiling.
Why is the executable named ./a.out and not ./lolno? Why are warnings disabled by default? What if you need to use <math.h>? And that’s just for a single file.
It's 155,000 lines of C code across 361 files. Not shown are the nearly 900 lines that make up the dependencies, but using `makedepend` (which came with my system) makes short work of that. I have a more complicated project that compiles an application written in Lua into a Linux executable. It wasn't hard to write, given that you can always add new rules to `make`, such as converting a `.lua` file to a `.o` file:
That still doesn't require any flags. Where it starts to get complicated is when you link in system libraries, because they vary between OSes and different versions/distros of the same OS. If you need to support multiple platforms this quickly becomes combinatorially complex, which is where Makefile hell comes from.
Use stunnel for TLS. A benefit is that if you properly sandbox the daemon behind it, a compromise in the daemon behind TLS does not result in the server key being compromised.
A GUI could be done in SDL+Nuklear, GTK+ or others.
Database access from C is easy, since the databases are written in C and provide C APIs for access.
You're not wrong, but you're closer to wrong than right. C toolchains are the best of a collection of rather sucky things.
I can compile all sorts of things on my Mac LC III+ with 36 megabytes of memory. Sure, Perl takes nine days, but it works. What other language can actually be used on a machine with such little memory?
Cmd and powershell exist and have done for a long time. There was a period of time where the visual C++ compiler was bundled with the IDE but it’s been available separately for the best part of a decade. Various incarnations of gnu-on-windows have existed for longer than that - Msys/cygwin/wsl are all feasible options and have been for ages.
I've never had problems with make versions specifically. Usually the project requires distro at most X years old because of gcc/clang version or shared library version. By the time you solve those, your make is new enough as well.
I mean yeah if all you're using is Linux then the issues with buggy versions of GNU make is something you've probably not seen in a while. Apple is still on 3.81 due to GPLv3 which means bugs. None of the BSDs ship with GNU make in the base system, and I believe they all install it at gmake (which means you've gotta be careful about hardcoding calls to make.
The pain in doing so and the very real chance you're trying to do something that can't be done in a portable manner is why things like cmake (and every other build system under the sun) exist.
Couldn’t agree more. Vcpkg + CMake doesn’t come close to the convenience of NuGet + MSBuild. The latter Just Works every time. You can’t say the same about C.
LLVM is a bit easier to set up in my experience. One of the most irritating things about setting up a GNU toolchain is the hard dependency on texinfo (which has been dropped in later versions I think).
A good heuristic test of correlation vs causation in headlines: flip the dependent and independent variable and see which explanation sounds more reasonable.
Heavy llm chat usage leads to loneliness | or | Loneliness leads to heavy chat usage.
To my eye the second seems far more likely than the first.
Many (if not most) human dynamics do not have a single direction of causality.
The whole premise of cognitive behavioral therapy is that human psychology can be described as nested feedback loops between behavior, emotion, and cognition.
The lack of a single direction is a really good point. In my mind I was thinking more from the perspective of tempering evocative headlines. But my rule also lacks quite a bit of nuance
The headline is hardly evocative. It states a fact found by the researchers that there is a correlation. That one causes the other is a conclusion drawn by the reader.
Correlation vs. causation is addressed in the article:
Note that these studies aren’t suggesting that heavy ChatGPT usage directly causes loneliness. Rather, it suggests that lonely people are more likely to seek emotional bonds with bots — just as an earlier generation of research suggested that lonelier people spend more time on social media.
My heuristic for HN is that when commenters focus on the headline, they almost never have actually read the article they are commenting on ;)
Reasonable perspective. I went back through the article and the content is more balanced than I initially would have guessed from the initial visualizations.
However, the much more assertive initial visualizations and the opening caption— “A chart illustrates that the longer people spend with ChatGPT, the likelier they are to report feelings of loneliness and other mental health risks” — convinced me not to continue reading.
I don't think correlation vs causation is the right question. Loneliness was clearly rampant long before chatgpt showed up. The question is whether chatbots are capable of reducing people's loneliness. To me it feels self-evident that in the long run, they are far more likely to increase feelings of loneliness than reduce them.
For me, the only thing that can reduce loneliness is conversation with another conscious entity. Many, if not most, people are barely conscious so this is hard to find in the physical world. But I don't believe llms are conscious, so for me they are a complete dead end for reducing loneliness whatever other virtues the may have.
I really appreciate the author posting their experience.
Just to add a little bit of my own experience. I had debilitating nerve pain as a result of surgery complications to the point where I could walk for a bit over a year.
It’s easy to fall into the trap of running from discomfort and making yourself more and more brittle in the process. At the same time it’s really easy to want to skip a few steps and try to jump back into the intensity level you are accustomed to. I think this even applies to coding. Before my surgeries, I could work for several hours straight and feel physically fine. Nowadays if I am physically static for such a long time, my nerve pain will come roaring back.
My main takeaways through all this are two relatively standard words of advice: “Movement is medicine” and that balance is key. Swimming, Pilates, yoga and build up towards more movement heavy lifestyle slowly got me to the point of walking and now being able to do 80% of what I once was able to again, but this time in a more sustainable way.
I don’t know if this counts as tiny but I use llama 3B in prod for summarization (kinda).
Its effective context window is pretty small but I have a much more robust statistical model that handles thematic extraction. The llm is essentially just rewriting ~5-10 sentences into a single paragraph.
I’ve found the less you need the language model to actually do, the less the size/quality of the model actually matters.
^ This perfectly encapsulates the story I see every time someone digs into the details of any llm generated or assisted content that has any level of complexity.
Great on the surface but lacks any depth, cohesive, or substance
> The language model predicts the probabilities of the next token. An arithmetic coder then encodes the next token according to the probabilities. [1]
It’s also mentioned that the model is configured to be deterministic, which is how I would guess the decompression is able to map a set of token likelihoods to the original token?
isn’t a LLM itself basically a compression of the texts from the internet? you can download the model and decompress the (larger) content with compute power (lossy)
Yeah that’s exactly how I think of llms in my head: lossy compression that interpolates in order to fill in gaps. Hallucination is simply interpolation error. Which is guaranteed in lossy compression.
I love the idea of the semantic web at a high level. Forgetting the technical challenges, I just struggle to picture what it would look like in practice.
Let’s say I follow a few pharma news sites and the nba. What would the idealized semantic web offer in terms of either discovery or browsing experience?
I don’t follow pharma news closely, but one thing semantic technology excels at is bridging gaps between sites with related information. Instead of links operating at the page level, semantics allow connections to form at the data level.
For instance, if you’re reading an interesting article and a specific topic or quote stands out, the site could trivially suggest links to related articles, even from other periodicals. Semantic connections are also highly flexible, making it possible to uncover surprising links—like connections between trends in pharma and the NBA.
The original post's main idea was about building a personal semantic web that works with your own data. This could enable powerful tools, like universal search. Imagine being able to search, "Find all documents about medical science I’ve read while at the library," and getting an accurate result. The potential for personalized knowledge management is immense.
The open source support and QuickStart are excellent. The engineering work put into the system is very noticeable!
reply