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

"14 Years of Go" by Rob Pike

codereliant.io

Post reply on HN
Print view View original

31–40 of 75 posts

Re: "14 Years of Go" by Rob Pike

#31

Post by microtonal »

tsimionescu wrote: post #26
ogogmad wrote: post #17

Lack of support for operator overloading is a bit sad. As a result, Go can't get used in numerical applications, unless you like writing `matrix_plus(A, B)` instead of `A + B`. Is there a programming language that has a "simple" design like Go but which supports some operator overloading?

Adding matrices with A+B looks nice. But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway, or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc. Update: corrected * representation

You can have your cake and eat it. E.g. C++ expression templates allow you to fuse application of multiple operators.

Re: "14 Years of Go" by Rob Pike

#32

Post by sph »

microtonal wrote: post #31
tsimionescu wrote: post #26

Earlier quoted context omitted.

Adding matrices with A+B looks nice. But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway, or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc. Update: corrected * representation

You can have your cake and eat it. E.g. C++ expression templates allow you to fuse application of multiple operators.

Yes that's the plus of using a language that supports every single paradigm ever invented. I hear that they'll add S-expressions in the next version. [1]

Jokes aside, that is pretty cool, I didn't know C++ templates did that.

1: btw Lisp could do that as well, if they wanted. C++ supports thousands of syntax features, Lisp supports infinite.

Re: "14 Years of Go" by Rob Pike

#33

Post by jimbob45 »

ogogmad wrote: post #17

Lack of support for operator overloading is a bit sad. As a result, Go can't get used in numerical applications, unless you like writing `matrix_plus(A, B)` instead of `A + B`. Is there a programming language that has a "simple" design like Go but which supports some operator overloading?

I think the right answer to your question would be NimLang[0]. In reality, if you're seeking to use this in any enterprise context, you'd most likely want to select the subset of C++ that makes sense for you or just use C#.

[0]https://nim-lang.org/

Re: "14 Years of Go" by Rob Pike

#34

Post by iamcalledrob »

Go is brilliant for what I don't have to do.

Go doesn't have a build system, so I don't have to learn that. (I spend every second I'm using Gradle to curse it's very existence -- and wish I had `go build`)

Go cross compiles natively, so I don't have to think about the toolchain.

Go has go:embed, so I don't have to think about bundling/packaging as a separate step.

Go has fantastic backwards compatibility, so I don't have to spend time getting an old project to even build.

Go's stdlib is extremely high quality, so much so that I've never run into a serious bug in it.

When jumping into other ecosystems, I'm shocked at how much time is spent fiddling with build scripts, packaging, deprecations, unfixed bugs in the tooling etc...

Still wish it didn't explode on null pointers though. And any large dependency authored by Google will be unidiomatic and over-complex, of course (see: grpc)

Re: "14 Years of Go" by Rob Pike

#35

Post by mattgreenrocks »

tikhonj wrote: post #18
cyberpunk wrote: post #2

[dead]

> Performance is good enough, it's not the intellectual masturbation of Scala or Rust. As we know, any technology that would require experienced programmers to learn something is a crime against engineering.

It’s also really gross how we want ultra prescriptive tools that force you to write things certain ways because we can’t trust our own coworkers to write decent code. Or learn things for that matter. I guess people don’t do code review at all?

This was tried before and it was called Java.

But there’s always an eager generation of naive programmers willing to believe the lie that this time is different.

Re: "14 Years of Go" by Rob Pike

#36

Post by anonymoushn »

campbel wrote: post #22
ogogmad wrote: post #17

Lack of support for operator overloading is a bit sad. As a result, Go can't get used in numerical applications, unless you like writing `matrix_plus(A, B)` instead of `A + B`. Is there a programming language that has a "simple" design like Go but which supports some operator overloading?

I'm really not a fan of small qol features like this. I think it really hurts readability for the general audience. The function itself is minimal overhead and is clearer to the reader.

That's true, we should get rid of operators for primitives too.

Re: "14 Years of Go" by Rob Pike

#37

Post by ogogmad »

campbel wrote: post #27
ogogmad wrote: post #25

Earlier quoted context omitted.

The world seems like it's moving to ML. That needs matrices, complex numbers, autodiff, different fixed/floating point types. All four of these need operator overloading.

Could you explain _why_ they need overloads and functions don't work? That does not immediately follow for me.

Autodiff requires interpreting the same piece of code using "dual numbers" that would normally expect "real numbers". This needs operator overloading combined with generics.

Re: "14 Years of Go" by Rob Pike

#38

Post by ogogmad »

yangl1996 wrote: post #29
ogogmad wrote: post #25

Earlier quoted context omitted.

The world seems like it's moving to ML. That needs matrices, complex numbers, autodiff, different fixed/floating point types. All four of these need operator overloading.

Your last sentence seems fishy to me. Are you suggesting that support for C++ like operator overloading is a necessary condition for, say, autodiff? I thought Go is a Turing complete language.

Operator overloading is about syntax and type safety. Brainfuck is Turing complete.

Re: "14 Years of Go" by Rob Pike

#39

Post by [deleted] »

iamcalledrob wrote: post #34

Go is brilliant for what I don't have to do. Go doesn't have a build system, so I don't have to learn that. (I spend every second I'm using Gradle to curse it's very existence -- and wish I had `go build`) Go cross compiles natively, so I don't have to think about the toolchain. Go has go:embed, so I don't have to think about bundling/packaging as a separate step. Go has fantastic backwards compatibility, so I don't…

[deleted]

Re: "14 Years of Go" by Rob Pike

#40

Post by johndough »

tsimionescu wrote: post #26
ogogmad wrote: post #17

Lack of support for operator overloading is a bit sad. As a result, Go can't get used in numerical applications, unless you like writing `matrix_plus(A, B)` instead of `A + B`. Is there a programming language that has a "simple" design like Go but which supports some operator overloading?

Adding matrices with A+B looks nice. But then you'll soon want to do A*B+C, and you'll find that fused multiply/add is a much faster operation than doing a multiplication and then addition, and soon you'll either be writing mul_add(A, B, C) anyway, or you'll overengineer a complex solution to make A*B return some kind of object that can recognize the subsequent + operation etc. Update: corrected * representation

Do fused multiply-add operations for matrices really matter? There are two relevant cases I could come up with.

1. You have large matrices. In this case, I'd think that the O(n^2) addition can be ignored, because it gets dwarfed by the the O(n^3ish) multiplication.

2. You have small matrices. In this case, the computation is likely bound by memory bandwidth. Waiting for the matrices A and B takes most of the time. Then you multiply them, which should go quickly, since the matrices are small. Then you do the addition with the matrix C, but since the product AB is already in cache and since you'd have to wait for the matrix C anyway, there is not much to be gained with a fused multiply-add.

Post reply on HN