Grappling with Go

&gt; It’s unprecedented for a language to be both garbage-collected and as squarely aimed at systems programming as Go is, because systems programmers have trouble tolerating the stop-the-world pauses that happen when the GC runs.<p>Only for those that never heard of Mesa&#x2F;Cedar, Algol-68, CPL, Ada, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07, C+@, Sing#, System C#, D.

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.<p>Sure rewriting &quot;bits&quot; 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 from C.<p>I get the feeling this is one of those projects which will never be complete. Perhaps not a bad thing, providing those involved are having fun, but so much verbiage to say so.

&gt; 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.<p>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 the number of kernel threads. Is that still the state of affairs?

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

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

&gt;It’s nice to see CSP in a language I can use for production, and very gratifying to find that it really is an effective tool for carving up concurrency problems. If there is one pitch the Go designers have knocked right out of the park, this is it. I’m already sure I’m going to miss it a lot in Rust.<p>Wait until he realizes that Rust has channels, too. It&#x27;s not as pure as Go&#x27;s implementation, but it&#x27;s a superset.

So I have to wonder about the performance difference between his sloccount and loc (<a href="https:&#x2F;&#x2F;github.com&#x2F;cgag&#x2F;loc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cgag&#x2F;loc</a>) which is so fast it always makes me think that it hasn&#x27;t done anything (same as ripgrep).<p>I&#x27;m like 98% sure loc will be faster, but it would be interesting to know by how much.

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

This has surprisingly little to do with Rust. Maybe change title to original?

I&#x27;ve changed my main language for doing work only a handful of times and it usually takes a few years of doing side-projects in a new language before I switch.<p>For instance it took about 7-8 years before I switched to Java (and then only after establishing a programming style that doesn&#x27;t rely on frameworks at all). The language wasn&#x27;t hard to learn, but it took a while for the JVM and the standard library to get to where it needed to be.<p>C++ never made the cut. Quite possibly because C++ is not really <i>one</i> language. There were at least as many styles of C++ as there had been projects I worked on (except perhaps at Google, which is the only place I&#x27;ve worked where I&#x27;ve consistently seen good quality C++ code).<p>I&#x27;m in the process of evaluating Go as my main language and I have to say that this is the fastest I have gotten comfortable with a new language. I&#x27;ve been noodling around for a few months, doing side-projects, but my experiences so far have been very positive. Unlike most languages I haven&#x27;t come across any uncomfortable stuff that would be hard to overcome. Just the usual confusion about what the idiomatic ways to do things are.<p>What is striking is that it is equally comfortable for doing relatively low-level (my first Go program talked to a chipset over SPI on RPi, doing something that is slightly timing sensitive) stuff and stuff that needs you to build abstractions.<p>I haven&#x27;t used Rust yet. Mostly because I don&#x27;t have the time. And I chose Go since some of my friends use it for software that you and I touch every day, thus providing me with access to people who have used it &quot;for real&quot;.<p>Go just might be my next &quot;main language&quot;. (Actually, right now it feels like I&#x27;ll switch to it and never go back, but the tiny rational bit of my brain says &quot;oh yeah, here&#x27;s a list of other times you had a good feeling about something that turned to crap&quot; :-))

DNS lookup stalls as motivating concurrency .. messy, complicated code with known bugs .. seriously? It&#x27;s not that hard to call getaddrinfo() in a thread and feed results back (atomically) over a pipe. No shared memory or mutexes needed.<p>Looking at Android as a representative of &quot;embedded&quot; 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.<p>EDIT: this comes across pretty snarky - more so than is warranted. I&#x27;m surprised by the first part, but have no right to impugn the whole project based on that. The surprise remains, but I apologise for my tone.

What does he mean by this?<p><i></i><i>&quot;The language does have annoyances. The absence of const is a minor one.&quot;</i><i></i><p><a href="https:&#x2F;&#x2F;gobyexample.com&#x2F;constants" rel="nofollow">https:&#x2F;&#x2F;gobyexample.com&#x2F;constants</a><p><pre><code> const s string = &quot;constant&quot;</code></pre>

My first major project with Go was BugReplay[1], and I had pretty much the same experience as the author. As someone with a lot of perl and python experience the idea of how restricted the language is stylistically initially seemed like a stumbling block but quickly turned into a huge asset.<p>Now when I go back to python or perl (or javascript) I&#x27;m super conscious of the choices I make regarding type checking and parameter checking.<p>[1]: <a href="https:&#x2F;&#x2F;www.bugreplay.com" rel="nofollow">https:&#x2F;&#x2F;www.bugreplay.com</a>

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