Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grappling with Go

blog.ntpsec.org

Post reply on HN
Print view View original

71–80 of 118 posts

Re: Grappling with Go

#71

Post by sidlls »

nicoburns wrote: post #23
koffiezet wrote: post #19

Earlier quoted context omitted.

No they're not. Go is very easy to pick up, Rust is not. That point alone should be enough. Without prior knowledge of both, no sane person would consider writing a browser-engine in Go, and yet that's exactly what they're doing with Rust. Just as no sane person would pick up Rust to write generic web services in that scenario. Put Rust and Go in front of a python coder who wrote dozens of web services using flask -…

The question of Go or Rust for something like web services is not as clear cut in my opinion. I have JavaScript/PHP background, and have recently learnt Rust for just this use case. Rust is slightly more complex (but really not that much, nothing close to as bad as C++), but also offers more correctness guarantees. Both are good choices, hence these discussions.

Long time C++ developer here, have written a few toy programs in Rust, and am in the process of re-writing some stuff at work in Rust (from python).

My opinion is that Rust is at least as complicated as C++. They have different complexities, but one isn't "easier" than the other. I enjoy Rust a lot. More than C++, at this point, but that may be the "newness" factor creating bias. I think Rust is likely a better language for people new to systems programming to pick up. It's complexities are largely up-front: a novice will learn how to program well in Rust by having the compiler break his teeth a few times, while for C++ she'd either have to have high-quality mentoring or else learn the hard way (by long experience).

Re: Grappling with Go

#72

Post by LukeShu »

gamesbrainiac wrote: post #64

Why is a 62kb binary a problem for a tool like sloccount? For me 62 KB is darn small.

The "62K" was lines of code, not bytes. He didn't actually give a binary size.

So I downloaded the code and compiled it. The binary is 2.5MB; or 1.6MB after running it through `strip -s`.

Re: Grappling with Go

#73

Post by weberc2 »

fauigerzigerk wrote: post #37
ENTP wrote: post #15

For me, the "learning curve" of Go was very small and that's the kicker. You can get up to speed quickly and get a 'feel' for the language quickly. It's been a great learning experience and I recommend it thoroughly.

I continue to be surprised by this argument. It seems to only matter if your job is to learn one language per week. I don't need to get up to speed in a weekend. It's the speed that I'm getting up to that matters. Of course there is a limit to this principle, I grant you that. What matters as well is how readable other people's code is, or even my own code after not touching it for a year. And I mean readable for som…

Learning curve is important because it means you can bring a new team member up to speed quickly--you don't need to find Go developers, you can make them. The learning investment will pay dividends very quickly. Also, Go can be mastered in 1-3 months, whereas other languages take years. Being able to quickly (i.e., cheaply) produce experts in the language seems advantageous.

Re: Grappling with Go

#74

Post by nurettin »

ridiculous_fish wrote: post #3

> I checked this by writing loccount as a parallelized tree traversal. Each file in the tree gets a goroutine spawned to count its lines; the threads run in parallel and as each finishes its work it stuffs a statistics block into a channel. In the past, this approach would blow up because Go would spawn a kernel thread for each blocking system call that was performed. I had to use a rate limiting channel to constrain…

Wow I know that nickname from 15 years ago.

Re: Grappling with Go

#75

Post by j1f4 »

dcu wrote: post #39
IshKebab wrote: post #38

So I have to wonder about the performance difference between his sloccount and loc ( https://github.com/cgag/loc ) which is so fast it always makes me think that it hasn't done anything (same as ripgrep). I'm like 98% sure loc will be faster, but it would be interesting to know by how much.

so I ran this test using the linux source code. I warmed everything to prevent caching/buffering advantages. For loc the best time was: 55.425s and the worst was: 1m30.557s For loccount the best time was: 42.345s and the worst was: 56.396s loc supports more languages but I also believe it has more false positives. loc reporting seems nicer as well.

Pass the release flag when you build loc; `cargo build --release`.

I see ~5 seconds for loc and ~34 seconds for loccount to count a freshly cloned linux repository.

edit: woops, that was user time. These both spin all the cores. loc takes ~0.7 secs and loccount ~6.6 secs real time.

Re: Grappling with Go

#76

Post by bluejekyll »

tptacek wrote: post #57
jerf wrote: post #45

Earlier quoted context omitted.

What progress are you looking for? There seem to be downloads here, posted pretty regularly: ftp://ftp.ntpsec.org/pub/releases/ I don't know if they build and work, but I'd suspect they do, based on the refactorings being discussed. The commits seem to be clicking along. A diffstat of roughly where I think they branched off of ntp vs. master takes a moment to poke through, because the raw stats are "1032 files change…

They started with Mills ntpd, so there have been downloads available since t0. There's a significant amount of code you can lose from a large C project just by getting rid of ifdefs that nobody uses, so the +/- line count isn't a great metric either. The true metric for success for something like ntpsec is the number of meaningful security problems ntpd has been vulnerable to since ntpsec's inception that ntpsec hasn…

> I genuinely do not like the idea behind the ntpsec project

I don't know the NTP protocol well enough right now, or the aims for the ntpsec project itself. I will say that having a signed response from an NTP server, would raise the trust level of the accuracy of that response. That is, no one can respond with a bogus time and screw up all sorts of stuff.

In terms of privacy/tls etc, that seems less important. But signed messages would be good.

Re: Grappling with Go

#77

Post by NelsonMinar »

stevekemp wrote: post #27

I continue to be surprised by the sheer amount of writing we see about ntpsec. The project was started over two years ago, and yet progress reports seem very optimistic and self-congratulatory, despite an obvious lack of progress. Sure rewriting "bits" of things, with more features, and adding my python sounds useful. But here we are 500+ days since the project started and there are only minor experiments in moving f…

I've been pondering this question too. NTP is a very important Internet service and it's great that folks are looking for a more secure alternative to traditional ntpd. I'm not sure if NTPsec is going to get there or not.

The best alternative out there right now seems to be Chrony. But it hasn't had nearly the inspection and usage ntpd has had, so it's hard to know for sure about its security. ntimed was also looking promising but seems stalled. openntpd doesn't keep time very well and systemd-timesyncd isn't really an NTP implementation.

Re: Grappling with Go

#78

Post by oblio »

zzzcpan wrote: post #48
barrkel wrote: post #42

Earlier quoted context omitted.

Software development has eternal amnesia. Deep understanding of the pros and cons of different ways of structuring things are being continuously re-learnt with each passing fad, and each rewrite of a legacy system by a bright new crop of young things who learned most of what they know with a decade or so of direct experience. Different concerns have different emphases in each fad, but the systems built have structura…

But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because ev…

> But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so.

Hah! Reasons for not learning from history:

* history is hidden behind NDAs, bad licences and patents

* history is hard to access due to its environment (printed on out-of-print books, stored on tapes, HDD and other forms of storage in someone's basement)

* history is written in a programming language nobody knows anymore

* history is written in an incompatible programming language, one for which there are no stable bindings to your favorite language (or for which there aren't any bindings, period)... just think how many times the String class or data type has been written and rewritten just in something like C, let alone the copies in Java, PHP, Ruby, Javascript, Go, Rust, etc., etc.

There's a ton of (somewhat) valid reasons history is forgotten and most of them aren't "history was bad, let's just forget it".

Re: Grappling with Go

#79

Post by dcu »

j1f4 wrote: post #75
dcu wrote: post #39

Earlier quoted context omitted.

so I ran this test using the linux source code. I warmed everything to prevent caching/buffering advantages. For loc the best time was: 55.425s and the worst was: 1m30.557s For loccount the best time was: 42.345s and the worst was: 56.396s loc supports more languages but I also believe it has more false positives. loc reporting seems nicer as well.

Pass the release flag when you build loc; `cargo build --release`. I see ~5 seconds for loc and ~34 seconds for loccount to count a freshly cloned linux repository. edit: woops, that was user time. These both spin all the cores. loc takes ~0.7 secs and loccount ~6.6 secs real time.

I'm not seeing any changes in my results. I'm testing in an old laptop, I guess that's why it's so slow.

My rustc version is 1.15.0 and go 1.8.

Post reply on HN