Live data from Hacker News

"14 Years of Go" by Rob Pike

codereliant.io

21–30 of 75 posts

Re: "14 Years of Go" by Rob Pike

#21
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?

You might be interested in Odin. It's very focused on numerical computing and has certainly taken some design hints from Go

Re: "14 Years of Go" by Rob Pike

#22
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.

Re: "14 Years of Go" by Rob Pike

#24
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?

> Is there a programming language that has a "simple" design like Go but which supports some operator overloading?

Think that one through again

Re: "14 Years of Go" by Rob Pike

#25
post #22
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.

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.

Re: "14 Years of Go" by Rob Pike

#26
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

Re: "14 Years of Go" by Rob Pike

#27
post #25
post #22

Earlier quoted context omitted.

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.

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.

Re: "14 Years of Go" by Rob Pike

#28
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

RETVRN TO GEOMETRY

https://en.wikipedia.org/wiki/Planar_ternary_ring

If you look at the section to do with geometry, you'll see that Fused Multiply-Add T(a,m,c) is the value of y given x where y=mx+c, where the latter is clearly just a line that's not parallel to the y-axis. You may thank me now.

Re: "14 Years of Go" by Rob Pike

#29
post #25
post #22

Earlier quoted context omitted.

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.

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.

Re: "14 Years of Go" by Rob Pike

#30
Rob Pike posted a textual version of this on his own blog: https://commandcenter.blogspot.com/2024/01/what-we-got-right... Discussed at the time:

Go: What we got right, what we got wrong - https://news.ycombinator.com/item?id=38872362 - Jan 2024 (694 comments)

The outline of that post is very clear, you can skim the original very quickly.

That link is conspicuously missing here, giving readers the impression that the talk is only available in video form. Not cool.

Post reply on HN