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

41–50 of 118 posts

Re: Grappling with Go

#41

Post by tptacek »

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…

Moreover, at the point where you're rewriting ntpd in a new language, you're no longer really producing a hardened version of the original. There already are competing ntpd implementations, if that's all you're after, so this latest excursion into Rust and Go raises the question of whether the project still even makes sense.

Re: Grappling with Go

#42

Post by barrkel »

pjmlp wrote: post #13
nachtigall wrote: post #9

Earlier quoted context omitted.

For Rust, probably Redox ( https://www.redox-os.org/ ). Then there's http://os.phil-opp.com/ and https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).

I know them. My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages. As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored. Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgo…

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 structural isomorphisms with what came before - they could hardly avoid it, being built to solve the same problems - and the older experience is lost, because people focus on the surface, rather than the larger shape. Older experience is dismissed because it was in an outdated language, despite it containing lessons that will continue to be applicable.

Everyone is myopic. It's like politics; the appearance of things is what matters. It's like fashion; it's the intersection of the ideas associated with the surface structure of your output that define its perception. No wonder older developers tend to leave this industry.

Re: Grappling with Go

#43

Post by nimish »

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…

This is basically Eric S Raymond's modus operandi. Instead of bikeshedding over Go vs Rust he could have had an MVP up by now

Re: Grappling with Go

#44

Post by oconnor663 »

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 and parallelism in particular), and we'll see other new languages making the same choices?

Re: Grappling with Go

#45

Post by jerf »

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…

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 changed, 126489 insertions(+), 143789 deletions(-)", but there's a lot of trading C code for test code and more docs in there.

I don't know exactly what metric you're using but this doesn't match my "obvious lack of progress".

Re: Grappling with Go

#46

Post by skj »

rev_null wrote: post #40
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…

To be fair, this was written by ESR. His code to self-congratulatory ratio was pretty high to begin with.

I assume you mean low? :)

Re: Grappling with Go

#47

Post by pjmlp »

barrkel wrote: post #42
pjmlp wrote: post #13

Earlier quoted context omitted.

I know them. My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages. As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored. Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgo…

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…

100% on spot, the fashion driven software as Alan Kay puts it.

Re: Grappling with Go

#48

Post by zzzcpan »

barrkel wrote: post #42
pjmlp wrote: post #13

Earlier quoted context omitted.

I know them. My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages. As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored. Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgo…

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 everyone had to develop everything from scratch, don't really make much sense today. Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past.

Re: Grappling with Go

#49

Post by pjmlp »

bluejekyll wrote: post #36
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 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. :)

Re: Grappling with Go

#50

Post by leshow »

StevePerkins wrote: post #35
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 -…

> Just as no sane person would pick up Rust to write generic web services in that scenario. I agree, but that's the thing... people DO advocate for that! http://www.arewewebyet.org Of course, there's a lot of double-talk on the subject. " You can TOTALLY do it today! " ... " Eh, but maybe you wouldn't want to use it PRODUCTION today " ... " But we're just a FEW more crates away from being there!" ", etc. The Rust com…

Rust absolutely does want to market to the web services crowd. They said as much during their year-end conference. The whole push with futures is partly because of that. This year you'll see a lot more development in the web arena. I realise this messaging is probably what you've heard already, but I believe when futures are integrated into the backend frameworks you'll see some really competitive offerings.
Post reply on HN