9 ms·

Maybe it's a biased and distorted perception that I have, but Go seems to be the most consistent and unsurprising language I've used, and I mean this positively

• pkaye 8y ago
  Our company uses Go. Most people who join have no experience in Go yet usually they can get comfortable with the language in 1-2 weeks to start contributing. I know nothing about Node/JS but I'm sure that takes much longer?
  • nostalgeek 8y ago
    > but I'm sure that takes much longer? Your people can pick up go reflect package or go routines/channels and co in 1-2 weeks and start contributing? impressive... most people can pick up for loops, if,switch statements, variable and function declaration in a week in any language as well... In fact, a lot of non programmers use JS regularly to write scripts in the browser. I imagine your people know how to program before hand... So what do you think takes longer to learn? mastering go threading model or being able to add interactivity to the DOM?
    • golangnews 8y ago
      go reflect is not commonly used, goroutines are pretty simple to pick up. I have used several large codebases with zero use of reflection. The point of go is it restricts you to 25 keywords (the basics that you sneer at above) so senior people can't get fancy and produce an impenetrable mess/marvel that beginners will take months to orient themselves in. It is definitely easier to write well than js IMO, and harder to make a big ball of mud in.
      • deleted 8y ago
        [deleted]
    • pkaye 8y ago
      > So what do you think takes longer to learn? mastering go threading model or being able to add interactivity to the DOM? For me, the go threading model is easier. I just can't stand DOM and web programming in general. Currently working on a problem doing some computation across dozens of cores on multiple servers and go makes it a lot easier to spawn the 1000 goroutines and coordinate between them. I guess everyone has different interests and perhaps it is similar for those we hire.
      • nostalgeek 8y ago
        > For me, the go threading model is easier. I just can't stand DOM and web programming in general. Because you didn't take the time to learn the DOM, that's all. I doubt learning a simple composite API made of dumb nodes is more difficult than writing thread safe programs in Go. I'm not talking about tastes or interests, I'm talking about ease of learning. Go isn't 'easy to pick up'. For loops, if statements and co are basic, and they are in all languages, that's my point. There is nothing particularly easy with Go.
  • stcredzero 8y ago
    Most people who join have no experience in Go yet usually they can get comfortable with the language in 1-2 weeks to start contributing. A lot of what makes anything hard to learn are the non-obvious gotchas. The design philosophy of golang is aimed at avoiding the non-obvious gotchas and the creep-up-on-you-at-scale gotchas.
    • solipsism 8y ago
      Except channels. If you use channels it's non-obvious gotchas galore.
      • stcredzero 8y ago
        Concurrency is hard. Channels make it somewhat easier. Basically, see if you can do concurrency with only synchronous code.
        • solipsism 8y ago
          Concurrency is hard and channels make it somewhat easier. Agreed. That's not relevant to the fact that the use of channels in Go is full of gotchas.
          • stcredzero 8y ago
            That's relevant to the fact that concurrency is full of gotchas. I also used Go to write an MMO all by myself. I think channels are great!
          • eudoxus 8y ago
            I think his point was that concurrency is riddled with gotchas regardless, and channels reduce them, but not remove them.
            • stcredzero 8y ago
              People completely misread my comment about doing concurrency with only synchronous code. Basically, channels let you do concurrency with only synchronous code as in Node JS, but without using callbacks.
  • aphexairlines 8y ago
    1-2 weeks is standard for all languages though. A week or less is how long it usually takes people at work to pick up Objective C and contribute to iOS development, or pick up Scala and contribute to service development.
• stcredzero 8y ago
  The problem with inconsistencies and surprises in languages, is that these are often the basis of conundrums that are more expensive to detect, figure out, and fix by a factor of 10X or more. I say this with appreciation and without irony: It turns out that "Blub" is actually a good thing, so long as it's done right. All languages are going to suck, somewhere. The trick is to actually optimize a language for the difficult, expensive parts of development. Many languages seemingly optimize for writing things from scratch slickly. They're "blog example optimized." Instead, languages should be optimized for debugging, reading code, and deployment. The fact that Go is not afraid of boilerplate is often actually a good thing. I've had to debug C++ in the confluence of 2 templates, such that there was no source code to display in the debugger. I don't expect to have this problem in Go, ever.
  • nine_k 8y ago
    There's a fine balance here. "You can't pay people enough to carefully debug boring boilerplate code. I've tried." (Yaron Minsky of Jane Street) While C++ goes to one extreme, not having certain expressive means (whatever they may be) has a price, and for certain kinds of problems, this price may be high. This returns to the idea I very much agree with: "The trick is to actually optimize a language for the difficult, expensive parts of development." The catch is that difficult parts are also problem area-dependent. Go definitely found a sweet spot for certain kinds of problems, though.
    • pjmlp 8y ago
      Go is what Java 1.0 should have been. Question is, how it will move beyond that, if ever.
      • nine_k 8y ago
        Go the language now is indeed very similar to Java pre-1.5, but with a better OOP story, and a much better concurrency story. I still think that JVM + JIT is hugely important, though. Now it's importance is somehow diminished by presence of LLVM, but 20 and even 10 years ago the situation with native compilation was different. (I know that the canonical Go compiler does not use LLVM.)
• sbjs 8y ago
  Meh, everyone has a preferred type of language they find least surprising. To many Ruby is the least surprising, and Matz used "principle of [his] least surprise" as a guiding principle when designing it, but many other people find it enigmatic and confusing. Some people find Haskell the least surprising and most consistent, others say Java is. Every language has caveats and inconsistencies, even Go. Like how Go has generics, but only for two or three built-in types. It seems to be more about the person trying out the language than the language itself.
  • sbjs 8y ago
    The article has two examples of how I already find Go to be inconsistent and/or surprising: w, err := b.NewWriter(ctx, "gopher.png", nil) ... _, err = w.Write(data) ... if err := w.Close(); err != nil Why is := used on the first line but = used on the second line, and then := used again on the third line? I get that you use := when introducing a new variable, and = when just assigning, the third line is not really introducing a new variable, since err is still in scope... or is it? Not to mention, what is the last argument `nil` supposed to represent? In most high quality Node.js libraries, functions/constructors will take an optional options object so you can omit it, or pass an object like { timeout: 300 } to it.
    • elithrar 8y ago
      > the third line is not really introducing a new variable, since err is still in scope... or is it? The "if" block creates a new scope.
    • skj 8y ago
      The third line has a new err inside the if statement's scope. It's equivalent to { // begin new scope here err := w.Close() if err != nil { foo } else { bar } }
    • deleted 8y ago
      [deleted]
    • ssambros 8y ago
• paulddraper 8y ago
  > unsurprising language --- This is a valid Go program. import "fmt"; func main() { fmt.Println("Hello world") } This is an invalid Go program. import "fmt"; func main() { // fmt.Println("Hello world") } Surprising. --- Creating typed general-use data structures is impossible. Surprising.
  • tree_of_item 8y ago
    Nope, you have to use imports. It's a little annoying but not "surprising" since the language shoves it in your face right away.
    • paulddraper 8y ago
      You're correct. I was in no way surprised by this language feature, and neither were any of my coworkers. Go is a thoroughly "unsurprising" language.
      • 0xdeadbeefbabe 8y ago
        Rave about porting cat to go and we'll restore your karma.
        • paulddraper 8y ago
          Maybe I should also blog about how I was able to keep the size increase under 50x.
      • erik_seaberg 8y ago
        A fatal error that prevents deployment is a lot more surprising than a warning.
        • bschwindHN 8y ago
          You shouldn't even be at the point of attempting a deploy if your code doesn't compile.
• pmontra 8y ago
  For me the big surprise is that we still have languages where we have to write things like func setupBucket(ctx context.Context) (*blob.Bucket, error) { sess, err := session.NewSession(&aws.Config{ Region: aws.String("us-east-2"), }) full of ( ) { } * and & as if we were still in the 80s. So Go is a very surprising language, but this is highly subjective. No hard feelings.
  • didip 8y ago
    For a statically typed language, the number of sigils Go have is surprisingly low.
  • tapirl 8y ago
    Most popular languages are full of (). Most popular languages are full of {}, except python. All C family languages are full of *. I can't see any surprises here.
  • robbrit 8y ago
    You're right, it is dependent on your perspective. Go is intended to be unsurprising to developers who want to just be able to look at code and have a good idea of what it does. Punctuation is very useful to get rid of ambiguity. Contrast this with a language like Ruby which tries very hard to make punctuation optional, and often ends up with ambiguous cases where you aren't 100% certain how the interpreter will parse some code and so you end up throwing in all the punctuation anyway.
  • deleted 8y ago
    [deleted]
  • notdang 8y ago
    I prefer it like this instead of relying on indentation
• outworlder 8y ago
  It is so consistent and unsurprising to the point of being boring. Which is a quality I have never thought I would appreciate, but if I am at work I do. It's very utilitarian. I'll take Scheme for a spin if I am doing something for fun. EDIT: %s/bored/boring/g
• untog 8y ago
  Go is certainly very easy to reckon with. But I was surprised at how little O cared for it when I tried it, given the hype I'd heard. The two things that immediately jumped out at me were error handling and generics. I understand both were deliberate choices but I'm still surprised they were made - I've been working with Swift a lot lately and it just feels like it makes so much more sense to me. I do love how opinionated Go is, though. Every language should have a gofmt equivalent.
  • symlock 8y ago
    Yes, gofmt is a wonderful since so many other languages can have very different way of writing code leading to harder-than-necessary digestion of new libs or projects.
  • cloverich 8y ago
    I feel like a caveman typing out error handling code in go, but on the other hand (even as a beginner in Go) I _never_ run into unexpected conditions. There's tradeoffs of course but every time I find myself thinking about what kinds of error conditions may be happening in my Node code (where I spend most of my time), and whether I covered them all... i think I'd trade.
    • herval 8y ago
      I keep shooting myself in the foot _the same way_, all the time - and it's incredibly easy to do so: - not knowing if "Foo" being returned is a struct or an interface, so you're not sure if you should "if foo != nil" (it could not be nil if it's a struct) - channels freezing (specially unbuffered ones). I still can't figure out how to debug those well. - (the most common of all) spawning goroutines on a for loop, and all of them closuring over the same value (instead of one per item on the loop) it's a surprising amount of sharp edges, for such a tiny language...
      • gant 8y ago
        1. Get IDE support. There is no convention of adding a suffix like "Interface", and I personally am very happy with this. C# ISomething naming conventions have annoyed me quite a bit. 2. Always limit the scope of your channels. I like using unidirectional channels with structs that have more unidirectional channels. (For instance, a chan of workRequest{workData, returnChan} where return chan only receives responses for this request and is closed when no values are left) 3. I think you've been treated to well by JS closures, always hand over arguments you're going to use in the goroutine, this also allows the CG to clean up the stack of the function that started the closure goroutine.