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

171–180 of 296 posts

Re: Go runtime: 4 years later

#171

Post by cies »

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 agree. It feels a bit like where Java/JVM is at: popular, solid runtime, large community/ecosystem, but Java made some bad choices.

In my opinion: Go needs a Kotlin. First and foremost to do away with implicit nulls (imho the biggest mistake), but here are other things that could be impoved you've already mentioned.

Re: Go runtime: 4 years later

#172

Post by throwaway2037 »

masklinn wrote: post #135
qaq wrote: post #79

Earlier quoted context omitted.

Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.

> Async code is way nicer in Go than it is in Rust. That’s because Go does not have async code. It has sync code on an async runtime. Like e.g. Erlang/Elixir.

This is an interesting comment. Is there a webpage where I can read more about this idea?

Re: Go runtime: 4 years later

#173

Post by morelisp »

Fire-Dragon-DoL wrote: post #110
morelisp wrote: post #40

Earlier quoted context omitted.

If I was going to try to make something "similar to Wordpress" with Go I would replace plugins with optional packages triggered by build flags (or possibly a light codegen step), not an actual dynamic plugin system. The Wordpress model is solved with plugins in PHP (for reasons that were to some degree bad even at the time), but it's not actually "I want to inject some external code into this existing process environ…

I'd like to point out also that wordpress can install plugin directly from the UI, which is a lot more involved if it requires the whole software to be recompiled (totally different machine too)

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.

Re: Go runtime: 4 years later

#174

Post by pizza234 »

nu11ptr wrote: post #33
akira2501 wrote: post #32

Earlier quoted context omitted.

I haven't found any issues with expression, so far. I wouldn't use it to write a UI, but for writing networking code or automated tasks I find it perfectly suited to the task. I appreciate it's error handling. It's burdensome, sure, but it presents almost no additional cognitive load when attempting to reason about control flow. It essentially has no enums. However, it has a comfortable type system that can wrap prim…

I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point o…

I've been surprised how writing Rust becomes smooth with experience (mostly; it's still complex in some areas), however, there's more to a language than just the formal part.

Rust requires designing the memory management (ownership/lifetimes) of a program, which Golang doesn't, so even if/when the cognitive load is (hypothetically) equal, there's an additional, non-trivial demand. This is not something that everybody wants in a project (the given tradeoff may not be worth); for sure, if I had to introduce a language in my team only for tooling purposes (ie. small programs), Rust would not be the most productive choice IMO.

Re: Go runtime: 4 years later

#175

Post by tomohawk »

baby wrote: post #142
hknmtt wrote: post #126

Quoted post unavailable.

What do you have against BLM?

Nothing against the statement, but the related politics led to this outcome:

https://www.cnn.com/2022/09/25/us/minneapolis-crime-defund-i...

And the organization named BLM didn't live up to its name:

https://www.washingtonexaminer.com/news/blms-millions-go-una...

Re: Go runtime: 4 years later

#176

Post by xpressvideoz »

bayindirh wrote: post #154
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…

We always make this discussion with friends. I don't think every language should tick the boxes the same way. I also personally like Go a lot. It's filling the gap between C++ and Python for me. If I need something compiled with proper threading support, but C++ would be an overkill, I reach for Go. Go is designed with a human centric view, IMHO: "Make writing great programs easier rather than design a language with…

> Go is designed with a human centric view, IMHO

If it were Go's design philosophy, it would have allowed unused variables/imports. Those restrictions are there exactly because they help computers, reducing compilation time. The over-focus of compilation time also stems from monorepos being used by Google, whose purpose is also helping computers.

Re: Go runtime: 4 years later

#177

Post by randomdata »

akira2501 wrote: post #72
aatd86 wrote: post #53

Earlier quoted context omitted.

If I may ask, I'm curious about why you wouldn't use it to build a User Interface?

One is Go's module/import system. It's pretty inflexible and the connection between exported functions and types and how they are Capitalized or not does create friction for me when I'm "building up" code bases from scratch. Puzzling about module boundaries and type definitions feels like it would consume more time than it's worth in a UI oriented program. The other is most UIs are wrappers around other functionality…

On the other hand, Go's defining feature: Its CSP model, lifted from Newsqueak, was originally designed for user interfaces.

I believe Go could be a really great fit for UIs, but likely never will be as there is little economic incentive to put in the incredible heavy lifting required to build up the support libraries. There are certainly some small projects trying, but without massive resources backing it, it is a struggle to achieve the full fit and finish that we've come to expect.

Re: Go runtime: 4 years later

#178

Post by qaq »

masklinn wrote: post #135
qaq wrote: post #79

Earlier quoted context omitted.

Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.

> Async code is way nicer in Go than it is in Rust. That’s because Go does not have async code. It has sync code on an async runtime. Like e.g. Erlang/Elixir.

Exactly don't have to deal with red/blue functions

Re: Go runtime: 4 years later

#179

Post by xvello »

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".

For that use case, I think that you can assign your defaults before passing your target struct to the unmarshaller.

The unmarshaller will iterate on the json input and set struct fields when json fields are found. This means that struct fields that don't match the json are ignored, and values you have set before will be left as is.

Re: Go runtime: 4 years later

#180

Post by qaq »

Klonoar wrote: post #87
qaq wrote: post #79

Earlier quoted context omitted.

Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.

>Also Go is much easier to read vs Rust. This is subjective - I for example have no real issues reading Rust code, but find Go to look like utter spaghetti on the screen.

Sure. But just due to Go type system being pretty basic I've never came across Go code I could not immediately grock, not so with Rust. Even bugging some pretty savvy Rust devs for help it sometimes took them a decent amount of time to pin down whats going on.
Post reply on HN