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

61–70 of 118 posts

Re: Grappling with Go

#61

Post by jjuel »

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…

That is the beauty of gofmt in my opinion. You can pretty much guarantee that your code will be almost the same style as someone else's code. Which in turn increases readability down the line for someone who knows the language.

Re: Grappling with Go

#62

Post by wtbob »

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…

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

Can't 'ifdefs that nobody uses' hide security flaws? Removing them helps the overall security of the codebase, preventing folks from accidentally enabling a long-dormant codepath, no?

> 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't been.

True enough. Are there any numbers on that?

Re: Grappling with Go

#63

Post by problems »

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.

> but really not that much, nothing close to as bad as C++

C++ dev here. Rust's borrow checking system is crazy and even after a week of trying I couldn't understand it in a way that I could reliably use the language.

In C++ everything is fairly straight forward and well documented, in Rust it feels like I'm inserting random symbols in hopes that something will compile. The syntax is verbose and ugly, maybe not as bad as C++ template code can get sometimes, but it's nasty in its own right.

I want to like Rust, I really do, but this just really turned me off it.

Re: Grappling with Go

#65

Post by tptacek »

wtbob wrote: post #62
tptacek wrote: post #57

Earlier quoted context omitted.

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…

> 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. Can't 'ifdefs that nobody uses' hide security flaws? Removing them helps the overall security of the codebase, preventing folks from accidentally enabling a long-dormant codepath, no? > The true metric for success for something like ntpsec is the…

I'm not saying that eliminating unused compile time options is a bad thing, just pointing out that the real security improvements from hardening something like ntpd come from simplifying and eliminating code that is in the default compile that everyone uses.

Really all I'm saying is that you can't get a reliable metric of progress on something like this from a simple line count.

Re: Grappling with Go

#66

Post by bluejekyll »

pjmlp wrote: post #49
bluejekyll wrote: post #36

Earlier quoted context omitted.

I encourage anyone that hasn't learned Go, to do it as well. In fact, everyone should learn as many languages as they have time for! Each one has interesting decisions they've made that will possibly help you in your everyday language of choice/work. That being said, Go was fun to learn, and taught me that deployment does have to be as painful as it's been in Java for so many years. But I encourage people to also spe…

> For me the type and generics system are the best I've ever used and I wish I had access to them in Java. Then you should spend some time with OCaml and Haskell. :)

I really should. I haven't had the time (caveat from my post above) :)

Re: Grappling with Go

#67

Post by barrkel »

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…

There's a variety of reasons. It's often because our languages are too low-level and the architecture too opaque, such that you need to study a codebase for a long time to understand what works well and what doesn't work so well. The hill you need to climb to reach an epiphany is sufficiently steep that people much rather build their own hill, and learn their own lessons.

The trade-offs come around and around, the lessons are not as inapplicable as you think. We used to struggle to run programs on small machines; those struggles came back again with mobile, and come back again in a slightly different guise in clusters (where the program is too big to fit on any one machine).

They recur on different scales, too. Just the other day I was looking at dependency injection. Dependency injection solves the problem of coordinating dynamic program composition; the reason the program needs to be composed is because it was decomposed for testing. But this is just another iteration of the same pattern come around again. It's been done before in a large variety of ways; sometimes through ambient configuration (global variables), sometimes with patched jump tables (dynamic linking), sometimes statically (module instantiation). The emphasis is different - testing - but the solution is not structurally novel in the least.

Re: Grappling with Go

#68

Post by sidlls »

koffiezet wrote: post #19
blub wrote: post #11

Earlier quoted context omitted.

Because they are competing with eachother! Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.

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

Why wouldn't a sane person write a "generic web service" in Rust? What does that even mean?

Re: Grappling with Go

#69

Post by Ygg2 »

problems wrote: post #63
nicoburns wrote: post #23

Earlier quoted context omitted.

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.

> but really not that much, nothing close to as bad as C++ C++ dev here. Rust's borrow checking system is crazy and even after a week of trying I couldn't understand it in a way that I could reliably use the language. In C++ everything is fairly straight forward and well documented, in Rust it feels like I'm inserting random symbols in hopes that something will compile. The syntax is verbose and ugly, maybe not as ba…

Interesting.

I as Java developer had some hurdles, but most of the time, me and borrow checker get along. My greatest improvement came from compiler lifetime elison in one of the pre-1.0 versions of Rust.

As for syntax being ugly, I do somewhat agree, but mostly, when it reminds me of C++ (e.g. T>>). I hate tire-tracks and Type::static_method() definitions.

Re: Grappling with Go

#70

Post by MichaelGG »

oconnor663 wrote: post #44
akerro wrote: post #8

Rust and Go are not competing with each other. Why do we see so many comparisons of them?

They certainly have a lot in common, either way: - Both compile to native code. - Both care a lot about performance. - Both care a lot about parallelism. - Both care a lot about safety. - Both were invented by a major browser vendor, roughly around the same time. - Both include an unsafe fun zone that lets you play with raw pointers. Maybe some of that was inevitable just by following the trends in the field (safety…

Safety is hardly a trend is it? GC'ing everything makes safety rather much easier. Go doesn't go beyond Java level safety or really any of many earlier "managed" languages. Does Go offer safety above, say, PHP?

Rust not only does all that, it provides data race safety, and does so without a runtime or tracing garbage collector or real performance sacrifices. All while maintaining C linkage for zero cost interop. I can use Rust basically anywhere I could use C, Go, not so much.

That seems to put it squarely in a different segment than Go.

Post reply on HN