NTP is officially getting rid of C and going to use Rust or Go

NTP is officially getting rid of C and going to use Rust or Go.

C is officially obsolete.

blog.ntpsec.org/2017/01/03/getting-past-c.html

Other urls found in this thread:

github.com/golang/go/issues/14939
go-review.googlesource.com/#/c/29655/).
phk.freebsd.dk/time/
gitlab.com/gitlab-com/infrastructure/issues/947
benchmarksgame.alioth.debian.org/u64q/rust.html
reddit.com/r/golang/comments/5kv2xx/why_is_golangs_performance_worse_than_javas_in/
twitter.com/SFWRedditGifs

Pro tip: don't look at the comments.

Rob Pike just vibrated

Literally who? Never heard of this progject, don't see why I should listen to their opinion.

kek, ntp is kind of a big deal

porting over a piece of critical infrastructure like that could be huge as it either proves the 'muh ownership safety' autists right or shits on them like pajeet on his favourite street

I use go, but yeah they're both better choices.

>muh ownership safety
They won't be using Rust for this. OP posted the wrong logo out of wishful enthusiasm.

People not updating their NTP servers is the biggest problem with NTP.

All I want is Go without GC.

Just add owned pointers. Memory leaks really aren't that big of a deal for me. Easy to find and easy to fix. Often I just allocate in a pool anyway.

desu i almost wish they went for go just to see the endless tears and tantrums of the rustfags

>Rob "syntax highlighting is for children" Pike

I mean sure the mark and sweep GC is pretty shit, but that's kinda the only sensible thing they put into the language

The 'go' in golang stands for 'garbage-oriented'

- Employed Golang Developer

ESR explains at length why Go is the more mature option, why it's a good fit for this project, and why the only "strike" against it (GC) is not actually a problem thanks to the programmer having control over GC pauses. Rust is being considered thanks to its reputation for being "faster" but they will quickly discover that this is all hype and no substance, and that the productivity cost of fighting with the borrow checker far outweighs its supposed benefits when compared to another equally safe language. Within the next month you can expect a second post explaining why they chose Go over Rust.

> Any manager would move a project to rust instead of Ada
Wew. Also, the article talks more about Go.

How so?
Go is a polished version of C. And then they smeared a GC turd all over it.

>Wouldn’t the stop-the-world pauses from garbage collection rule out Go?

From what I've heard, Go is changing the way it does garbage collection in 1.9 (planned).

Theoretically, Go could be faster than C.

>Memory leaks really aren't that big of a deal for me
How come?

A properly designed program runs for a short time and its memory is reclaimed by the OS when it exits.

Not all programs can be short-lived. Some have to run for years at a time.

Rust already is because of the huge amount of things you can do at compile time.

It can only do those things in theory. None of that is implemented in the compiler, and adding it will take many years.

Like I said. I mostly just allocate in a pool. For the majority of things I allocate I know how big they are beforehand and the approximate range of how many I want.
Combine that with tools like valgrind and I've never had a memory leak bug in any product I shipped.

What do you mean? I was referring to macros.

That's a fine example, because Rust's macros are utterly anemic compared to go generate.

You can do that as well in a language with a GC and never hit it.

Of course, the NTP team is unable to deal with buffer overflows. Blog entry should be "Getting past shitty developers".

Also, this is about NTPsec, a """secure""" implementation of NTP, not the official NTP suite.

The problem is that most GC languages make it hard to know when you're doing a dynamic allocation and give you very little control over memory or how much you're using.
They also make the program non deterministic.

Go actually is actually a lot more clear on this. But still nowhere as where I want it.
Yesterday I learned that the "defer" keyword does dynamic allocation. Something it could just as well be done on the stack.
Then it does some kind of weird fuckery with copying the stack when it grows a goroutine's stack. And I haven't been able to find out if the main thread does this as well.

Part of me wants to write my own language based on Go. If only I wasn't drowning in work.

Main thread is just another goroutine.

C's handling of array passing/length tracking is complete garbage that can be accommodated for but truly shouldn't have to be.

Remember Heartbleed and tons of other high-profile bugs from presumably competent devs.

Heartbleed came out of academia and was merged into trunk with no code review. It was a failure of the development process, not the language.

While I agree
>OpenSSL
>competent devs

...

> shit OpenSSL devs
agreed

Be careful what you're saying here buddy, a surprisingly large faction of C fanboys can't understand "array safety" has other meanings besides dynamic index checking, and god help you should you refer to "array passing" issues as "array decay"...

...

This is some next level trolling.

>refer to "array passing" issues as "array decay"
In practice, you rarely pass arrays as function arguments except when calling into libraries, because almost all arrays you use will have global scope. "Array decay" is a theoretical problem and competent programmers are content to leave it in academia.

global arrays, in-band c string termination, etc. are symptoms of the deeper design flaw.

deflecting blame onto programmers is undue protection of a language with a pretty asinine mistake.

i bet that they wont use Rust, it's so fucking over complicated

> golang: "hey guys, lets try to keep it simple. Like C but with GC!"
> rust: "ok lets add a super complicated lifetime system and on top of that, lets add macros (everybody loves em in C and C++ right?!?!), generics and a ton of other ultra complicated crap! EVERYBODY WILL SURELY SWITCH TO RUST NOW"

They wouldn't rule out Go anyway, since you can disable the GC anyway, and use the heap profiler to ensure that your code doesn't allocate anything in its main loop. And it still would be easier than learning rust

>defer doing dynamic allocation

This shit killed me when I found out. I still don't know why you can't just push that shit onto a fucking stack.

I'm not a rust fan by any means, but criticizing rust macros is insane when it can offer awesome shit like try. I wish go had the try macro

(not even a casual Go user, but ...) isn't the entire point of defer to set up LIFO tasks during scope unwind?

even if you're trying to protect overthrow of a thread's stack, it would seem like you could just use a single linear allocation elsewhere in memory.

If generics are too complicated for you, go work in a bakery instead

wouldn't trust ESR with anything that's meant to be secure. wait for OpenBSD to adopt Rust and write rusted OpenNTPD

For the people who somehow depend on the implementation of defer for their language choices, there is a pretty good read on them in here.
github.com/golang/go/issues/14939

You would think so, but you'll quickly find out you're wrong if you call a function that happens to defer something in performance-critical code sections.

Part of the problem is that go's defer statements are actually closures, so they *can* be forced to track a decently large amount of local state. Still, most of defer's usage is just a single-argument function (i.e. blah.Close()), and it would be great if they could somehow optimize this on a stack.

Damn, right after I wrote , I see that some guy in that discussion is saying he'll do that exact thing. Would have been killer had that made it into go 1.8, but it looks like it'll be in 1.9 at least (go-review.googlesource.com/#/c/29655/). Sweet.

Yea, it's just one of those things somebody has the time for to do. It's not the most fun work in the world and not exactly hanging fruit either.

The way C handles arrays is the ONLY way it can be done without causing needless overhead. If you really want safe arrays that badly, you can always implement your own class in C++, or hack something up in C with structs and macros.

>because almost all arrays you use will have global scope.
>because almost all arrays you use will have global scope.
>because almost all arrays you use will have global scope.
you almost got me
>mutable global state in $CURRENT_YEAR

No, it's a sign of bad programming style. Mutable global state can only be explained by carelessness or idiocy.

>not swift

I've always had a pretty dim view of closures in any sort of systems programming language.

They always seem too hard to shoehorn into linear stack models without ending up either useless or unsafe.

Guess which one is written in C.

It's nice how Go's minor version bumps always have impressive features that basically everyone who uses the language benefits from.

But Torvalds is from Finland, is the picture intentionally like that?

But the C version of hello world will be littered with unsafe pointers, arrays, and format strings, all of which are just waiting to exploit your system

One of the nice things about having a mostly locked standard library and a compatibility guarantee is you only have on thing to focus on. The compiler being written in Go is further motivation to make it really performant.

I am really liking the path it is on now, especially on the Garbage Collector side of things.

I don't think it will help them. You probably don't understand just how bad NTP really is, even if you actually hack on it. It's fractally horrifying. I don't think they can handle it. C is the least of its worries.

Poul-Henning Kamp probably can, and it's taking him years of research and development; adding more devs would only shit it up. I don't think I could name anyone else. ESR doesn't stand a fucking chance at getting it right.

phk.freebsd.dk/time/

Only if it's written by an utter retard.

Go is 300% slower than C. Rust is 3% slower than C.
You are substantially shilly.

Go in a nutshell.

FWIW, gitlab plans to rewrite a lot of their shitty code in Go:

gitlab.com/gitlab-com/infrastructure/issues/947

It will be a big step up from ruby. I'm amazed that they have survived for so long given how shitty their code is. It will be nice to see if they can migrate to Go and see loads of performance issues melt away.

On my machine, C binaries are 30 times the size of Java binaries. Does that mean Java is the better language?

2017 is the year of CHANGE
Julia
Scala
Rust
Grumpy

Learn those get rich. Laugh at Haskell babbyes and C tards

Also keep Java just in case because Java 9 will be great I swear

Java needs value types or it can fuck off. SoA (struct of array) style coding gets old quick in Java.

I'm offended they're not even considering a functional language like Haskell.

Rust AKA Cuck is officially the worst programming language ever devised

he is still ethnically swedish
he barely even knows more than few finnish words

Jesus Christ, your comprehension of type systems and their implementations must be puddle deep on a good day.

You absolutely do not need ad-hoc ptr-plus-len passing to avoid "needless overhead".
Just have:
> strongly typed statically sized arrays with no length passing necessary
> arrays with size known only at run time with their sizes implicitly passed
> implicit type promotion for parameters of the second kind

ta-da! it's the exact same fucking use cases and run-time expenses, except that it's easier to use and impossible to fuck up!
additional pro-tip: systems like this actually exist, as in C++, where you can choose between array, dynarray, span views, etc. in addition to vectors.

That's NTPsec not NTP...

>herp derp cuck derp derp sjw

kys

No joke, I made a bug report to bash about a memory leak that one of our company scripts that was supposed to run for at least very long periods of time on our products
Their response?
Not a bug. The script must quit eventually.

Rewrite it in Perl and call it a day

He found the Go CoC to be too jewy. It uses the word "microagressions" ffs.

Even the compile plugin ones? You can build your own AST. It stabilized a day or two ago.

Jokes on you I can't learn C or Rust or Go

That isn't the ntpd used by the majority of OSes.

And using Rust instead is supposed to fix that?

Rust's isn't as bad as Go's. In fact, it's pretty standard.

>We will exclude you
>we don’t tolerate behavior that excludes people
Rust's is good for a laugh

So you must be against the death penalty then.

>not crystal

shame

Well I dropped gitlab anyway. Been preferred to it after github UI switched to sysem font. Today gitlab makes the same silly mistake too.

I'd rather use github with custom styles (via stylish) instead. For private projects just go to bitbucket.

Crystal is even meme-er than Go.

GO binaries are statically linked, while C/C++ are dynamic by default. Try to compile a hello world statically compiled in C and you will see the file size get close to 2mb

>java
>binary
kek

Rust is a functional programming language.

Of all the limited resources on a computer, disk space is the hill you want to die on? I can get a 20GB SSD from DigitalOcean for $5 a month.

can linkers not strip out the unrelated routine code at all?

at the end of the day, it's just doing a write(2) to a pre-opened descriptor...

I like Rust but it wont replace C.

You can force then not to, but it's not done by default.

it took you 7 minutes to write hello world?

Do you actually know how they would or are you just parroting shit you've heard without understanding it?

The comments gave me end-stage bone cancer.

This is entirely explained in the first paragraph.

"into a language with no buffer overruns, and in general much stronger security and correctness guarantees."

Things they require:
safety/security guarantees
buffer overrun prevention
automatic prevention of other common exploit techniques

Things they don't require:
performance
low level memory manipulation
being able to hire and easily replace developers

Now I'm no expert in Go and Rust, and I don't know the performance numbers off the top of my head, but that is the dichotomy I see.

At work I write "micro-services" in C/C++ to extend our proprietary platform. Our priorities aren't security and safe code, our priorities are getting it out the door fast, and making sure data throughput is high. And we need to be able to quickly, easily replace a developer that decides he needs to go join the circus or whatever.

Different languages for different requirements. If I were starting a project, sure, I'd go and analyse the available languages as see what fits best for the project requirements.

Blind dogma and fanboyism for a single language serves nobody.

You should learn Racket, then.

It can do everything C can except better. In practice, it's even faster as evidenced by real-world software.

>Now I'm no expert in Go and Rust, and I don't know the performance numbers off the top of my head

Rust purpose is to be as fast as C while being safer
benchmarksgame.alioth.debian.org/u64q/rust.html
As you can see in some cases it achieved its goal in other cases not, in a few years it might be capable of being on par with C performance wise

But as you said most developers priorities are getting shit done and not that many know how to use Rust so yeah i don't see it gaining much traction outside of the people developing it or startups at least for the next few years

>Blind dogma and fanboyism for a single language serves nobody.
Amen to that brother

C is indestructible and will never die. It will outlive all of us.

Those benchmarks are garbage. The binary trees put go at something like 39 seconds but a user in /r/golang on reddit was able to write a program that performed better than C.

reddit.com/r/golang/comments/5kv2xx/why_is_golangs_performance_worse_than_javas_in/