Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First chapter of Kernighan and Donovan's new Go book [pdf]

gopl.io

Post reply on HN
Print view View original

201–210 of 233 posts

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#201

Post by 15155 »

staticint wrote: post #122
15155 wrote: post #95

Earlier quoted context omitted.

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly. The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with num…

> It is not like someone is going to manually write out identical functions twenty times for each type they want to support.

I'll stop you right there. Have you seen a modern Go codebase?

They most certainly duplicate the simplest of functions, resort to `go generate`, or use reflection.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#202

Post by 15155 »

AnimalMuppet wrote: post #109
15155 wrote: post #95

Earlier quoted context omitted.

I wonder how much developer time is spent due to a lack of generics. Developer time costs more than compiler time.

> Developer time costs more than compiler time. I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler ti…

> Worse, the developer time you spend due to lack of a feature, you spend while writing some code that would benefit from the feature. The compiler time you pay every time you compile - year after year, for some projects.

Except that this is a false dichotomy: you don't have to have a lack of features to get a fast compile. Incremental compiles have existed for a very long time in various language ecosystems and will achieve very acceptable results.

In addition, SSDs and multicore CPUs can be leveraged to decrease compile times, and these things are only getting better.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#203

Post by agentgt »

chimeracoder wrote: post #30
bdamm wrote: post #27

Earlier quoted context omitted.

100x? Even 10x is very significant. Why is it that you feel so much more productive in Go? Is it ease of refactoring? Lack of frustrating bindings bugs? Something else?

Yeah, I know 100x is a huge multiplier, but I've actually tracked myself to the extent possible, and that really is the right order of magnitude for me. There are a number of reasons. I find refactoring is way, way simpler. Refactoring in Python feels painful enough that I always put it off until it gets absolutely necessary. With Go, I find it takes way less time, and also less mental energy. The static typing and s…

I agree that static typing at least for me gives massive reduction in time in medium to large projects. And despite what many think about Java I am able to be a multiplier faster than Python with it (I would say as much as 4x at times).

What I don't understand is all these people claiming that the language is slowing them down by massive factors. I guess I'm either incredibly stupid or people on HN are incredibly smart (probably both) but I just can't even think fast enough for the syntax of the modern languages to really slow me down (ignoring copy n' paste exceptions and build time issues). For example to create the mental model of a dumb video game I'm making is taking more time than the actual coding.

In fact I would say if anything slows me down its bugs and/or features missing in immature open source libraries, crappy tooling, and lack of documentation and most importantly not fully understanding the problem (or what to create in terms of video game). And I can say this definitively about Rust... the language is awesome but I'm slow as crap in the language because of random stuff breaking and lack of good libraries.

I'm not saying Go has the above issues (on the contrary it now is rather mature) but I have hard time believing the 100x (and that is my opinion :) ) of going from problem to fully coded solution.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#204

Post by e12e »

twic wrote: post #118
sinatra wrote: post #90

This is a good place to ask this (because Go posts attract a lot of commenters, even those who dislike Go and like some other language): Which language/framework would you choose today for writing WebServices? Preferably with the following characteristics: static type (or at least static analysis), easy deployment (ex, generates a single binary like in Go), supports concurrency very well, is small/simple, has good to…

Java. Static types (less sophisticated than state of the art, more sophisticated than Go), fairly easy deployment (you can easily make a package with everything except the JVM, so it's your one binary + /usr/bin/java + libjli + lib{c,dl,pthread,z}), concurrency is state of the art (whether old-school threads-and-locks with java.util.concurrent, actors with Akka, fibres with Quasar, whatever you like), is a quite smal…

If going down this route, I'd probably look into using Kotlin with dropwizard, rather than Java. Maybe it's just me, but the amount of code you have to write in Java that really should be auto-generated (and often is, by an IDE) is absurd.

I've not toyed extensively with Kotlin yet, but so far it does look like a "modern Java done right". Most of the code you don't actually need to write, or read -- like getters and setters that just get and set.

And it's close enough to plain Java that there's little overhead, and not a whole new language -- like with Scala, or Clojure.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#205

Post by tracker1 »

MichaelGG wrote: post #170
tracker1 wrote: post #156

Earlier quoted context omitted.

It depends on the use case... C# is a wonderful language, since the addition of generics and lambdas, it's downright beautiful to work with. But this does come with a cost... Even a simple hello world console app has a pretty significant spin up time compared to go, or anything that is truly compiled. In some cases, if you have long-lived services, then Java and .Net make sense... You can get farther with the code in…

I cannot find any reason to believe that lambdas have anything, at all, to do with sin-up time. A hello world console app wouldn't even be using them much (closures are just objects so...). And I doubt generics make a significant difference in runtime but I don't have a CLR v1.1 around to test it out. For comparison, a C# hello world takes about 10ms longer than a C one (both compiled with optimizations; .NET 4.6 C#…

I wasn't saying lambdas are a reason that it's slower.. only that it was a feature that made it really nice to work with.

I remember the difference being a bit more than that, on the order of half a second in difference.. but that was around the .Net 1.0 timeframe.. I still used it for a lot of things because it didn't matter to me.. but a couple of things I wanted to use it for at the time was too much lag for starting an EXE and getting output from the command prompt.. running as a service was a different story.

A 1.2Ghz early Athlon was a lot slower than what we have today as well... even so, depending on what you need, even 10ms can make a difference.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#206

Post by AYBABTME »

jerf wrote: post #141
yokohummer7 wrote: post #64

Earlier quoted context omitted.

> no default parameter values Hearing this leaves a bad taste in my mouth, because one of the (mis)features I've found in Go is its implicit default value in struct initialization. In Go, you don't get a compile error when you miss some fields while initializing a struct. e.g. type T struct { a int b string c float64 } t := T{c: 1.5} will happily set `t.a` to 0 and `t.b` to an empty string. While this is useful for m…

I should explicitly state I seem to be in the minority in the Go community here, but: You don't get a compiler error if you initialize by name. You do get a compiler error when you initialize by position. In my minority opinion, you can and should use that to your advantage whenever possible. Some structs are clearly "configuration-like", for instance, and you don't want an error if a new option shows up, which will…

That's a pretty risky thing to do.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#207

Post by e12e »

fsloth wrote: post #36

Would Go provide a viable alternative to C++ for numeric and computer graphics 'kind of stuff'? I have no problem with C++ but the better-than-python proclamations got me intrigued.

I would guess Julia (or D) today, perhaps Rust in the not so distant future. I'm not sure if Go will ever be a good fit if you need really high and/or deterministic performance?

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#208

Post by staticint »

15155 wrote: post #201
staticint wrote: post #122

Earlier quoted context omitted.

I imagine not that much in practice. It is not like someone is going to manually write out identical functions twenty times for each type they want to support. That's precisely what computers are good at doing and there are countless tools to do it painlessly. The bigger problem is that Go doesn't have type inheritance or similar. Meaning, there's no great way to say that this generic function will only work with num…

> It is not like someone is going to manually write out identical functions twenty times for each type they want to support. I'll stop you right there. Have you seen a modern Go codebase? They most certainly duplicate the simplest of functions, resort to `go generate`, or use reflection.

I am afraid I am not entirely sure of what you are trying to get across here. Your mere mention of go generate indicates to me that you do understand my point about computers being able to free the programmer from doing the drudgery of implementing the same generalized function twenty times. And since you are familiar with go generate, I expect you also realize there are seemingly endless tools that exist to solve this specific problem.

I _think_ what you are trying to say is that templates in Go are less convenient than in some other languages. That is a completely fair assertion. But the idea of having to type `go generate` occasionally adding significant man hours to a project seems a little far fetched. You could even:

  alias go='go generate && go'
I completely understand the appeal of templates/generics being a first-class language feature. Not even the Go authors themselves discount the usefulness. I don't understand why the lack of them is adding so many more man-hours to your projects? The overhead of working around the lack of them should not be that significant, even if less pleasant.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#209

Post by JonahBraun »

api wrote: post #178
MikeTaylor wrote: post #176

Earlier quoted context omitted.

Never gonna happen, Go 2 is considered harmful.

This is one of the things I like about Go: it's "done." In exchange for passing on extensions that might make certain use cases easier, we'll avoid the bloat and have decades of backward compatibility. We just came out of a decade of nifty language mania. What I learned is that languages are boring but problems are interesting. Algorithms and solutions are interesting. A great solution to a challenging problem is rea…

You missed the joke re: Go 2.

I don't think Go is done. The active development speaks otherwise.

Re: First chapter of Kernighan and Donovan's new Go book [pdf]

#210

Post by lmm »

tracker1 wrote: post #156
lmm wrote: post #132

Earlier quoted context omitted.

> I find that to be a very odd statement. Usually, the developer waits for the compiler in order to find out if the code compiles and executes properly. That is, every minute of compiler time costs a minute of developer time. If your business starts to hit a wall on compile times you can buy a computer that can compile twice as fast. It's much harder to buy a developer who can think twice as fast. And every year the…

It depends on the use case... C# is a wonderful language, since the addition of generics and lambdas, it's downright beautiful to work with. But this does come with a cost... Even a simple hello world console app has a pretty significant spin up time compared to go, or anything that is truly compiled. In some cases, if you have long-lived services, then Java and .Net make sense... You can get farther with the code in…

I don't think it has to be a tradeoff though. Look at OCaml or possibly D - decent type system, fast compilation and fast runtime performance. And I'd expect Rust to do even better.
Post reply on HN