5 ms·

Why the hell would you write this in C, when so many other programming languages exist now. I mean, you could write a time sync program in Python today. But if

by zanny 12y ago

Why the hell would you write this in C, when so many other programming languages exist now. I mean, you could write a time sync program in Python today. But if you still want to be maximally performant since you intend to run on millions of computers, Go and Rust are new and fresh and memory safe, and modern C++ is great too. A lot better than malloc and pointer arithmetic. I get that the original ntpd is almost 20 years old, and opentpd is about a decade old, and back then writing every in C was forgivable, because the alternates were not as far ahead in every metric possible as they are today. Now it just looks like someone trying to use Cobol or Fortran in new production products.

kolev 12y ago
I think Rust should be the default choice from projects like this going forward.
- perlgeek 12y ago
  While I agree with the motivation behind your statement, I don't think Rust has proven itself yet to the degree that it should be a default choice for anything. Remember that compilers and runtime libraries can have bugs too, and new ones tend to have more bugs than those maintained over some time.
  - kolev 12y ago
    Yes, runtimes and libraries can have bugs, too, agreed, but at least you will have to just recompile with the patched version vs having to fix and test your code as fast as possible. It's more efficient as well as fixing the core will benefit many (well, of course, that would have compromised many as well... to start with).
- ta0967 12y ago
  you should publish a Rust version of Ntimed, then its advantages would be obvious and nobody would touch C again. while i'm here, compare the tone of your comment with that of the following (lifted from somebody's comment in another HN thread): Personally I wish this was done with $otherlang.. But then again I'm not writing it myself, so I can't really complain.
justcommenting 12y ago
it's easy to criticize someone's choice of language or coding style with generalities--and i don't necessarily even disagree with the substance of your criticism--but it's also important to note that building free software for freedom is much, much harder than any two-paragraph comment you or i might write. imperfect as it may be, i'm grateful that phk was willing to build something that people can freely choose while contributing mutual aid and solidarity to the free software community--instead of snark.
flogic 12y ago
Yeah. I think we've hit the point where we need to start discouraging the proliferation of C and C++ (in my opinion). It seems silly that we cling to languages from the 80's and earlier when modern languages have advanced so far.
- zanny 12y ago
  I'm not saying a language must die because its old. Modern C++ is not bad - but you have to restrict your development into the "good" subset, and avoid the bad stuff from before. IE, use references and smart pointers rather than news and deletes. With C, there is no alternative. It is still malloc and free, still buffer overflows and integer overflows galore, and the C language standards group is not moving to make the kinds of radical changes to modernize it the C++ one is.
  - flogic 12y ago
    I'm not going to pass myself off as a C++ expert. That said, I think it's very telling that we haven't had an unsuccessful pwn2own yet.
    - zanny 12y ago
      And most C++ is written insecurely and poorly, especially since good C++ is literally a new invention in the last three years. It is why Rust and Go are better in general, because they force you to be safe, whereas C++ gives you all the tools you want to stab yourself in the foot in the same toolbox as all the stuff that makes sense.
panic 12y ago
Are you speaking from experience writing system components in these languages? Lots of very high-quality software is written in C. Go and especially Rust are still moving targets. Depending on a separate compiler or runtime can hinder adoption and introduce errors when versions are out of sync.
- zanny 12y ago
  Yes, I am. I have worked on pulseaudio and gstreamer in the past (because of fundamentally broken parts I had to patch and merge upstream to get it to work) and GObject or just no type system at all is a nightmare in a huge project. I'm also contributing to frameworks 5 from KDE, and those libraries are a hell of a lot saner and they are still using Qt functions over std ones that have arisen in the last three years with better syntax, but it sure as hell beats having to spend days manually tracing all your allocations and having to write out every version of a function by hand because you can't template anything. > separate compiler Go has its own compiler and runtime, yeah. Rust compiles to strict native and uses LLVM. C++ uses the same compilers as C (GCC, etc). In any case, both Rust and C++ can be distributed as final binaries with no runtime dependencies besides potentially dynamically linked Rust std libs (libgreen, etc) and a C++ stdlib. Feel free to bundle those, in the same way you would have to bundle or trust the end users libc implementation.

by zanny 12y ago

kolev 12y ago

I think Rust should be the default choice from projects like this going forward.

perlgeek 12y ago
While I agree with the motivation behind your statement, I don't think Rust has proven itself yet to the degree that it should be a default choice for anything. Remember that compilers and runtime libraries can have bugs too, and new ones tend to have more bugs than those maintained over some time.
- kolev 12y ago
  Yes, runtimes and libraries can have bugs, too, agreed, but at least you will have to just recompile with the patched version vs having to fix and test your code as fast as possible. It's more efficient as well as fixing the core will benefit many (well, of course, that would have compromised many as well... to start with).
ta0967 12y ago
you should publish a Rust version of Ntimed, then its advantages would be obvious and nobody would touch C again. while i'm here, compare the tone of your comment with that of the following (lifted from somebody's comment in another HN thread): Personally I wish this was done with $otherlang.. But then again I'm not writing it myself, so I can't really complain.

justcommenting 12y ago

it's easy to criticize someone's choice of language or coding style with generalities--and i don't necessarily even disagree with the substance of your criticism--but it's also important to note that building free software for freedom is much, much harder than any two-paragraph comment you or i might write. imperfect as it may be, i'm grateful that phk was willing to build something that people can freely choose while contributing mutual aid and solidarity to the free software community--instead of snark.

flogic 12y ago

Yeah. I think we've hit the point where we need to start discouraging the proliferation of C and C++ (in my opinion). It seems silly that we cling to languages from the 80's and earlier when modern languages have advanced so far.

zanny 12y ago
I'm not saying a language must die because its old. Modern C++ is not bad - but you have to restrict your development into the "good" subset, and avoid the bad stuff from before. IE, use references and smart pointers rather than news and deletes. With C, there is no alternative. It is still malloc and free, still buffer overflows and integer overflows galore, and the C language standards group is not moving to make the kinds of radical changes to modernize it the C++ one is.
- flogic 12y ago
  I'm not going to pass myself off as a C++ expert. That said, I think it's very telling that we haven't had an unsuccessful pwn2own yet.
  - zanny 12y ago
    And most C++ is written insecurely and poorly, especially since good C++ is literally a new invention in the last three years. It is why Rust and Go are better in general, because they force you to be safe, whereas C++ gives you all the tools you want to stab yourself in the foot in the same toolbox as all the stuff that makes sense.

panic 12y ago

Are you speaking from experience writing system components in these languages? Lots of very high-quality software is written in C. Go and especially Rust are still moving targets. Depending on a separate compiler or runtime can hinder adoption and introduce errors when versions are out of sync.

zanny 12y ago
Yes, I am. I have worked on pulseaudio and gstreamer in the past (because of fundamentally broken parts I had to patch and merge upstream to get it to work) and GObject or just no type system at all is a nightmare in a huge project. I'm also contributing to frameworks 5 from KDE, and those libraries are a hell of a lot saner and they are still using Qt functions over std ones that have arisen in the last three years with better syntax, but it sure as hell beats having to spend days manually tracing all your allocations and having to write out every version of a function by hand because you can't template anything. > separate compiler Go has its own compiler and runtime, yeah. Rust compiles to strict native and uses LLVM. C++ uses the same compilers as C (GCC, etc). In any case, both Rust and C++ can be distributed as final binaries with no runtime dependencies besides potentially dynamically linked Rust std libs (libgreen, etc) and a C++ stdlib. Feel free to bundle those, in the same way you would have to bundle or trust the end users libc implementation.