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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

331–340 of 402 posts

Re: The State of Go

#331

Post by ridiculous_fish »

Cthulhu_ wrote: post #165
skybrian wrote: post #83

Earlier quoted context omitted.

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

It does though. Maps and folds - and functional programming in general - focuses on the /what/. For-loops on the other hand tell the compiler / cpu the /how/. Summing is a nice example. A naive for-loop will just iterate through the list, keep a variable around, add the next item in the list to it. In functional programming (or with a reduce), you tell it to sum in a more concise way - but more importantly, you don't…

Consider product as a counter-example. With an imperative loop, it's easy to add an early-out condition if zero is encountered. But this is harder to do in a (strict) functional language.

Re: The State of Go

#332

Post by wtbob »

This slideshow doesn't work on narrow browsers: a narrow browser window clips the text, despite there being more than enough window space to display all the information on the slide.

Remember when the Web was automatically adaptive? Remember when we preferred HTML to PDF because it adapted?

Re: The State of Go

#333

Post by Kexoth »

spraak wrote: post #121

I'm yearning for the Golang of functional programming. That is, excellent std lib, clear documentation, awesome tooling, active community.. and after typing this, maybe that's Elixir? Though I do love static typing.

I was thinking about this a year ago & decided on Elixir. So far I have no regrets. As you mentioned Elixir satisfies all the conditions you mentioned. For the static typing part, I agree. But since there's no OOP, the flow of the information throughout the app is pretty explicit & the reasoning behind it is easy to be debugged.

Re: The State of Go

#334

Post by mrcactu5 »

i love languages and i am enjoying seeing Go mature as a language. At the moment I do have my hands tied with Elm and Haskell.

Originally I am a Python programmer. Any advice for people transitioning for Python? What are some of the advantages of Go?

Re: The State of Go

#335

Post by zik »

aeturnum wrote: post #86
artursapek wrote: post #20

Earlier quoted context omitted.

What on earth is a "good" language? > you're clearly pitching for that vast bulk of mid-quality developers that make up the huge middle chunk of corporate devs That was actually something Google aimed for with Go, and I don't see what is shameful about it. It's a simple language on purpose. It is meant to be easily learned by any developer, and similarly Go code is meant to be easily read. Also, what sets Go apart fo…

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars. Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's…

> Go, however, is like a Toyota Corolla or a Honda Civic.

The only problem with this argument is that everywhere - even in this thread - there are people saying that Go is a joy to program in. It's not lacking magic, it's magical in its own right.

A better car analogy would be that Go is a Lotus Elise. It's nowhere near as powerful as your friend C++'s Mustang or Rusty's McLaren. But to C++ and Rusty's dismay Go's little Elise still gets around a racetrack crazy fast. It may have a smaller engine but it's just taken a really different approach to going fast which works really well. And Go has a much more pleasant time getting to his destination than C++ and Rusty do.

Re: The State of Go

#336

Post by im_down_w_otp »

Kexoth wrote: post #333
spraak wrote: post #121

I'm yearning for the Golang of functional programming. That is, excellent std lib, clear documentation, awesome tooling, active community.. and after typing this, maybe that's Elixir? Though I do love static typing.

I was thinking about this a year ago & decided on Elixir. So far I have no regrets. As you mentioned Elixir satisfies all the conditions you mentioned. For the static typing part, I agree. But since there's no OOP, the flow of the information throughout the app is pretty explicit & the reasoning behind it is easy to be debugged.

There is static type checking/analysis available. Just use Dialyzer.

Re: The State of Go

#337

Post by peteretep »

zik wrote: post #335
aeturnum wrote: post #86

Earlier quoted context omitted.

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars. Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's…

> Go, however, is like a Toyota Corolla or a Honda Civic. The only problem with this argument is that everywhere - even in this thread - there are people saying that Go is a joy to program in. It's not lacking magic, it's magical in its own right. A better car analogy would be that Go is a Lotus Elise. It's nowhere near as powerful as your friend C++'s Mustang or Rusty's McLaren. But to C++ and Rusty's dismay Go's li…

Some people find dull cars a joy to drive.

Re: The State of Go

#338

Post by leshow »

cube2222 wrote: post #213
leshow wrote: post #168

Earlier quoted context omitted.

> Errors are just a worse Either monad after allm they're much more pleasant to use than exceptions. How are errors in Go at all monadic? They just have a convention where you return a tuple and manually check if something isn't nil. Either type will inhabit one variant or another, not both with one having a value of nil. The 'monadic' part of Either (or Result in something like Rust, where try! is sort of like >>= i…

As I said, in practice they're a worse either monad. With which I meant -> they were inspired by them, but lack the monad part and having the value with the error in one object interchangeably. It's the same treating errors as values though.

It's really just a worse Either type, if anything, there's nothing monad about it. Although it's sort of hard to be close to an Either without being an algebraic data type. But I see what you're trying to say.

Re: The State of Go

#339

Post by Cyph0n »

enneff wrote: post #301
Cyph0n wrote: post #291

Earlier quoted context omitted.

> Can any of those tools execute code from within the slides? > And do they let us store our code snippets in actual testable (or at least buildable) source files? Not that I'm aware of, no. That's a pretty cool feature actually! As you kindly said, Reveal.js may probably work for you as a frontend for your tool.

Those features were the impetus for the tool, and as far as I'm aware they were Not Invented Anywhere at the time. :-)

I guess I missed those features at first glance. I apologize for that.

Re: The State of Go

#340

Post by pvg »

coldtea wrote: post #320
pvg wrote: post #295

Earlier quoted context omitted.

So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced. It's just not a precisely defined technical term and in a computer language really has more to do with the intent and purpose of the designers and implementors and the operational context than things like 'has manual memory management' or 'must be used for writing an actual oper…

> So it's not constrained to operating systems but it's pretty much constrained to operating systems. You can see how I'm less than convinced. It's just that operating systems is not just the kernel. The POSIX userland of tools (ls, cat, ps, etc) are also systems programming, and essential part of an OS. And of course device drivers (which they even get linked or loaded directly to the kernel). Postgres, Varnish, red…

The definition of 'systems programming' is certainly wooly (and predates all of your examples) but I don't think it's an iterative stochastic hairsplitting fractal, like you're proposing. You've basically argued your way to a corner in which varnish and apache are not 'systems programming'. That's not a sensible use of the term.
Post reply on HN