14 ms·

Grappling with Go

155 points by dcu 10y ago

Ygg2 10y ago
This has surprisingly little to do with Rust. Maybe change title to original?
- tmpxkdks 10y ago
  He knows that rust posts are usually popular here. It is just clickbait.
- bluejekyll 10y ago
  I had the exact same thought. On top of that, the fact that he did this before the post on Rust is strange. Why publish them out of order? Reading this first would have made it clear that he already had a strong bias towards Go, and also would have showed the Rust community what it was in detail that he liked in Go, so as not to have inflamed so many who love Rust. It seems at this point clear to me, that the previous Rust piece was written out of sheer frustration, and that the entire period while "learning" Rust he really wanted to be writing in Go, which he had already found to enjoy. This is understandable, but creates a clear bias; which is completely fine, but would have been nicer to see this for that reason. Everyone's experiences are going to lead them in different directions. I learned Go, decided it was missing features that I really wanted, and that's when I decided to learn Rust. That was a decision driven as much from comfort with a language as it was technical. Which brings me back to his original Rust post, it was written as though comparing two languages on their technical merit, when in reality (after reading this post) it was really about comfort. Again this is fine, and would have been clearer if posted in the original order.
ridiculous_fish 10y ago
> 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 the number of kernel threads. Is that still the state of affairs?
- lmb 10y ago
  Yes, that is still the case. Cgo calls work the same. Note that the most common syscalls get special treatment though: file and network I/O use a thread pool and epoll/kqueue respectively.
- StreamBright 10y ago
  Isnt there a way to limit the number of threads? Starting N threads each reads the same queue and executes the operation. The queue gets full when there are no workers are available. I though you can implement something like this in Go...
  - pcwalton 10y ago
    You risk deadlocks if you have a limit on the number of system threads. Think about something like goroutines reading and writing from pipes.
- nurettin 10y ago
  Wow I know that nickname from 15 years ago.
pjmlp 10y ago
> 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. Only for those that never heard of Mesa/Cedar, Algol-68, CPL, Ada, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07, C+@, Sing#, System C#, D.
- xiaoma 10y ago
  What's the most successful operating system created in one of those languages?
  - pjmlp 10y ago
    Probably Oberon, which was used during several years at ETHZ across the IT department of the university, including the secretary personal. Was also the source for many of Plan 9 UI ideas. What is most successful operating system created in Go or Rust?
    - nachtigall 10y ago
      For Rust, probably Redox (https://www.redox-os.org/ https://www.redox-os.org/). Then there's http://os.phil-opp.com/ http://os.phil-opp.com/ and https://intermezzos.github.io/book/ https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).
      - pjmlp 10y ago
        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 forgotten systems had. We can only improve our future by learning the lessons from the past.
akerro 10y ago
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
- blub 10y ago
  Because they are competing with eachother! Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
  - koffiezet 10y ago
    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 - and I am pretty sure I can predict what tool he'll pick. Sure you could write web services in Rust, that's not what I'm arguing, learning Rust for writing stuff like that is simply not worth it for people having to write such services. Rust's complexity is comparable with C++, and the main reason for this complexity is to address problems that are mainly seen in C/C++ applications. Rust's reason for existing is simple: modern low-level language with built-in (memory) safety with no performance trade-offs (implying concurrency support etc). That makes it squarely aimed at C++, where developers accept the complexity as a trade-off for performance. Go's reason of existence and goals are completely different, it addresses the gap that existed between compiled and interpreted languages. It wants to be a simple, safe, easy to deploy language that offers more performance over classic scripting languages and thus is able to address more performance-critical issues. It's main target is clear: servers and networking services, where a GC's impact less important due to the I/O bottlenecks in most scenario's.
    - nicoburns 10y ago
      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.
ENTP 10y ago
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.
- bluejekyll 10y ago
  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 spend some time with Rust, as it has made a very different set of choices. For me the type and generics system are the best I've ever used and I wish I had access to them in Java.
  - pjmlp 10y ago
    > 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. :)
    - bluejekyll 10y ago
      I really should. I haven't had the time (caveat from my post above) :)
- fauigerzigerk 10y ago
  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 someone as proficient in the language as the original author. This aspect sometimes seems underappreciated by proponents of "powerful/expressive" languages.
saywatnow 10y ago
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 router. EDIT: this comes across pretty snarky - more so than is warranted. I'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.
- StreamBright 10y ago
  Depends on the situation, if you are in a server that needs to handle millions of requests and you create a million thread probably wont fly. If your concurrency is limited to a low enough number than you can create and terminate threads, so the proposed threading solution works well on mobile devices.
- bluejekyll 10y ago
  DNS gets so much blame, and yet so little time is spent to make it better. If DNS is that important to your application, you should install a caching resolver locally on your system.
- pjmlp 10y ago
  > 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/ http://www.microej.com/resources/supported-platforms/
  - saywatnow 10y ago
    I don't understand the relevance?
    - pjmlp 10y ago
stevekemp 10y ago
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 from C. 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.
- tptacek 10y ago
  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.
- bluejekyll 10y ago
  I had the same thought. I will say that that lack of progress may be the exact reason why so much consideration is being put into porting to another language, so as to make faster progress.
- rev_null 10y ago
  To be fair, this was written by ESR. His code to self-congratulatory ratio was pretty high to begin with.
  - skj 10y ago
    I assume you mean low? :)
- nimish 10y ago
  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
IshKebab 10y ago
So I have to wonder about the performance difference between his sloccount and loc (https://github.com/cgag/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.
- dcu 10y ago
  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.
  - j1f4 10y ago
    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.
    - dcu 10y ago
      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.
      - j1f4 10y ago
        If you are running the program with `cargo run` that takes the same --release flag. Could be the machine difference though.
        dcu 10y ago
        I'm not. Are you testing with go 1.8 btw?
perlpimp 10y ago
"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.
gamesbrainiac 10y ago
Why is a 62kb binary a problem for a tool like sloccount? For me 62 KB is darn small.
- LukeShu 10y ago
  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`.
w8rbt 10y ago
What does he mean by this? "The language does have annoyances. The absence of const is a minor one." https://gobyexample.com/constants https://gobyexample.com/constants const s string = "constant"
- peterwaller 10y ago
  He's referring to it as a type qualifier, I would assume. https://en.wikipedia.org/wiki/Const_(computer_programming) https://en.wikipedia.org/wiki/Const_(computer_programming)
  - w8rbt 10y ago
    Got it! Thanks for the clarification.
- dllthomas 10y ago
  I don't think he was complaining about the lack of a syntactic token reading "const", but rather the inability to protect values from modification (in certain contexts) without incurring the overhead of hiding them behind an interface.
edibleEnergy 10y ago
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. Now when I go back to python or perl (or javascript) I'm super conscious of the choices I make regarding type checking and parameter checking. [1]: https://www.bugreplay.com https://www.bugreplay.com
edibleEnergy 10y ago
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. Now when I go back to python or perl (or javascript) I'm super conscious of the choices I make regarding type checking and parameter checking. [1]: https://www.bugreplay.com https://www.bugreplay.com
tormeh 10y ago
>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. Wait until he realizes that Rust has channels, too. It's not as pure as Go's implementation, but it's a superset.
bborud 10y ago
I'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. For instance it took about 7-8 years before I switched to Java (and then only after establishing a programming style that doesn't rely on frameworks at all). The language wasn't hard to learn, but it took a while for the JVM and the standard library to get to where it needed to be. C++ never made the cut. Quite possibly because C++ is not really one 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've worked where I've consistently seen good quality C++ code). I'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'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'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. 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. I haven't used Rust yet. Mostly because I don'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 "for real". Go just might be my next "main language". (Actually, right now it feels like I'll switch to it and never go back, but the tiny rational bit of my brain says "oh yeah, here's a list of other times you had a good feeling about something that turned to crap" :-))
- sanjayts 10y ago
  Sorry if you saw this coming but do you really not miss generics and exceptions? I like Go given that it's a lean language and the compiles down to a self contained binary which doesn't consume gobs of CPU or memory and is pretty quick to start-up and run. Perfect language for writing command line tools and one-off network clients. But I dread the feeling of writing repetitive error handling code and copy-pasta to get a simple generic functionality to work across data types. Maybe I should just consider it a better C and move on...
  - 10y ago

Grappling with Go

155 points by dcu 10y ago

Ygg2 10y ago

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

tmpxkdks 10y ago
He knows that rust posts are usually popular here. It is just clickbait.
bluejekyll 10y ago
I had the exact same thought. On top of that, the fact that he did this before the post on Rust is strange. Why publish them out of order? Reading this first would have made it clear that he already had a strong bias towards Go, and also would have showed the Rust community what it was in detail that he liked in Go, so as not to have inflamed so many who love Rust. It seems at this point clear to me, that the previous Rust piece was written out of sheer frustration, and that the entire period while "learning" Rust he really wanted to be writing in Go, which he had already found to enjoy. This is understandable, but creates a clear bias; which is completely fine, but would have been nicer to see this for that reason. Everyone's experiences are going to lead them in different directions. I learned Go, decided it was missing features that I really wanted, and that's when I decided to learn Rust. That was a decision driven as much from comfort with a language as it was technical. Which brings me back to his original Rust post, it was written as though comparing two languages on their technical merit, when in reality (after reading this post) it was really about comfort. Again this is fine, and would have been clearer if posted in the original order.

ridiculous_fish 10y ago

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

lmb 10y ago
Yes, that is still the case. Cgo calls work the same. Note that the most common syscalls get special treatment though: file and network I/O use a thread pool and epoll/kqueue respectively.
StreamBright 10y ago
Isnt there a way to limit the number of threads? Starting N threads each reads the same queue and executes the operation. The queue gets full when there are no workers are available. I though you can implement something like this in Go...
- pcwalton 10y ago
  You risk deadlocks if you have a limit on the number of system threads. Think about something like goroutines reading and writing from pipes.
nurettin 10y ago
Wow I know that nickname from 15 years ago.

pjmlp 10y ago

> 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. Only for those that never heard of Mesa/Cedar, Algol-68, CPL, Ada, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07, C+@, Sing#, System C#, D.

xiaoma 10y ago
What's the most successful operating system created in one of those languages?
- pjmlp 10y ago
  Probably Oberon, which was used during several years at ETHZ across the IT department of the university, including the secretary personal. Was also the source for many of Plan 9 UI ideas. What is most successful operating system created in Go or Rust?
  - nachtigall 10y ago
    For Rust, probably Redox (https://www.redox-os.org/ https://www.redox-os.org/). Then there's http://os.phil-opp.com/ http://os.phil-opp.com/ and https://intermezzos.github.io/book/ https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).
    - pjmlp 10y ago
      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 forgotten systems had. We can only improve our future by learning the lessons from the past.

akerro 10y ago

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

blub 10y ago
Because they are competing with eachother! Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
- koffiezet 10y ago
  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 - and I am pretty sure I can predict what tool he'll pick. Sure you could write web services in Rust, that's not what I'm arguing, learning Rust for writing stuff like that is simply not worth it for people having to write such services. Rust's complexity is comparable with C++, and the main reason for this complexity is to address problems that are mainly seen in C/C++ applications. Rust's reason for existing is simple: modern low-level language with built-in (memory) safety with no performance trade-offs (implying concurrency support etc). That makes it squarely aimed at C++, where developers accept the complexity as a trade-off for performance. Go's reason of existence and goals are completely different, it addresses the gap that existed between compiled and interpreted languages. It wants to be a simple, safe, easy to deploy language that offers more performance over classic scripting languages and thus is able to address more performance-critical issues. It's main target is clear: servers and networking services, where a GC's impact less important due to the I/O bottlenecks in most scenario's.
  - nicoburns 10y ago
    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.

ENTP 10y ago

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.

bluejekyll 10y ago
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 spend some time with Rust, as it has made a very different set of choices. For me the type and generics system are the best I've ever used and I wish I had access to them in Java.
- pjmlp 10y ago
  > 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. :)
  - bluejekyll 10y ago
    I really should. I haven't had the time (caveat from my post above) :)
fauigerzigerk 10y ago
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 someone as proficient in the language as the original author. This aspect sometimes seems underappreciated by proponents of "powerful/expressive" languages.

saywatnow 10y ago

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 router. EDIT: this comes across pretty snarky - more so than is warranted. I'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.

StreamBright 10y ago
Depends on the situation, if you are in a server that needs to handle millions of requests and you create a million thread probably wont fly. If your concurrency is limited to a low enough number than you can create and terminate threads, so the proposed threading solution works well on mobile devices.
bluejekyll 10y ago
DNS gets so much blame, and yet so little time is spent to make it better. If DNS is that important to your application, you should install a caching resolver locally on your system.
pjmlp 10y ago
> 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/ http://www.microej.com/resources/supported-platforms/
- saywatnow 10y ago
  I don't understand the relevance?
  - pjmlp 10y ago

stevekemp 10y ago

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

tptacek 10y ago
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.
bluejekyll 10y ago
I had the same thought. I will say that that lack of progress may be the exact reason why so much consideration is being put into porting to another language, so as to make faster progress.
rev_null 10y ago
To be fair, this was written by ESR. His code to self-congratulatory ratio was pretty high to begin with.
- skj 10y ago
  I assume you mean low? :)
nimish 10y ago
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

IshKebab 10y ago

So I have to wonder about the performance difference between his sloccount and loc (https://github.com/cgag/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.

dcu 10y ago
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.
- j1f4 10y ago
  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.
  - dcu 10y ago
    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.
    - j1f4 10y ago
      If you are running the program with `cargo run` that takes the same --release flag. Could be the machine difference though.
      - dcu 10y ago
        I'm not. Are you testing with go 1.8 btw?

perlpimp 10y ago

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

gamesbrainiac 10y ago

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

LukeShu 10y ago
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`.

w8rbt 10y ago

What does he mean by this? "The language does have annoyances. The absence of const is a minor one." https://gobyexample.com/constants https://gobyexample.com/constants const s string = "constant"

peterwaller 10y ago
He's referring to it as a type qualifier, I would assume. https://en.wikipedia.org/wiki/Const_(computer_programming) https://en.wikipedia.org/wiki/Const_(computer_programming)
- w8rbt 10y ago
  Got it! Thanks for the clarification.
dllthomas 10y ago
I don't think he was complaining about the lack of a syntactic token reading "const", but rather the inability to protect values from modification (in certain contexts) without incurring the overhead of hiding them behind an interface.

edibleEnergy 10y ago

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. Now when I go back to python or perl (or javascript) I'm super conscious of the choices I make regarding type checking and parameter checking. [1]: https://www.bugreplay.com https://www.bugreplay.com

edibleEnergy 10y ago

tormeh 10y ago

>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. Wait until he realizes that Rust has channels, too. It's not as pure as Go's implementation, but it's a superset.

bborud 10y ago

I'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. For instance it took about 7-8 years before I switched to Java (and then only after establishing a programming style that doesn't rely on frameworks at all). The language wasn't hard to learn, but it took a while for the JVM and the standard library to get to where it needed to be. C++ never made the cut. Quite possibly because C++ is not really one 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've worked where I've consistently seen good quality C++ code). I'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'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'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. 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. I haven't used Rust yet. Mostly because I don'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 "for real". Go just might be my next "main language". (Actually, right now it feels like I'll switch to it and never go back, but the tiny rational bit of my brain says "oh yeah, here's a list of other times you had a good feeling about something that turned to crap" :-))

sanjayts 10y ago
Sorry if you saw this coming but do you really not miss generics and exceptions? I like Go given that it's a lean language and the compiles down to a self contained binary which doesn't consume gobs of CPU or memory and is pretty quick to start-up and run. Perfect language for writing command line tools and one-off network clients. But I dread the feeling of writing repetitive error handling code and copy-pasta to get a simple generic functionality to work across data types. Maybe I should just consider it a better C and move on...
- 10y ago