I’m going to try to help explain this, but i’ll be honest it feels like you’re coming from a place of frustration. I’m sorry about that, take a break :)

(I’m not a language expert, but here goes)

var test int < bruh what? :=

These are the two forms of variable declaration and the second one is a declaration and initialization short hand. I most commonly use :=. For instance:

foo := 1 // it's an int!
var bar uint16 // variable will be assigned the zero value for unit16 which is unsurprisingly, 0.

func(u User) hi () { … } Where is the return type and why calling this fct doesnt require passing the u parameter but rather u.hi().

This has no return type because it returns no values. It does not require passing u. It’s a method on the User type, specifically u User is a method receiver. You might think of this akin to self or this variable in other languages. By convention it is a singke character of the type’s name.

If that function returned a value it might look like:

func(u User) hi() string {
    return "hi!"
}

map := map[string] int {} < wtf

This is confusing because of how it’s written. But the intent is to have a map (aka dictionary or hashmap) with string keys and int values. In your example it’s initializd to have no entries, the {}. Let me rewrite this a different way:

ages := map[string]int{
    "Alice": 38,
    "Bob": 37,
}

Hope this helps. In all honesty, Go’s language is very simple and actually rather clear. There’s definitely some funny bits, but these aren’t it. Take a break, come back to it later. It’s hard to learn if you are frustrated.

I also recommend doing the Tour of Go here. My engineers who found Go intimidating found it very accessible and helped them get through the learning code (as there is with any language).

Good luck (I’m on mobile and didn’t check my syntax, hopefully my code works 😎)

but Im seeing syntax that Ive never seen in my life

Which languages do you know? What is your background?

What is wrong with “var test int”? There is no need for a return type, if the function returns nothing. Thats the language design and I think it is easy to remember.

func(u User) hi ()

u is something like self in Python and hi() is a method of User.

Please explain why do you think something is too messy, also with which languages you have already worked.

Yea this is just syntax, every language does it a little different, most popular languages seem to derive off of C in some capacity. Some do it more different than others, and some are unholy conglomerations of unrelated languages that somehow works. Instead of saying why is this different, just ask how does this work. It’s made my life a lot simpler.

var test int is just int test in another language.

func (u User) hi () { ... } is just class User { void hi() { ... } } in another language (you can guess which language I’m referencing I bet).

map := map[string]int {} is just Map<String, Integer> map = new HashMap<>() in another (yes it’s java).

Also RTFM, this is all explained, just different!

Edit: I also know this is a very reductive view of things and there are larger differences, I was mostly approaching this from a newer developers understanding of things and just “getting it to work”.

map := map[string] int {}

Not sure where you got your examples, but the spacing is pretty wonky on some (which can’t possibly help with confusion) and this one in particular causes a compile-time error. (It’s kindof trying to declare a variable named “map”, but “map” is a reserved word in Go.)

var test int < bruh what?

This article gives the reasoning for the type-after-variable-name declaration syntax.

:=

Lots of languages have a colon-equals construction. Python for one. It’s not terribly consistent what it means between languages. But in Go it declares and assigns one or more variables in one statement and tells Go to figure out the types of the variables for you so you don’t have to explicitly tell it the types to use.

func(u User) hi () { … }

That function (“method”, really, though in Go it’s more idiomatic to call it a “receiver func”) has no return values, so no return type. (Similar to declaring a function/method " void in other languages.)

The first pair of parens says to make this “function” a “method” of the “User” type (which must be declared in the same package for such a function declaration to work.) The whole “when I call it like u.hi(), don’t make me pass u as a parameter as well as putting u before the period” thing also has precedent in plenty of other languages. Python, again, is a good example.

Oh, and the second set of parens are where the function’s (non-receiver) parameters go. Your example just doesn’t take any. A function like func (u User) say(msg string) { ... }, for instance, could be called with u.say("Hey."). func (u User) ask(question string) string { ... } has a return type of string. So you could do var ans string = u.ask("Wuzzup?") or ans := u.ask("Wuzzup?").

I can’t say I was ever too taken aback with Go’s syntax. Just out of curiosity, what languages do you have experience with?

My least favorite part of Go, by far, is the capitalization as struct member visibility thing. That and the not super great json encoding annotations.

Here’s a sample:

type Change struct {
	Path             string `json:"path"`
	Category         string `json:"category"` // change, append, create, delete
	Position         int64  `json:"position"`
	Size             int64  `json:"size"`
	OriginalChecksum string `json:"original_checksum"`
	UpdatedChecksum  string `json:"updated_checksum"`
	UnixTimestamp    int64  `json:"unix_timestamp"`
	Data             []byte `json:"data"`
	MatchedRules     []Rule `json:"matched_rules"`
}

I would take explicit public declarators any day

Wow it shows how much it boils down to préférence at the end of the day.

I’m a Go fanboy, I cannot cite an aspect of the language I don’t like, find clunky…

Wow. I love syntax, the tooling, the speed, the errors, the testing framework.

The := operator is called walrus operator and is inspired by Python I think. It’s declaring a variable and assigning it in one go. map[string] int is defining a map (associative array or also known as dictionary in Python), with string as key type and int as value type. And the following {} is the body of the associative array, meaning empty content.

I only played a bit with Go and did basic tutorials. I might go back to it at some point, but Zig is much more appealing to me. Go is too simple in the language to me, but on the other side, this is exactly whats appealing.

To do quick and simple explanations:

var test int = 0

assign an int, var = let in rust land

:= 

This is basically an inferred assignment e.g.

a := "hello world"

The compiler will know this is a string without me explicitly saying

func (u User) hi() {}

To return to rust land this is a function that implements User. In OOP land we would say that this function belongs to the user class. In Go, just like in rust we don’t say if a function returns void so this function is for User objects and doesn’t return anything:

func (u User) hi(s string) string {}

If it took in a string and returned a string it would look like this.

map[string] int {}

I will give you that this syntax is a bit odd but this is just a hashmap/dictionary where the key is a string and the value is an int

I entirely disagree, Go has some of the most straightforward and meaningful syntax I’ve ever used.

I agree. I find Rust’s syntax much better than Go’s.

The more time I spend on Lemmy the more depressed I am about its potential.

Stupid, wrong-headed comments get solid upvotes if they also hint at some popular sentiment. I even see comments that are literally unreadable nonsense get solidly upvoted, either by bots or by people who just like the vibe they feel from scanning it and don’t care that it’s gobbledygook. Some content makes me wonder if half of Lemmy is just LLMs barfing back and forth at each other.

Then this post is heavily upvoted, even though it’s nothing more than “the syntax isn’t the same as the other language(s) I have seen, waaaaa!”. Is it just people like to see Go criticized? Because there are actual real issues that could be discussed.