tammerk

I can't find in documents but does multi-threading effect consistency somehow? Is there a chance that I wouldn't read what I just wrote? I'm talking about single node, not about replication, cluster etc.

If it provides same consistency, is threading like :

sock_read();

lock(datastructures);

set x=3;

unlock(datastructures);

sock_write();

Difference between Go and Java, Java drives developers to write bloated code. Bunch of abstract classes, interfaces, fancy inheritance, getters/setters, OOP patterns, classes for anything and everything .. all in a different file. Normally, some code can fit in a single file, a logic can be a method but Java way of doing it in 20 files, 20 classes, 3 sub-classes, 3 interface implementations. I think this is the boilerplate that matters most.

I think Go will not ever be as bad as Enterprise Java because language and community culture which is shaped by language, don't give you as much opportunity to abuse it. If Go gets some new features that may enable abusing it, then yeah, history will repeat :)

Literally author is asking for something in the cloud which is abstracted away, fast, easy to use and easy to debug. This is not possible imho. There are always trade-offs. You can't get all of them for "free". e.g serverless services will be slower than your own setup, like always. Debugging, I'm not sure but I don't think it will be as easier as your own setup ever.

I agree but I didn't consider these while saying C is the fastest. These are not "general purpose", like you don't write your db, browser, http server or game engine with these.

I didn't mean C is not fast or not faster than other languages. It's still the fastest one I believe.

What I meant is undefined behaviors allow compilers to optimize in a way that would not be possible otherwise. So, it might be a deliberate decision back then, to leverage performance. I don't know, just an idea.

Nowadays, it doesn't provide any performance gain. I didn't see those days but maybe it was important for performance back in 70s/80s/90s even it was risky? e.g null terminated string was chosen due to low space overhead.

It's more funnier that although language is full of traps, in practice it works quite well. I don't think any C developer(or let's say %95) knows all the rules mentioned in the article, yet we are still one piece.

Does anybody know any paper for bugs per lines of code for different languages or something similar?

We'll see if they are going to prevent this.

This is way beyond being "controversial". First thing probably, HN team can investigate all China related posts and gather users who flagged these posts and take action accordingly.

There are no hidden calls, mostly there is one way to do something. No exceptions, so you can see entrance and exit points of a function. There is no "abstraction" feature, so you tend to keep your code away from unnecessary abstractions.

You can find counter-examples ofcourse, bad programmers can create a mess from anything and everything.

My question is, as an example, how come Linux kernel's code ,nginx's code or memcached's code 100 times more readable than any other project in another "better" language.

This is why people say C is simple. You have limited options and you tend to end up with a "simple, readable" solution.

No one says "C is perfect, you should use it for anything and everything, it handles all the issues of computers, no gotchas, no surprises, 3 year old kids should start with C programming."