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

51–60 of 118 posts

Re: Grappling with Go

#51

Post by pjmlp »

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…

> we'll see other new languages making the same choices?

We are already seeing that, .NET and Java are finally paying more attention to the AOT story on their standard toolchains.

And we also have Objective-C and Swift on iDevices.

Re: Grappling with Go

#52

Post by perlpimp »

"I think writing toy programs - conscious finger exercises - are a terrible way to learn a new language." whoa hold on there. everyone's learning style is different. Doing "dumb simple" things first and extracting reward from it is essential to growing progress, even for advanced programmers imo.

Re: Grappling with Go

#53

Post by SEJeff »

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…

ESR is a master of just this. He's involved, just ask him :)

http://esr.ibiblio.org/?p=6820

Re: Grappling with Go

#54

Post by pjmlp »

jacmoe wrote: post #34
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.

Because they are not competing with another! :) Taken from Dave Cheney's https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-c... -> "Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering e…

With a sub-millisecond GC pauses there are many overlapping use cases.

For example, while you might need Rust to target a PIC or a ESP-32 class processor, Go will run perfectly fine on a ARM Cortex-M3 which also has hardware vendors selling Java compilers, e.g. MicroEJ OS (http://www.microej.com/).

Re: Grappling with Go

#55

Post by blub »

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

One can split hairs like you do, but in the end they're both part of a new generation of statically typed languages aiming for good performance.

People looking for such a language will take a look at them and pick one.

Re: Grappling with Go

#56

Post by christophilus »

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…

I think what you are saying is that the readability of a language is more important than how easy a language is to learn. I heartily agree. Languages that encourage simple, readable code trump pretty much any other language out there, in my opinion. I can't tell you how many times I've looked at my overly abstract Ruby code and just thought, WTF?!

I like Go for this reason. It has more noise (err) than I'd like, but when I look at most Go code, I find it relatively easy to follow and modify. There's no other language I've used that achieves this so consistently.

Re: Grappling with Go

#57

Post by tptacek »

jerf wrote: post #45
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 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't been.

At the point where they rewrite in a new language, they're embarking on a fundamentally different project with a different value proposition, which sort of moots the progress they've made (or not made) on hardening ntpd.

(Fair warning: I am both an ESR skeptic and an ntpsec skeptic; I genuinely do not like the idea behind the ntpsec project).

Re: Grappling with Go

#58

Post by pjmlp »

saywatnow wrote: post #16

DNS lookup stalls as motivating concurrency .. messy, complicated code with known bugs .. seriously? It's not that hard to call getaddrinfo() in a thread and feed results back (atomically) over a pipe. No shared memory or mutexes needed. Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home…

> Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home router.

Well you can look at ARM Cortex-M3 running MicroEJ instead.

http://www.microej.com/resources/supported-platforms/

Re: Grappling with Go

#59

Post by problems »

nimish wrote: post #43
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

He does, there are releases for NTPsec in C. He's just recently debating about Go vs Rust as a possible transition.

Re: Grappling with Go

#60

Post by blub »

jacmoe wrote: post #34
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.

Because they are not competing with another! :) Taken from Dave Cheney's https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-c... -> "Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering e…

There are many things that are not AAA games, browser engines and micro controllers where C++ is used and where the Rust community would like Rust to be used.

Rust and Go might compete in that area, assuming that Go programmers will have interest in such projects.

It's not in the interest of the leaders of each community to admit that though.

Post reply on HN