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

Go runtime: 4 years later

go.dev

Post reply on HN
Print view View original

221–230 of 296 posts

Re: Go runtime: 4 years later

#221

Post by icholy »

doctor_eval wrote: post #102
geenat wrote: post #90

Love go as a platform.. self contained binaries have been a miracle for ops..but have a few big hangups about using the language full time because of the sucky ergonomics. * No optional/named parameters. Writing a whole function per parameter for function chaining is excessive. This would not be difficult to add to the compiler (i've done it and have seriously considered using the fork) but it seems like the team is…

> No default struct values I love Go too but this does drive me nuts, especially when parsing JSON and wanting to set sane defaults for missing values. Like, for example, booleans that should default to "true".

Write a DefaultFoo function which returns a Foo with default values set. Then unmarshal into that.

Re: Go runtime: 4 years later

#222

Post by pjmlp »

randomdata wrote: post #217
baby wrote: post #144

Earlier quoted context omitted.

I think if Golang would have been invented a couple of years later it def would have had sum types. But then, Rust probably wouldn’t have had its insane tooling that is most likely inspired by golang

I doubt it. It seems quite apparent that Thompson just wanted to take another stab at creating the next generation in the B -> NB (New B) -> C -> Go family tree. It would have likely been named D if the name wasn't already taken. Pike slapped his Newsqueak's CSP paradigm on top and the rest is history.

Go is basically an AOT compiled version of Limbo with the method syntax and UNSAFE package from Oberon-2, and they stopped there.

Re: Go runtime: 4 years later

#223

Post by morelisp »

Fire-Dragon-DoL wrote: post #218
morelisp wrote: post #173

Earlier quoted context omitted.

There’s no reason that UI can’t kick off a recompile on the backend, nor any reason it has to be a different machine.

Recompiling the whole software is way more expensive than pasting a file on the filesystem, that was my point.

But it’s not so expensive you can’t do it. If you cache it’s probably not even so expensive anyone will notice compared to the equivalent PHP process. And it would be a massive operational, usability, and performance improvement to the actual server.

Otherwise you’re just saying “I can’t write Go like PHP” - no shit, that’s a good thing.

Re: Go runtime: 4 years later

#224

Post by philosopher1234 »

kaba0 wrote: post #163
philosopher1234 wrote: post #156

Earlier quoted context omitted.

Public static void is already quite a lot for beginners to learn

I don’t know — do you have to know how an engine works to drive a car? While they may not understand at first why they have to write this, I really dislike when people make that 3 words into something impossible to grasp. A good chunk of all programmers have learnt to program by starting with Java. And besides these 3 words, it is a small language (very few keywords), easy, but sufficiently strong type system that wi…

I think the point is that this is hard to learn. Whether it’s necessary to learn is a separate question. I think it’s easier to be an effective dev when you do understand how these things work, and designing a language to make it easier to acquire that understanding is good.

Re: Go runtime: 4 years later

#225

Post by dfawcus »

apatheticonion wrote: post #99
nu11ptr wrote: post #29

I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs mu…

I totally agree. After working with it for a while I feel like its best use is in writing CLI tools due to the compiler making it so damn easy to produce statically linked binaries for any platform, backed by an incredibly powerful standard library. My issue for application and web server development are in the language design as it restricts me in my personal quest to write loosely coupled code that is marinated in…

"You can accept a struct where an interface is a parameter but you cannot return a struct where an interface is the return type."

Possibly I'm misunderstanding the complaint, but that is because an interface is a fat pointer, so one returns a pointer to a struct implementing the interface.

https://go.dev/play/p/YOa6NF7rjPF

Re: Go runtime: 4 years later

#226

Post by spullara »

uup wrote: post #100
spullara wrote: post #52

Earlier quoted context omitted.

You are actually suggesting what Java does in a container environment lol. https://developers.redhat.com/articles/2022/04/19/java-17-wh...

Maybe now, but in the past you'd have to worry about things like running out of PermGen space. There were definitely more knobs than a typical container environment.

PermGen was removed from Java in 2014, just a year after Docker was released. Please compare modern with modern rather than "the last time I used it".

Re: Go runtime: 4 years later

#227

Post by uup »

spullara wrote: post #226
uup wrote: post #100

Earlier quoted context omitted.

Maybe now, but in the past you'd have to worry about things like running out of PermGen space. There were definitely more knobs than a typical container environment.

PermGen was removed from Java in 2014, just a year after Docker was released. Please compare modern with modern rather than "the last time I used it".

I did qualify my statement with "in the past." I was pointing out that Java did, in fact, have a lot of annoying knobs to turn. tbrock was advocating against having such knobs as they make deploying a language diffcult. The fact that Java removed one of the annoying knobs doesn't disprove the fact that having such knobs is annoying.

Re: Go runtime: 4 years later

#228

Post by wtetzner »

simiones wrote: post #196
pjmlp wrote: post #122

Earlier quoted context omitted.

It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help. Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.

I generally agree about the runtime and language semantics. However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).

> However, (stable) OCaml not having multithreading support is still a gigantic limitation.

OCaml 5 still seems a lot more real and coming-sooner than the imaginary OCaml-on-Go. Sure, it's not ideal that multicore OCaml isn't yet stable, but it does exist, and will become stable.

Re: Go runtime: 4 years later

#229

Post by simiones »

wtetzner wrote: post #228
simiones wrote: post #196

Earlier quoted context omitted.

I generally agree about the runtime and language semantics. However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).

> However, (stable) OCaml not having multithreading support is still a gigantic limitation. OCaml 5 still seems a lot more real and coming-sooner than the imaginary OCaml-on-Go. Sure, it's not ideal that multicore OCaml isn't yet stable, but it does exist, and will become stable.

Absolutely - I was only replying to the question of why you may want this in principle.

Re: Go runtime: 4 years later

#230

Post by int_19h »

cygx wrote: post #170
int_19h wrote: post #145

Earlier quoted context omitted.

Go doesn't have bytecode interpreter or JIT, but it still needs a VM, if only for green threads.

Not every runtime environment is a virtual machine...

That's true, but I would argue that any runtime with custom green threads is.
Post reply on HN