New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Sure, there are valid reasons why in 2018 you must choose C - that last few percent of performance, or you're doing something very close to hardware/assembler/etc., or there just happens to be a set of libraries no one has ported.
FORTRAN is still widely used because of that last point...no one wants to go through and rewrite all those hairy scientific libraries written in the 60s.
No, but its scope of applicability has shrunk radically. In the 70s, C was used for everything...today it's niche + legacy.
C's performance edge has also shrunk radically. Even scripting languages suffice for most needs today.
C has some flaws, though, in its core that can't be wrapped. Its for loops are error prone. You have to spend a lot of energy to figure out what you can store in an int. Many of its library functions are deeply flawed (sprintf, fgets, strtok, etc.) yet they stay there for compatibility, luring new programmers to use them. Heck, C doesn't even initialize variables to zero.
C is like a 1950s car. No reason it won't run just fine today, but you'll be safer in a vehicle that has seat belts, airbags, etc. (Even in a crash :-)
If I was writing a mail server today, I wouldn't write it in C.
My personal preference for something server-side is golang, which has all of C's freedom without the dangers, a richer library that is a huge superset of everything libc offers, easy multithreading, and frankly is a joy to code in. Every single flaw I've mentioned about C in this thread is not an issue in golang, though that is true of many other languages, too.
However, I'm not defending golang as the ultimate language or anything. If someone chose C#, erlang, swift, etc. those are also reasonable choices. I guess my main point is that C comes with many trap doors that later languages fixed.
BTW I was a kid in the 80s, too...made some beer money (ok, I was a high schooler...) writing C on the TRS-80.
Wow, i can't even remember pascal having pointers at all but then i probably remember some stone age version and even that memory has mostly faded. The idea of mixing it with C also seems interesting.
Yeah, C is extremly flexible and very good at not getting in the way with the major downside being that it without the slightest complains allows stuff that's only useful like <%1 of the time while being absolutly disatrous or at least extremly bad style otherwise.
I lack the experience to actually judge that but the task of getting C in check being huge just seems logical.
True, i still remember being quite suprised when just a couple years ago i saw people on a rather technical forum actually writing in delphi. I knew it had qutie a bit of following in the late 90s/early 00s but i thought it would have pretty much died off. Seems not and given those guys were probably way better low level programmers than i'll ever be i'd have a hard time calling it uncool but i have to agree somewhat. C programmers have quite a tendency to be snobs and look down on anything that isn't C.
Funny how just skimming it brings up points i like about C, labels them as bad and still i can do nothing but agree with the reasoning behind it.
Sorry, for having misrepresented you. As i said that's not my field and somewhat over my head.
Tbh i've come to just ignore any try at fixing C. It usualy ends up being the worst of both worlds.
Yeah, i guess there was a reason i've never returned to pascal and didn't hop on the delphi train when it was the cool thing to do but as i said at least the possibility of mixing it with C seems insteresting. Not being some kind of fixed C is a pro in my opinion and in any case i have a weak spot for not exactly well liked languages.
Not even that. Those last few percent of performance don' exist anymore in quite some cases. Either they are shrunk to tenths of a % or they don't exist at all.
C isn't inherently faster. It has been faster for mainly 2 reasons, namely a) the compilers were more mature than those of newer languages, and b) no GC - paying dearly elsewhere for that (side note: I'm not a fan of GCs).
Another point is that in many scenarios, particularly with server, The "language performance" is but one of multiple factors. The fast servers aren't fast because they have been written in C (or C++) but they are fast because they've got and done things like IO handling right.
As for libraries, well, most newer languages (the relevant ones anyway) offer a good FFI and binding to C libraries is a breeze.
More of a side note: go's major forté is that it has got CSP right. Looking closer, though, I went away from it because it has kept many weak points of C and offers next to nothing in terms of safety and verification which is a very sad thing in the 21st century. Also the tool chain (while being lauded by fans) is still a bit meager but for a new language that's normal and they seem to work hard to make it richer.
Currently it seems that go (use) has grown very fast while Rust's is growing slower but steadily. I'm not sure that go will be the new language in the longer run.
It won't because it's opinionated. The devs have been very open about their opinions and reasoning, but there are still tons of programmers who must have their pet features.
It's also not sufficiently OOP for a lot of people...there's a large class of programmers who aren't happy unless they're arguing about the intricacies of polymorphism and multiple inheritance like fucking Greek philosophers.
While i largely agree with your points the only reason languages like javascript are viable these days isn't really because scripting languages have become that much faster but rather because with current CPUs the overhead doesn't matter anymore.
Seems like something i might like then. I have no problem with OOP as long as i don't have to write it. It might have it's place in forcing people to adhere to a common set of design principles but to me the line of though behind OOP just feels unnatural.
@raindog308 @mksh
A propos OOP, a side note (or actually maybe a lot more): Both modern Pascal and Ada (albeit with a strange syntax ("tagged")) offer OOP - but do not force it upon developers. However, and that's the important and fun part, both offer a sensible module system and I find myself using objects very rarely thanks to that.
I also mention that because C's non existing module system which was basically taken over by C++ (the dreaded include files) probably was a major driving force for C++' OOP.
Pretty much all the Wirth languages and those with a similar mindset (i.p. Ada) always had at least reasonably good and sometimes even great (e.g. Modula-3, Ada) modularity "built in" from the start.
So, when using these languages, one quite often defines a datatype (typ. a record ("struct")) along with normal procedures and functions which just, if smartly done, offer many of the advantages of OOP without the high price.
Moreover and imo even more important modules also offer much better structured software plus some nice goodies like much better and easier system details handling (providing some functionality that's implemented differently in diverse OSs or even need to be emulated).
And trust me, I know what I'm talking about. As I just have some spare time I'm working on a small tool (i.a. for LET users; maybe I'll even sneak "LET" in its '-v', haha) that'll work on linuxes and BSDs and needing/doing some low level stuff, too, which is done in C (everything else with FreePascal); what a fucking hell with #ifdefs all over the place! (It also reminds me why I strongly dislike linux: they just squarely shit on posix and standards, so pretty much has to be done extra for lisux). Btw, the reason I use C for the low level stuff isn't that Pascal couldn't do it, it could; it's that the FreePascal people unfortunately (well, from my pov) chose to focus more on gui shit and to offer a somewhat poor lib for low level OS stuff.
Damn now I want to try some Pascal. Have not used it since the mid-80s.
There are some fundaments, which ironically are present in C, which are very useful:
That's about 99% of what I want from OOP.
Yeah, the lack of a standartized module system really hurts C. Pretty much any library no matter how good uses a different coding style. Technically that might not sound to bad but the more libraries are involved in a project the more it starts looking like a non uniform mess which seriously hurts readability and thereby the overall quality quite a bit. Actually having written wrappers that do nothing but hide the stylistic differences of various libraries is a pretty sad thing to admit imo.
Spot on. It always baffles when people act like OOP is some kind of unique aproach when it really is nothing but a glorified structure pointer transparently passed to every member function. Doing OOP in a procedural language is no big thing as long as defining a struct is possible. The other way around it's often way less straight forward and let's face it there's cases where (and i think i can say that without bias) objects just aren't a good solution.
Just install freepascal. Most distros have it in their repos (package is usually called "fpc"). If you want an IDE too have a look at Lazarus.
many other languages (i.a. all the algol/Wirth languages). Some even have discriminated records ("variants of records").
like in most compiled languages.
That's half a lie. In C whatever you put into a header file is exposed and there is no differentiation whatsoever (unlike C++ which offer private, protected, public). Pretty much all algol/Wirth (and many other) languages have way more elaborate module systems.
Sorry, my last bullet was incorrect. What I was actually thinking about were object private variables/methods (“encapsulation”) which C doesn’t offer.
Yeah, keywords aside you could pretty much just write C as long as you'd explicitly pass the "this" pointer which in turn would likely drastically reduce the use of function pointers since in a lot of cases it would become superflous to have them on a struct that gets passed to the function anyways.
Declaring stuff static is admittedly not the best substitute for the various levels of public/private OOP languages tend to have so a bit of voluntarily self restraint is needed here. Add consistent naming scheme and you basically have a poor mans OOP implementation.
Funnily enough quite a bit of my code looks just like this even if i've never thought about OOP while writing it. Not sure how to best describe the unnatural feeling i get with traditional OOP. I guess it's related to the coupling of code and data which sometimes is just a poor abstraction since ocationaly there simply isn't any connection or it just doesn't feel strong enough to warrant said coupling.
Also the OOP style grouping somehow feels to me like going at the problem backwards but i guess it might be related to my brain being trained to think in procedures rather than objects. Still procedural programming will always be more near to the actual hardware since CPUs are procedural by nature (is there any exceptions?).
Edit: Not ment as an attack obviously. If OOP works for you that's great. It just isn't my cup of tea.
Functional programming is very hip right now, so you’re in a good spot.
I think the comments here were mostly off by one too ;-)
But hey, this is LET where the talking can be low end as well, lol.
This discussion reminded me of this post by ESR:
"The long goodbye to C"
http://esr.ibiblio.org/?p=7711
I'm sorry, but this is PR, not a security issue. Very simple and typical bug which is increased in million times just to get some hype and better portfolio. There is dozen of million projects with much worst issues out the box, and what? Why is no one talking about them? Because better to hit systems which are well known by everyone. Nothing interesting.
Since when are CVE not security issues anymore? I guess you have updated your software for the last time years ago because all those CVE are not really security issues in your opinion. I wish you good luck because you'll need it.
When you remove the walls of text you'll see raindog suggested golang as a potential alernative, if C is not appropriate for coding MTAs.
What I meant was that this discussion was originally about updating Exim because of a security issue.
Yeah indeed, I knew what you meant. I was also meaning a lot of it was surplus to requirements.
Well, tbh i regret taking the time to read all of that. I mean sure there a lot more viable alternatives to C today than there was 20 years ago and often it's more practical to use them than go to C. Not much of a suprise there and the attempt to draw paralells to COBOL is pretty forced and cringeworthy imo.
Beyond that the author loses me pretty quickly as it seems he has no real preference for anything. If it wasn't for python he would have started to write java. Uhh, ok? In the end he praises Go/Rust for having GCs. Is there anything this guy ever liked about C or was he just forced to write it by the circumstances? Seems it's the latter if you ask me...
@ricardo it occurred to me that the last major MTA released was written in...C :-)
https://en.m.wikipedia.org/wiki/OpenSMTPD
Though this probably has mainly to do with that project’s environment and culture than an objective (no pun intended!) choice.
Despite written in C, OpenSMTPD is actually a great piece of software. It is really easy to configure, preventing common mistakes.
If you want to use OpenSMTPD with Rspamd, you'll find this useful: https://gist.github.com/M66B/e8757f8bab1dfd4cc609c2f91b7db8d4
Silly people, making the same mistakes over and over :-) Still, golang is relatively young at 8 years old... C at 50 has had a lot of years for people to pick it up.
The SMTP server currently used by Guerrilla Mail (a disposable email service) is written in Go for performance reason. They claim to processes millions of emails every day.
https://github.com/flashmob/go-guerrilla
Before that, they had written another SMTP server in PHP, when exim failed to cope with their inbound mail flow.
https://github.com/TwixtedChaox/Guerrilla-SMTPd
So Go is faster than PHP? Such suprise. Such wow.
It also has a built-in webserver!
Stop bringing up systemd.
While I have relatively little PERSONAL use for Go- that's just mean.
The OpenBSD guys will always stick with C - and reasonably so. One doesn't throw away a time-tested team of high quality and hundreds of man years of experience unless one is forced to.
But then, our problem isn't in the upper 3% of C developers, it's in the lower 85% of C developers who reliably produce a never ending stream of bugs and vulnerabilities.
As for the newer languages the problem is (im)maturity, tool chains, and code bodies. I've seen enough de principe interesting languages with their wiki saying something like this re. tool support "A has written emacs support and B is working on sublime [or textmate or atom or ...] support. There is no debugger support so far but we have a nice trace macro" and those are the better cases.