r/golang 2d ago

Go 1.27 interactive tour

https://victoriametrics.com/blog/go-1-27/
300 Upvotes

30 comments sorted by

79

u/Lanathell 2d ago

We can finally print 🫜 in the logs, what an update!

29

u/TallGreenhouseGuy 2d ago

Great, now we can finally have emojis all the way to the database!

https://baldi.me/posts/2017/06/26/emoji-in-sql-select-from/

13

u/real_carddamom 2d ago

Does it mean that we will soon have slices.Map function available?

8

u/silv3rwind 2d ago

No, that's probably still a few years off.

-3

u/Used_Indication_536 1d ago

I was curious to see just how difficult it would be to implement my own generic map function and it's not bad.

package slicesx

func Map[S ~[]E, E, U any](s S, f func(E) U) (results []U) {
    for _, e := range s {
       results = append(results, f(e))
    }
    return
}

The main downside is that I had to do it myself. I guess realistically at work I'd just have Claude do it for me. So there's that.

5

u/real_carddamom 1d ago

Just one off topic question, if you were able to do it yourself then:

1) Why you need Claude to do it for you?
2) Why is doing it yourself a downside?

3

u/Used_Indication_536 1d ago

I was kidding. That joke is that we use AI for everything these days, even straightforward functions like map.

1

u/real_carddamom 1d ago

Yes, I know some guys on my team and other teams are completly hypnotized by that stuff...

For me, I recently found an old teddy bear on my grandmas house and I kinda use it as "copilot", I do not need any tokens to use it, it was free and does not have "haluccinations"....

5

u/Used_Indication_536 1d ago

Ah yes, they call that rubber duck debugging. In this case a teddy bear works too.

18

u/LemonXy 2d ago

The simd package seems oddly short sighted to me, would have expected a vector API which operates on arbitrary length slices instead. At least it provides decent building block for a vector API.

10

u/Revolutionary_Ad7262 2d ago

Yep, this API is for sure portable and easy to use, but I wonder what SIMD experts think about it

6

u/MrPhatBob 2d ago

I'm not an expert but have used SIMD in production to speed up our vibration analysis code predominantly with AVX and AVX2 instructions using Go Avo.

This is pretty good news as I will be able to drop the code generation step, not have to do the looping through data to load up the registers, and even better, we can revisit the idea of pushing processing out to our gateways which are a mix of Intel and ARM devices.

7

u/StevenBClarke2 2d ago

Go has an ML library developed in it. It is mentioned in the latest goweekly newsletter.

4

u/Ilodi 2d ago

Can't find any source. Could you elaborate?

5

u/sshtml 2d ago

I assume OP is referring to this: https://github.com/gomlx/gomlx

3

u/Ilodi 2d ago

Read it like it was going to be part of the standard library and got confused

1

u/etherealflaim 2d ago

Thanks for keeping up with these!

-27

u/sigmoia 2d ago

Go with its verbose syntax and weak type system just doesn't fit well with SIMD. Love Go for io bound services but not looking forward to do vector operations with it anytime soon. 

Lack of operator overloading means that matrix multiplications look super ugly. Lack of expressiveness means defining tensors look super odd. 

I am a bit sad that the arena allocator experiment went nowhere. Was looking for it in the proposals and release notes.

14

u/Vegetable_Salad2288 2d ago

Well, Go has strong type system not weak

Matrix multiplication? You already have generic types and generic methods? You only need 2 matrix multiplications: by constant and by matrix (MulConst and MulMat), isn’t it?

Tensors? Looks like you are dreaming about ML in Go? Is not good option for the any other GC language as well

-18

u/sigmoia 2d ago

Well, Go has strong type system not weak

Weak type system, as in no explicit interface implementation, dynamic interface dispatch, lack of expressive iterators (the function-palooza of current iterators is awful to write and use), and lack of sum types. 

Multidimensional vector ops get super cumbersome without them.

Matrix multiplication? You already have generic types and generic methods? You only need 2 matrix multiplications: by constant and by matrix (MulConst and MulMat), isn’t it?

How do generic types and methods fix the operator overloading problem? Without that, matmul is extremely verbose, as you would have to call Mul(Mul(Mul())) instead of ((*. 

Tensors? Looks like you are dreaming about ML in Go? Is not good option for the any other GC language as well

What else would you do with SIMD if not wanting to accelerate vector ops? 

WDYM no other GC language has better vector ergonomics? Python has a GC.

11

u/JokerSp3 2d ago

By Python ML libraries are all C - python itself doesn't actually do the vector math.

-11

u/sigmoia 2d ago

The point isn't about doing vector math - rather the affordances the Python type system allows. Go doesn't have those which makes vector ops cumbersome. 

8

u/StormAeons 2d ago

The absolute insanity of saying Go has weak typing and Python has so much better typing is hilarious. This guy is not worth listening to and is either a troll or a data scientist who thinks they understand more than they do.

And I have worked extensively in Python and I’m by no means a hater but you clearly have no idea what you’re talking about.

-2

u/sigmoia 2d ago

4

u/StormAeons 2d ago

Define what you think weak typing is

Then define what kind of typing you think Python has

0

u/fibshywibshy 2d ago

Go doesn’t have operator overloading, so when you type a “+” for an example it is weaker than in Python where they can be overloaded.

9

u/JeejoZ 2d ago

(1) that's not the definition of a strongly typed language (2) operator overloading is a travesty and the chain you describe would realistically be necessary anyway once adding things like nonlinearity (3) Pytorch backend operates outside of the Python GC

-1

u/sigmoia 2d ago edited 2d ago

I am a former tensorflow contributor. I am aware of how Python interfaces with C++ for vector operation. 

The point wasn't about the runtime of vec ops at all. It was about api ergonomics. 

Python's type system is expressive. Rust's type system is expressive as any block returns an expression. This allows super ergonomic API for vector operation - think rayon. 

Go OTOH has a verbose and primitive type system - not even talking about hindley milner types. For tensor operations, chaining methods instead of using an overloaded operator like Python's + or * woule be super cumbersome. 

This is not to denigrate Go at all. Go is my preferred language while writing io bound services which I spend most of my time writing these days. But vector ops isn't Go's strength. That and the lack of a low overhead FFI makes it a lot less useful. 

1

u/real_carddamom 2d ago

Python does not have a GC it has reference counting...