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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

311–318 of 318 posts

Re: Seven years of Go

#311

Post by lomnakkus »

mjburgess wrote: post #309
defgeneric wrote: post #290

Earlier quoted context omitted.

> That sounds like a deepity[1] if ever I've heard one. Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. Not concerned with the…

In my experience Haskell-people are not insuffereable, but have a history of a rather academic humility in the same manner that, historically, the ruby community used to. Perhaps this is changing, but my guess is the prior comment was by a person who appeals to Haskell more often than uses it.

> my guess is the prior comment was by a person who appeals to Haskell more often than uses it.

Two points:

One, I'm not keeping an exact score of how often I mention Haskell vs. use it, but I can assure you that I use Haskell almost every single day.

Two, this constant anti-academia thing is really getting tiresome at this point... but just for the record: I've never worked in academia and didn't even encounter Haskell until I was out of university. My interest and praise for Haskell (and Ocaml) is entirely based on practical experience.

Re: Seven years of Go

#312

Post by lomnakkus »

defgeneric wrote: post #290
lomnakkus wrote: post #235

Earlier quoted context omitted.

> While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. That sounds like a deepity[1] if ever I've heard one. Just to add something a little more substantive: It may not be obvious at first sight (esp. in e.g. C++ or Java), but 'generics'/'parametric polymorphism' can actually incredibly powerful at restricting what your prog…

> That sounds like a deepity[1] if ever I've heard one. Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase. Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming. Not concerned with the…

> Your code becomes less peculiar to you and more in line with the peculiarities of the language as it's used by most people. Shallow enough? Don't let an allergy to postmodernism become an allergy to a turned phrase.

I'm objecting to the attempt at sloganization as if witty/clever phrases mean anything. FTR, I also think this is a bad thing in FP. My "favorite" example being "if it compiles, it works" (or similar).

> Not sure what the rest of your comment has to do with my point, which was about, if you like, the pragmatics of programming.

My point, though perhaps somewhat obscure, was that eliminating a lot (i.e. "classes") of bugs up front (e.g. by exploiting parametric polymorphism) means that you spend less time fixing bugs... which means that you spend more time getting things done.

(Now, the jury is still out on whether static type checking leads to more productivity than dynamic type checking, but given that you're interested in Go, I'm guessing you're probably leaning towards 'static' anyway.)

> Not concerned with the space of programs that type check. Insufferable haskellers...

I used Haskell (and ML, you'll notice) as an example, but if you're not concerned with the space of programs that type check -- why are you even using a statically checked language? Surely you'd be infinitely more productive in a dynamically checked language? I'm saying you should be concerned and demand concern from the designers of your language.

Re: Seven years of Go

#313

Post by petre »

dilap wrote: post #30
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

i love go, but follow rust with a lot of curiosity. a very interesting language, and much more ambitious than go. when i've played with it, one thing that was always a big turn-off for me was super-long compile times. as someone who used to do a lot of c++, i am loathe to go back to a language with long compile times, no matter how good the language...

Have you tried D?

Re: Seven years of Go

#314

Post by petre »

zeveb wrote: post #35
barrystaes wrote: post #12

These big funny logos, illustrations, and memes appearing in todays technology websites & videos really dont help for office environments. :( Colleagues should not visit websites littered with memes and cute drawings, but i do.

I love the look of the Go gopher, but you're not wrong. There's nothing wrong with having a little fun, but there is something wrong with prolonged immaturity. Where's that line? I don't know. Is the Go's use of the gopher on one side or the other of that line? I honestly don't know.

I think the Perl/OCaml camels or the Swift swallow logo are that line. They're not cartoon characters or a cute looking animals like the Go gopher which is both a cartoon and a cute animal.

Re: Seven years of Go

#315

Post by dilap »

petre wrote: post #313
dilap wrote: post #30

Earlier quoted context omitted.

i love go, but follow rust with a lot of curiosity. a very interesting language, and much more ambitious than go. when i've played with it, one thing that was always a big turn-off for me was super-long compile times. as someone who used to do a lot of c++, i am loathe to go back to a language with long compile times, no matter how good the language...

Have you tried D?

i have not. should i?

Re: Seven years of Go

#316

Post by petre »

dilap wrote: post #315
petre wrote: post #313

Earlier quoted context omitted.

Have you tried D?

i have not. should i?

You should definitely try it as it's easy to interface with C/C++ and the compile times are short, maybe comparable to Go. Also they fixed a lot of C++ annoyances and the language is older and definitely more mature than Rust. It's garbage collected, but you can also do manual memory allocation, although standard library support for that is rather lacking. Unlike Go, It also has a package manager called DUB.

http://dlang.org/overview.html

https://www.quora.com/Which-language-has-the-brightest-futur...

I'm playing with it using LDC2 (Clang), not the standard DMD compiler. LDC2 generates smaller binaries from what I saw.

Re: Seven years of Go

#317

Post by di4na »

weberc2 wrote: post #303
di4na wrote: post #270

Earlier quoted context omitted.

You would be surprised by the result. Economically it make sense. And i would argue that production ready Elixir/erlang is easier to teach than production ready Go.

Still, I'm fairly risk averse. I'll wait for the inevitable explosion of Erlang/etc shops to take off before I jump on board.

It happened. But well. Do as you want. It is your project :)

Re: Seven years of Go

#318

Post by wtetzner »

weberc2 wrote: post #266
wtetzner wrote: post #260

Earlier quoted context omitted.

Wow. That seems very complicated for an implementation of map(). It seems like this is a perfect example of how generics are a productivity feature.

It's complicated because the reflect library is very general. There's no need to repeat most of this. So in fact, it's a perfect example of how functions are a productivity feature.

I would argue it's both.
Post reply on HN