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

Pro tip: don't look at the comments.

File: catv.png (87KB, 853x621px) Image search: [Google]

87KB, 853x621px

>>58318469

Rob Pike just vibrated

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

>>58321381
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.

File: gopher.gif (181KB, 500x500px) Image search: [Google]

181KB, 500x500px

>>58321807
>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.

>>58318469
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.

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

>>58319536

>Rob "syntax highlighting is for children" Pike

>>58321975

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

>>58321993

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

- Employed Golang Developer

>>58321978
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.

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

>>58322051
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.

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

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

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

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

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

>>58322299
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.

>>58322352
What do you mean? I was referring to macros.

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

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

>>58318469
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.

>>58322406
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.

>>58322631
Main thread is just another goroutine.

>>58322501
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.

>>58322774
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.

>>58322774

While I agree
>OpenSSL
>competent devs

>>58322876
>>58322912
> shit OpenSSL devs
agreed

>>58322774
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"...

>>58322396

This is some next level trolling.

>>58323001
>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.

>>58323581
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.

>>58318469

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" <- oh and lets make the compile times crazy long because #yolo

>>58322249
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

>>58322631
>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.

>>58324473
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

>>58322631
>>58325053
(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.

>>58324473
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.
https://github.com/golang/go/issues/14939

>>58325118
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.

>>58325329
Damn, right after I wrote >>58325369, 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 (https://go-review.googlesource.com/#/c/29655/). Sweet.

>>58325409
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.

>>58322774
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.

>>58323581
>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

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

>not swift

>>58325369
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.

File: kek.jpg (4KB, 277x33px) Image search: [Google]

4KB, 277x33px

Guess which one is written in C.

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

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

>>58325522
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

>>58325543
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.

http://phk.freebsd.dk/time/

>>58325577
Only if it's written by an utter retard.

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

>>58325522
Go in a nutshell.

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

https://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.

>>58326759
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

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

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

File: 1468839104430.png (73KB, 2048x1024px) Image search: [Google]

73KB, 2048x1024px

Rust AKA Cuck is officially the worst programming language ever devised

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

>>58325452
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...

>>58327285
>herp derp cuck derp derp sjw

kys

>>58322332
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.

>>58327500
Rewrite it in Perl and call it a day

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

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

File: 1450970322290.jpg (29KB, 320x291px) Image search: [Google]

29KB, 320x291px

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

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

>>58328029
And using Rust instead is supposed to fix that?

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

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

>>58329970
So you must be against the death penalty then.

>>58326947
>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.

>>58330415
Crystal is even meme-er than Go.

>>58325522
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

>>58327025
>java
>binary
kek

>>58327153
Rust is a functional programming language.

>>58325522

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.

>>58331154
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...

>>58318469
I like Rust but it wont replace C.

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

>>58325522
it took you 7 minutes to write hello world?

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

>>58319322
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.

File: 012.jpg (111KB, 320x480px) Image search: [Google]

111KB, 320x480px

>>58328477
You should learn Racket, then.

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

>>58332825
>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
http://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.

>>58336336
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.

https://www.reddit.com/r/golang/comments/5kv2xx/why_is_golangs_performance_worse_than_javas_in/

>>58326685
>>58332358
Come on guys, everyone knows the standard "hello world" in C is this:

#include <stdio.h>
#include <string.h>

int

// This is the main function
main(int argc, char ** argv)
{
        char str[16];
        // Print the args too
        while (--argc) {
                strcat(str, argv[argc]);
        }
        strcat(str, "hello world!\n");
        printf(str);
}

>>58318469
Actually it's not. One unofficial blog post does not a change make.

>>58337624
I couldn't figure out why it prints garbage characters before "hello world", but I guess that's a price I have to pay for the great performance!

OpenBSD & seL4 are real proof that C can be clean, the problem is usually that lots of people contributing = lots of spaghetti code.
Without any real auditing and competent review of the stuff people add it's hard to maintain clean codebase.
Also memory safety doesn't mean it's exploit free lot's of other bugs can be introduced because muh safety lets add spaghetti code.

>>58327318
I'm not that guy, but all of those things you wrote still require checking every array access at runtime, unless every instance of indexing into an array index can be statically verified at compile time.

>>58337856
lmao, passing length fields isn't the same as dynamic bounds checking.
it's just getting the length info to where it needs to be, for copies, concatenations, etc. as well as random accesses.

random access bounds checking needs length, but it's far from the only thing that does.

>>58337926
Right, but the guy said
>The way C handles arrays is the ONLY way it can be done without causing needless overhead
which I assumed to be referring to the fact that C does not check bounds at runtime, unless the programmer does so explicitly. I guess he could just be a total retard and be complaining about having to pass around the length field. Granted, tons of C programmers *do* have a problem with that...

>>58336259
>It can do everything C can except better.
Except, you know, running fast and building small binaries.

>>58331154

569K on my machine

>>58331888
That's exactly what they do (by default, even), but there are a few gotchas.

Static linking operates at the granularity of an object file. If an object file in an archive defines a lot of functions, but your program only uses one of them, the whole file goes into your binary. Remember that the linker also needs to link in code your program uses indirectly, so even if you only call nicely unit-segregated functions in your code, a single utility function in a giant object file can still bloat up your binary.

There may be linker options these days for function-level linking but I'm not familiar with them.

>>58331154
Golang programs also carry the size overhead of the Go runtime. Goroutines and garbage collection don't come free.

I also suspect that the hello world was written using the fmt package, which has the reflect package as a dependency, which is a known bad case for the linker: using reflection, one can walk over and call ALL the methods of a type, so the code for all of them (and their dependencies) needs to be linked in.

>>58341397
>fmt package

It must have been. I compiled a hello world go program using only the "println" built-in (which nobody ever uses, for the information of any non-go users around), and it produces a 1MB binary. "strip --strip-unneeded" brought the binary down to 600KB. This was on go 1.7.1, so it's not even the newest version.

>>58318469
who the fuck uses ntpsec or even "ntp classic"?
if you don't use openntpd or timesyncd you should be using windows.

>>58321975
>>58322051
>all these gofags pretending that they've ever worked on something that was affected by the gc
If you are on the latest release you won't even "feel" the GC unless you're writing games or hard realtime shit.

>>58324473
desu i thought rust was over complicated until 3 days ago. i haven't done much advanced work with it but so far it's been a pretty cool experience.

(i have 9yr experience with c and 6yr experience with c++)

>>58342422
It is overcomplicated. The module system alone has 5 different ways to refer to a name, all with different rules. Try using a library in a submodule and see what happens.

>>58342459
i did have some issues with mod/use when i created my first crate but i've figured it out after googling a bit.

>>58342488
If you have to google to understand how it works, it's too complicated. It should be intuitive at first glance.

>>58342366
>unless you're writing games
Guess what I'm writing faggot.

>>58342366
For some reason, my beginnings of a game in Go+SDL seem to stutter *more* on the newer versions of Go than they did on older versions.

>>58342366
>implying anybody on /g/ hasn't tried to write a game at least once

>>58322287
Theoretically, Python could be faster than C. Practically, no.

>>58342523
>>58342546
>>58342584
if you're writing games in go you're doing it wrong

>>58342662
It wouldn't be if it wasn't for the GC.

>>58318469

> One thing moves from C in 2017.
> C finished

K....

I mean sure people are moving forward which is good but C will still be very relevant for probably long after we are all dead.

I'm not advocating for C or anything here, just it's not something that will go away. I see x86 going away and being forgotten before C even starts to look obscure or unused.

Only thing that would cause c to die is a complete shift in computing and technology and a total reboot of everything we know. Too much shit relies on C.

>>58318469
>throw out a working code base and rewrite it in another language
Why?

>>58342847
The C community wasn't tolerant and inclusive enough of women, trans* people and people of color.

>>58342662
People write games in python, java, flash, and javascript. Why would Go be worse than any of those?

>inb4 "they aren't good games"

>>58332160
asking the real questions

>>58342847
From actually reading the article, the reason seems to be that the code base is shit anyway, and if they're doing a rewrite they'll do it in a safer language.

>>58342756
People who think C can be replaced have never written low-level code. Higher level languages need to be able to stop every thread whenever an allocation happens so they can rewrite pointers as they relocate extant heap objects while defragging the address space. Unpredictable pauses are a fact of life in high level languages. But when you're bitbanging system calls onto a serial port, they're just plain unacceptable.

>>58342991

Well there is no technical reason there can't be a new language to do this.

We can have a more modern c with some niceties without losing low level control. Just no one wants to rewrite the thousands of c libraries, cpmpilers, etc and support c and this new meme language.


I wouldn't mind a enhanced c that had some nice extras, and modern features but wasn't a giant cluster fuck of shit like c++. There are a few 'c with objects' but they are all macro messes/hacks.

>>58343308
Such a language would be worse than C, because it wouldn't be C.

>>58339889
It can do both better than C though.

>>58342991
Not sure if clinically retarded or lobotomized. Eitherway, thanks for the cringe.

>>58336259
It can but I don't think you have any idea just how many C programs are out there we rely on everyday. You need at least 2 decades of rewriting them into Rust and debugging until they're the same quality.

C isn't going away anytime soon. Rust still needs better documentation too the guy posted to HN yesterday that they purposely left tons of "advanced" material out of the Rust book just to shill the lang to webdevs, and then admitted they forgot to document those features elsewhere too.

>>58344709
It would probably take 5 years total, but certainly not 2 decades. First you're greatly underestimating the speedup from developing in a high-level language like rust as opposed to C. Second, you're not taking into account the global dev experience that has developed writing the various kinds of programs in C. Third, you're also not taking into account the performance boost from not having to develop with hardware that's decades old in mind.

Plus the fact you don't have to even check for memory-related errors whatsoever in 99.9999% of cases, and how ridiculously good the error messages are for the rust compiler (as opposed to "segmentation fault (core dumped)"), all in all I think my estimate is more realistic.

However it would be a different story if we were to include C++ software simply because the biggest, most tricky software are written in C++ if they're not written in java.

Whether or not rust needs more documentation is unclear. A good realworld example should be used to clarify this.

What percentage of a library like glibc would be spent in unsafe blocks? C created this wrong perception that you need lots unsafe code, due to how it does strings and vectors but there would still be a lot of unsafe blocks in a glibc rewrite.

In all safe alternatives to C, just like Rust you need unsafe at the Assembly FFI level and hardware integration like IO ports and interrupt handling. Rust is much, much better than C/C++ at this but it won't magically fix all vulnerabilities esp if low skilled programmers are doing rewrites and introducing new bugs into services like NTP or kernel code.

For sure C is dying but we'll still have exploits galore even with Rust, just they won't be low hanging fruit memory exploits.

>>58344832
As I noted here >>58344891 there is no money or motivation for anybody to rewrite major projects like glibc hell we can't even maintain them today with any kind of funding.

Right now we just have hobbyists doing the work, and Rust's compiler still has tons of bugs http://robert.ocallahan.org/2016/02/rewrite-everything-in-rust.html

>>58321381
>>58321807

It's not "NTP".
It's a fork of the ntp project that no one uses.

Here's some hard numbers on the code size and static/dynamic linking debate

    6712 Jan  5 15:50 hello-dynamic-c
    8392 Jan  5 15:51 hello-dynamic-cpp
    8608 Jan  5 15:50 hello-dynamic-rs
  801224 Jan  5 15:50 hello-static-c
 2024928 Jan  5 15:50 hello-static-cpp
 1646254 Jan  5 15:53 hello-static-go
  964768 Jan  5 15:50 hello-static-rs

C: gcc 5.3.1, printf(...)
C++: g++ 5.3.1, cout << ... << endl
Rust: rustc 1.10.0, println!(...)
Go: go 1.7.4, fmt.Printf(...)

I've never used Go so I just copied the "hello world" from their website. I saw a post ITT saying `fmt` causes code bloat, so if someone wants to provide a better version, I'll build that instead. Also, if anyone knows how to build a dynamically-linked hello world in Go, please let me know (building with -linkshared gives me "cannot implicitly include runtime/cgo in a shared library")

>>58345649
>2 MB hello world

Sasuga sepples, STL was the right choice.

>>58345649

How does the ldd output compare among the four statically linked binaries? I find it incredibly hard to believe that a statically linked C++ program takes up more disk space than a statically linked Go program, PLUS the statically linked-in Go runtime.

Not that I give a shit about Go's big binaries, but since you've done the work and have the binaries handy, now I'm curious.

>>58325452
>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.
You realize Rust array's are literally C arrays right?
It's a pointer and you calculate the offset. The Rust ABI just forces you to pass the length around as well, but this gets removed post compile (outside of debug mode). Release binaries maybe do 1 bounds check ever 1000x accesses. For static/bounded loops you'll only bounds check against the maximum value.

Really all Rust is doing is forcing you write how you _should_ write C code.

>>58345861

hello-dynamic-c:
    linux-vdso.so.1 (0x00007fffa1d28000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa22feb5000)
    /lib64/ld-linux-x86-64.so.2 (0x0000558469ec1000)
hello-dynamic-cpp:
    linux-vdso.so.1 (0x00007ffcdb9f8000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fcb52875000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcb5256d000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcb52355000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb51fad000)
    /lib64/ld-linux-x86-64.so.2 (0x0000562c9f2e6000)
hello-dynamic-rs:
    linux-vdso.so.1 (0x00007ffe8fdb8000)
    libstd-2f39a9bd.so => (long-ass path)/lib/libstd-2f39a9bd.so (0x00007f72d52d5000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72d4f05000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f72d4cfd000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f72d4add000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f72d48c5000)
    /lib64/ld-linux-x86-64.so.2 (0x000055e404e2a000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f72d45bd000)
hello-static-c:
    not a dynamic executable
hello-static-cpp:
    not a dynamic executable
hello-static-go:
    not a dynamic executable
hello-static-rs:
    linux-vdso.so.1 (0x00007ffe39348000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb46ff9d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb46fd7d000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb46fb65000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb46f7bd000)
    /lib64/ld-linux-x86-64.so.2 (0x000055dd03b8d000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb46f4b5000)

>>58337965
>Granted, tons of C programmers *do* have a problem with that...
Mostly retarded ones. C98, 03, and 11 standards all had proposals to make arrays be ptr+len tuples. The real issue is nobody can agree on the ABI. Some people want to put the 128bit wide tuples into SSE registers. But then you need SSE4+ to read the high/low 64bit words as 64bit ints. So now you have compatibility problems with the AMD64 ABI.

Interesting. Statically-linked C++ is indeed bigger than Go, and Rust static binaries either aren't actually statically linked or you compiled it wrong.

What happens if you compile the C and C++ programs with -Os?

>>58346124
>Rust static binaries either aren't actually statically linked or you compiled it wrong
hello-static-rs is compiled with the default flags, which statically link all the Rust dependencies but apparently not the C ones. I looked through --help, -C help, and -Z help for more "static" options, but I couldn't find any.

>What happens if you compile the C and C++ programs with -Os?

   6712 Jan  5 15:50 hello-dynamic-c
   6704 Jan  5 16:42 hello-dynamic-c-Os
 801224 Jan  5 15:50 hello-static-c
 801160 Jan  5 16:41 hello-static-c-Os

>>58346228
Can you strip all of those executables with "strip --strip-unneeded"? As those are, they're only marginally smaller than a Go hello world that (correctly) doesn't use the fmt package.

>>58318469
lmao anti-rust fags BTFO

now that one of the most fundamental and long standing services on every platform is using Rust, how will they EVER recover?

>>58345649
The non-fmt Go version of hello world:

package main

func main() {
    println("Hello, world!")
}

This should be at or below 1 MB.

>>58346458
Did you even read the article or the thread? The guy's leaning towards Go, not Rust. Also, it's not a "fundamental and long-standing service on every platform". There are alternative implementations of NTP on several platforms.

>>58346460
>This should be at or below 1 MB.

 1003404 Jan  5 17:06 hello-static-go

>>58346446
>Can you strip all of those executables with "strip --strip-unneeded"?

    4432 Jan  5 17:07 hello-dynamic-c
    4424 Jan  5 17:07 hello-dynamic-c-Os
    5536 Jan  5 17:07 hello-dynamic-cpp
    5896 Jan  5 17:07 hello-dynamic-rs
  727768 Jan  5 17:07 hello-static-c
  727704 Jan  5 17:07 hello-static-c-Os
 1596760 Jan  5 17:07 hello-static-cpp
  627856 Jan  5 17:07 hello-static-go
  434904 Jan  5 17:07 hello-static-rs

>>58325522
You can strip the Rust binary to remove all the debug stuff, and the binary size is 2kb larger than equivalent C program.

>>58346228
rust binaries dynamically link to glibc but everything dynamically links to glibc. It's a sin not too.

>>58346574
So C++ has 400KB of debug symbols in its stdlib and still gets BTFO by everything in terms of size after stripping

Go surprisingly does better than C in terms of actual code (unlikely if fmt was used, though)

Rust wins overall on the size. Nice.

>>58346669
oic, overlooked that rust still uses dynamic linking when "statically" linked. Oh well

>>58337728
This, OpenBSD has a proven track record.
rewriting things in rust will introduce new bugs and specially if those are new programmers.
Nobody is going to pay people to rewrite things in rust so unless it gets backers it will stay for the hobbyists & startups.

>>58346838
Rust has mozilla as a pretty damn big backer, just like Go has Google. We can say for sure that the OpenBSD devs don't like people to force new shit at them, so that's at least one C user that's going to stick around for a while longer.

>>58346909
Linux kernel, Freebsd kernel, lots of other kernels, big projects are not gonna be rewritten.
Mozilla is small comparing to Google.

>>58321975
You can write code that doesn't need GC, this is pretty easy to optimize/do.

The only time you really need it is for something like audio processing where there's a lot of garbage left over.

>>58346909
OpenBSD is open to Rust though, they're just waiting for the language to get out of beta and actually have a definitive spec that doesn't change every week so they can start rewriting daemons like OpenNNTPD and OpenSMTPD with it. They also like the concurrency Rust offers for writing new web servers but again there's no official spec or anything concrete as far as Rust development yet, give it a few years.

They also have decades of experience shaking the bugs out of the GCC compiler which is why they build for multiple arches, some are just solely for bug exposing. Rust compiler still needs a lot of work, and some formal verification around some of its types to make sure it's actually doing what it says it's doing under all circumstances (again, give it a few years and it'll be there)

>>58347061
We can't even rewrite the shit parts of the Linux kernel that are filled with 20 million lines of legacy code that needs rewriting let alone Rustify it.

What would be good though would be for say, Hurd to move to Rust. They're a microkernel anyway

>>58347143
>they're just waiting for the language to get out of beta
They will be waiting for thirty years.

Go has GC, and stops all execution while GC does it's stuff.

Rust uses ARC, no GC, and is better because of this. If they use Go it's because they wanted the low barrier to entry at the cost of future potential

>>58347490
2017 is when rust will have ABI stability

>>58347801
Rust does not use ARC.

It has reference counted types in the standard library, but memory is handled by RAII and destructors are inserted at compile time.

>>58347834
Rust does use ARC. The compiler inserts the increments and decrements automatically.

>>58347856
It does not, there are no increments or decrements, nothing is reference counted.

>>58347197
redox-os.org
It is a work in progress has a TCP stack, x64 support, and a GUI. Still needs a libc, compiler, and multithreading.

>>58347871
There's a blog post from Rust core developers about how they planned to implement GC but gave up trying and made ARC instead.

>>58347856
he's right. arc is done at compile time, the memory is scheduled at compile time when it will enter and exit

>>58347856
If you opt into it. Not by default. Swift uses ARC for everything. Rust actually does lifetime tracking.

>>58347894
Check the year, and the Rust version it's talking about, there hasn't been ARC for eons.

>>58346446
>>58346574
>>58346669

You're not supposed to strip(1) Go binaries. 4chan thinks a link to a github wiki is spam, so here's an excerpt from Docker's wiki that you can google yourself:

> Please, please, please do not strip any compiled binaries. This is really important.
>
> In our own testing, stripping the resulting binaries sometimes results in a binary that appears to work, but more often causes random panics, segfaults, and other issues. Even if the binary appears to work, please don't strip.

>>58347801

>Go has GC, and stops all execution while GC does it's stuff.

Go optimizes its garbage-collector for low pause times, and they seem to somehow find ways to make it faster with every release.

The design of Go also makes it much easier to garbage collect, with its wide usage of value types as opposed to something like Java where everything that isn't a primitive type is a reference-counted object with all the overhead that entails.

>>58337965
You could always just make checking indexes the default and provide a standard library function for array indexing without a bounds check, or even allow a compiler flag to eliminate all runtime bounds checks.
At the end of the day, iterating through an array doesn't require bounds checks anyways, and bounds checks could be eliminated by fairly simple compiler optimizations.
There is NO good counter argument other than C fanboyism

Rust provides a reference counted TYPE, saying that Rust does ARC is exactly as valid as saying that C++ does ARC

>>58347143
it's been out of beta for a while already.

I have no idea why this thread has such a hate-fest for GC. Naive reference counting will always be slower than a tracing garbage collector.

What, you think that RAII and reference counted types suddenly frees you from the costs of destructing an object? Instead of dealing with garbage-collection pauses, you're dealing with additional overhead of dealing with the reference count, and then introducing a destruction delay at the exact moment a reference counted object becomes unreachable.

You're basically praying that those instantaneous delays will be unnoticeable, which is generally true....until your program grows in size and complexity and suddenly it isn't anymore. And then you begin the long sad journey of trying to better manage the lifetimes of these objects, which means you're now introducing a ton of extra complexity, essentially writing your own (likely incredibly shitty) garbage collector. Or maybe you do some sort of pool allocation scheme, which surprise surprise you can do in GC languages anyway.

There is no such thing as a free lunch.

>>58348476
Oh god, that's right, I forgot about that shit. I still can't believe they decided to go with some wacky custom toolchain. Even Clang used GNU binutils for ages, only now are they writing their own linker, and it's going to be GNU ld compatible. Meanwhile Go is off doing its own batshit plan9 thing, producing nonstandard binaries that mysteriously break if you remove normally-irrelevant sections from them. I have no idea how they fucked up that badly but I find it hilarious.

>>58349626
it's not just removing sections, it's removing symbols from the symbol table. This can cause problems if something needs to use reflection or needs to look up a symbol.

Yes it's a custom toolchain that's crazy, but it allows for easily targeting other platforms and systems by changed environment variables.

File: thumbnail_21509.jpg (24KB, 400x300px) Image search: [Google]

24KB, 400x300px

>>58349626

I don't think you know what a "nonstandard binary" is. The standard for a binary file on Linux is the ELF format, and it's a standard that Go binaries conform to - they kind of have to, otherwise how would they even run in the first place.

If you want to safely strip a go binary, you can do it at compile time by passing -s to the linker.

And yeah, Go's toolchain might be non-standard, but being able to cross-compile across operating systems and CPU architectures by setting two environment variables is fucking sweet.

They've also been gradually evolving the toolchain behind the scenes, you can watch this video for a taste of how the assembler has evolved and why it's so easy to cross-compile:

https://www.youtube.com/watch?v=KINIAgRpkDA

They're trying to get to a point where they can machine-read a PDF description of a new architecture and from that automatically generate the proper tables for their assembler.

>>58349552

It dtill needs the rest of it.

>>58318469
Lisp would've been the solution (Common Lisp).

>>58318469
>C is officially obsolete
yea no