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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

151–160 of 280 posts

Re: Go's Sweet 16

#151

Post by pa7ch »

throw1111221 wrote: post #50
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

I feel like people always take the designed for juniors thing the wrong way by implying that beneficial (to general software engineering) features or ideas were left out as a trade off to make the language easier to learn at the cost of what the language could be to a senior. I don't think the go designers see these as opposing trade offs.

Whats good for the junior can be good for the senior. I think PL values have leaned a little too hard towards valuing complexity and abstract 'purity' while go was a break away from that that has proved successful but controversial.

Re: Go's Sweet 16

#152

Post by treis »

gp wrote: post #78
stackghost wrote: post #77

Earlier quoted context omitted.

Sure, but all those languages didn't have the psychotic design that mandated all your code lives under $GOPATH for the first several versions. I'm not saying it's awful, it's just a pretty mid language, is all.

The language has changed a lot since then. Give it a fresh look sometime.

It's still pretty mid and still missing basic things like sets.

But mid is not all that bad and Go has a compelling developer experience that's hard to beat. They just made some unfortunate choices at the beginning that will always hold it back.

Re: Go's Sweet 16

#153

Post by estebank »

j16sdiz wrote: post #59
metaltyphoon wrote: post #45

Earlier quoted context omitted.

Rust isn’t that complicated if you have some background in non GC languages.

Parent say _all_ of it, not a subset for everyday use.

There's a different question too, that I think is more important (for any language): how much of the language do you need to know in order to use it effectively. As another poster mentioned, the issue with C++ might not be the breath of features, but rather how they interact in non-obvious ways.

Re: Go's Sweet 16

#154

Post by morshu9001 »

ezst wrote: post #112
morshu9001 wrote: post #21

Earlier quoted context omitted.

Language can be bottleneck if there's something huge missing from it that you need, like how many of them didn't have first class support for cooperative multitasking, or maybe you need it to be compiled, or not compiled, or GC vs no GC. Go started out with solid greenthreading, while afaik no major lang/runtime had something comparable at the time (Java now does supposedly). The thing people tend to overvalue is the…

I'll be the one to nickpick, but Scala never intended to be a nicer Java. It was and still is an academic exercise in compiler and language theory. Also, judging by Kotlin's decent strides, "little Syntex differences" get you a long way on a competent VM/Runtime/stdlib.

Kotlin's important feature is the cooperative multitasking. Java code has been mangled all these years to work around not having that. I don't think many would justify the switch to Kotlin otherwise.

Re: Go's Sweet 16

#155

Post by morshu9001 »

ttoinou wrote: post #57
alexjplant wrote: post #29

Earlier quoted context omitted.

ECMAScript is an order of magnitude more complicated than Go by virtually every measure - length of language spec, ease of parsing, number of context-sensitive keywords and operators, etc.

Yeah I’m pretty sure people who say JS is easy don’t know about its Prototype based OOP

You don't have to know about it, but if you do, it's actually simpler than how other languages do OOP.

Re: Go's Sweet 16

#156

Post by zer00eyz »

bccdee wrote: post #123
zer00eyz wrote: post #66

Earlier quoted context omitted.

You're not wrong but... there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. I keep using the analogy, that the tools are just nail guns for office workers but some people remain sticks in the mud.

Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. For non-trivial tasks, AI is neither of those. Anything you do with AI needs to be carefully reviewed to correct hallucinations and incorporate it into your mental model of the codebase. You point, you shoot, and that's just the first 10-20% of the effort you need to move past this piece…

> Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood.

You missed it.

If I give a random person off the street a nail gun, circular saw and a stack of wood are they going to do a better job building something than a carpenter with a hammer and hand saw?

> Anything you do with AI needs to be carefully reviewed

Yes, and so does a JR engineer, so do your peers, so do you. Are you not doing code reviews?

Re: Go's Sweet 16

#158

Post by millerm »

trenchpilgrim wrote: post #91
ashishb wrote: post #90

Earlier quoted context omitted.

> I'm still trying to convince the scientists I work with that they should format their code or use linters. Consider adding a pre-commit hook if you are allowed to.

My group's repos enforce strict rules, theirs does not.

Yeah, I've been there. I would get passed down horribly formatted code from another repo and it showed the data scientists writing it barely knew what they were doing. It was their repo, we couldn't do anything about it. They wouldn't reformat the code, because they were afraid it would break. They also passed us a lot of Python, and you can see where they got this fear from.

Re: Go's Sweet 16

#159

Post by culebron21 »

lenkite wrote: post #148
culebron21 wrote: post #111

Earlier quoted context omitted.

> `value, keyExists := myMap[someKey]` If I don't need the value, I have to do awkward tricks with this construct. like `if _, key_exists := my_may[key]; key_exists { ... }`. Also, you can do `value := myMap[someKey]`, and it will just return a value or nil. Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. This construct (assigning from map subscript) is pure magic, de…

> Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. Err, no Go doesn't do that. No insertion happens unless you explicitly assign to the key.

You're right. But it will return something: https://go.dev/play/p/Cz6aeGpURgo

  my_map := make(map[int32][]int64)
  val := my_map[123]
  val = append(val, 456)
  my_map[123] = val
  fmt.Println(my_map)
prints `map[123:[456]]`

I guess it's convenient compared to Rust's strict approach with entry API. But also, what I found is that golang's subscript returns nil in one case: if the value type is a nested map.

  my_map := make(map[int32]map[int32]int64)
  val := my_map[123]
  val[456] = 789
  my_map[123] = val
  fmt.Println(my_map)
output:

  panic: assignment to entry in nil map

Re: Go's Sweet 16

#160

Post by millerm »

zerr wrote: post #145
tschellenbach wrote: post #2

10 week onboarding program we use here for go backend devs: https://www.reddit.com/r/golang/comments/1eiea6q/10_week_pla... go is amazing. switches from python to go 7 years ago. It's the reason our startup did well

One thing I don't like when it comes to Golang jobs - it is rare to see pure software engineering positions. For some reason, most Go jobs requirements include AWS, Kubernetes/Docker, CI/CD setup, etc... DevOps stuff, which is not the case for positions in other stacks.

I haven't been able to find a job anywhere, using any language, that didn't require all that stuff these days. I wish I could go back to pure development, but now we all get this entire infra-crap thrown at us too. Which then means... you support the environments, the runtime, and the code. It's a 24/7 world and I don't care for it anymore.
Post reply on HN