HN isn't a judge of software; it's a place to learn and be curious. So people are often interested in projects that do a novel thing in a normal way, or a normal thing in a novel way. Eg, stories fascinate us because something was built by a very lean team, or a group with no money, or somebody who is an industry outsider, or a parapalegic, etc. Overcoming these limitations is a sort of 'hacking'.
There is a new trend in Silicon Valley of bragging about how young founders are, etc. along with the rather bizarre trend of bragging about dropping out of high school to "found a startup".
Totally agree. Even if I'm a teen myself I never post my age unless someone asks explicitly. Saying your age is just trying to find excuses to justify a sub-par software imo (Not saying this project is sub-par)
A competent developer would be more likely to send a PR using the tool with zero friction than to dedicate a few additional hours of his life to create an account and figure out how to use some obscure.
You are making the same mistake of conflating competence and (lack of) dedication.
Most likely, dedication says little about competence, and vice versa. If you do not want to use the tools available to get something done and rather not do the task instead, what does that say about your competence?
I'm not in a position to know or judge this, but I could see how dedication could be a useful proxy for the expected quality a PR and the interaction that will go with it, which could be useful for popular open source projects. Not saying that's necessarily true, just that it's worth considering some maintainers might have anecdotal experiences along that line.
This attitude sucks and is pretty close to just being flame bait. There are all kinds of developer who would have no reason to ever have come across it.
A competent developer should be aware of the tools of the trade.
I'm not saying a competent developer should be proficient in using gerrit, but they should know that it isn't an obscure tool - it's a google-sponsored project handling millions of lines of code internally in google and externally. It's like calling golang an obscure language when all you ever did is java or typescript.
It’s silly to assume that someone isn’t competent just because you know about a tool that they don’t know about. The inverse is almost certainly also true.
Is there some kind of Google-centrism at work here? Most devs don’t work at Google or contribute to Google projects, so there is no reason for them to know anything about Gerrit.
> Most devs don’t work at Google or contribute to Google projects, so there is no reason for them to know anything about Gerrit.
Most devs have never worked on Solaris, but if I ask you about solaris and you don't even know what it is, that's a bad sign for how competent a developer you are.
Most devs have never used prolog or haskell or smalltalk seriously, but if they don't know what they are, that means they don't have curiosity about programming language paradigms, and that's a bad sign.
Most competent professional developers do code review and will run into issues with their code review tooling, and so they'll have some curiosity and look into what's out there.
There's no reason for most developers to know random trivia outside of their area of expertise "what compression format does png use by default", but text editors and code review software are fundamental developer tools, so fundamental that every competent developer I know has enough curiosity to know what's out there. Same for programming languages, shells, and operating systems.
These are all ridiculous shibboleths. I know what Solaris is because I’m an old fart. I’ve never used it nor needed to know anything about it. I’d be just as (in)competent if I’d never heard of it.
Exactly. Let's invent a word for "installing from play store". Playstoring?
So we can rewrite the story to something like: Google wants to prohibit app installation on Android phones. The only way to get an app would be through playstoring.
Funny, I just asked "Ask Brave", which uses a cheap LLM connected directly to its search engine, and it got it right without any issues.
It shows once again that for common searches, (indexed) data is the king, and that's where I expect that even a simple LLM directly connected to a huge indexed dataset would win against much more sophisticated LLMs that have to use agents for searching.
It's an example of what a responsible local government working in the interest of the local community could achieve.
No wonder that the federal government did all they could to shut down this experiment. It was too dangerous to have an example of actually functional governance.
Nice toy. It works until it stops working. An experienced C developer would quickly find a bunch of corner cases where this just doesn't work.
Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?
It's just, I'd rather play with my own toys instead of using someone else's toy. Especially since I don't think it would ever grow up to be something more than a toy.
For serious work, I'd use some widely used, well-maintained, and battle-tested library instead of my or someone else's toy.
Yeah, kids like to waste time to make C more safe or bring C++ features.
If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases.
If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return.
Temporary buffers? if they arent big, dont be afraid to use static char buf[64];
No need to waste time for malloc() and free. They are big? preallocate early and reallocate or work on chunk sizes. Simple and effective.
No, because I did NOT do serious analisis of this. Nor I care, ask upper commenter.. C have some corner case and undefined behaviours and this stuff will make it worse IMO.
My thoughts as well. The only thing I would be willing to use is the macro definition for __attribute__, but that is trivial. I use C, because I want manual memory handling, if I wouldn't want that I would use another language. And now I don't make copies when I want to have read access to some things, that is simply not at a problem. You simply pass non-owning pointers around.
In a function? That makes the function not-threadsafe and the function itself stateful. There are places, where you want this, but I would refrain from doing that in the general case.
It also has different behaviour in a single thread. This can be what you want though, but I would prefer it to pass that context as a parameter instead of having it in a hidden static variable.
What different behaviour you mean? static in function means that this is just preallocated somewhere in data, not on stack nor heap. Thats it. Yes, its not thread safe so should never be used in libraries for any buffering.
But in program, its not bad. If I ever need multiple calls to it in same thread:
static char buf[8][32];
static int z;
char *p=buf[z];
z=(z+1)&7;
Static foremost means that the value is preserved from the last function invocation. This is very different behaviour, than an automatically allocated variable. So calling a function with a static variable isn't idempotent, even when all global variables are the same.
> If I ever need multiple calls to it in same thread:
What is this code supposed to do???? It hands out a different pointer, the first 8 times, than starts from the beginning again? I don't see what this is useful for!
If you want to return some precalculated stuff w/o using malloc() free(). So you just have 8 preallocated buffers and you rotate them between calls. Of course you need to be aware that results have short lifetime.
That sounds like a maintenance nightmare to me. If you insist on static, I would at least only use one buffer, to make it predictable, but personally I would just let the caller pass a pointer, where I can put the data.
What application is that for? Embedded, GUI program, server, ...?
it is very predicatable.. Every call it returns buffer, after 8 calls it wraps.
I use such stuff in many places.. GUI programs.. daemons.. Most stuff are single threaded. If threads are used, they are really decupled from each other.
Yes, you should never ever use it in Library.. But small utility functions should be okish :)
This is example from my Ruby graph library. GetMouseEvent can be called alot, but I need at most 2 results. Its Ruby, so I can either dynamicaly allocate objects and let GC pickup them later, or just use static stuff here, no GC overhead. it can be called 100s of times per second, so its worth it.
static GrMouseEvent evs[8];
static int z=0;
GrMouseEvent *ev=&evs[z];
God forbid we should make it easier to maintain the existing enormous C code base we’re saddled with, or give devs new optional ways to avoid specific footguns.
Goofy platform specific cleanup and smart pointer macros published in a brand new library would almost certainly not fly in almost any "existing enormous C code base". Also the industry has had a "new optional ways to avoid specific footguns" for decades, it's called using a memory safe language with a C ffi.
I meant the collective bulk of legacy C code running the world that we can’t just rewrite in Rust in a finite and reasonable amount of time (however much I’d be all on board with that if we could).
There are a million internal C apps that have to be tended and maintained, and I’m glad to see people giving those devs options. Yeah, I wish we (collectively) could just switch to something else. Until then, yay for easier upgrade alternatives!
I was also, in fact, referring to the bulk of legacy code bases that can't just be fully rewritten. Almost all good engineering is done incrementally, including the adoption of something like safe_c.h (I can hardly fathom the insanity of trying to migrate a million LOC+ of C to that library in a single go). I'm arguing that engineering effort would be better spent refactoring and rewriting the application in a fully safe language one small piece at a time.
I’m not sure I agree with that, especially if there were easy wins that could make the world less fragile with a much smaller intermediate effort, eg with something like FilC.
I wholeheartedly agree that a future of not-C is a much better long term goal than one of improved-C.
A simple pointer ownership model can achieve temporal memory safety, but I think to be convenient to use we may need lifetimes. I see no reason this could not be added to C.
Would be awesome if someone did a study to see if it's actually achievable... Cyclone's approach was certainly not enough, and I think some sort of generics or a Hindley-Milner type system might be required to get it to work, otherwise lifetimes would become completely unusable.
C does have the concept of lifetimes. There is just no syntax to specify it, so it is generally described along all the other semantic details of the API. And no it is not the same as for Rust, which causes clashes with the Rust people.
I think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.
One of them was a maintainer of that particular subsystem, but that doesn't mean that the other folks aren't also maintainers of other parts of the kernel.
> Complexity for the sake of complexity is not a goal everyone should be striving for.
THIS !
Go's well maintained stdlib just lets me get on with it.
With Rust meanwhile, I have to decide which of thousands of third-party Rust crates is sufficiently en-vogue and well maintained.
Most of my coding work is backend stuff that calls a lot of HTTP APIs, parses a lot of JSON and does a lot of crypto. All that is ready-to-go "out of the box" with Go stdlib and on top of that is faster to get to production in Go than in Rust.
I don't need or want Rust's complexity. As I said I have enough going on at $work...
We should judge software by the quality, not by authors age.
reply