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

181–190 of 296 posts

Re: Go runtime: 4 years later

#181

Post by kajaktum »

randomdata wrote: post #153
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…

> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…

>There are a lot of programs where you don't need to think about errors

What kind of utopian programming job do you have that you don't have to think about errors? An error is not limited to technical issues like packet loss or unable to open socket. Its also "client A attempted to purchase item B which is limited to client C". How do you express this in Go?

I have no idea why people are so opposed to ADTs. Its like sliced bread with butter, or whatever the phrase is. Its not _that_ complicated...is it?

Re: Go runtime: 4 years later

#182

Post by kaba0 »

randomdata wrote: post #167
jackosdev wrote: post #157

Earlier quoted context omitted.

Just make it so: varFoo, err := GetFoo() if err != nil { return err } Can be written as: varFoo := GetFoo()? Just like Rust, everyone would stop complaining about Go error handling. But they have this absolutist position on syntactic sugar, even for something like this that would make the language that much nicer to look at and work with.

While that may look good for a hypothetical example, I'm not sure how beneficial it is in real-world use. If your higher level functions are directly passing errors from your lower level functions then you start to bake implementation details into your abstractions which becomes a nightmare later when your implementation changes and callers are depending on those details. In reality, you need to deal with the error i…

All of these things are better handled by good old exceptions (with optional checking, even). All in all, handling errors is often not possible locally -- there is no reasonable thing to do with a db connection error for example at its immediate caller.

The reasonable thing is perhaps to log it there at most, and bubble it up (possibly wrapped as you mentioned). It can be handled for example by a request handler, by returning a 50_ error.

Re: Go runtime: 4 years later

#183

Post by kaba0 »

EdwardDiego wrote: post #158
randomdata wrote: post #153

Earlier quoted context omitted.

> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…

I like the reasoning behind Go's approach, but the `if err != nil` ends up polluting codebases like Java's checked exceptions did. I'm not sure what the better way to do it is tbh.

Java's checked exception's could be handled at a single place by a catch, or just marked as `throws`. It was never as verbose as go is.

Re: Go runtime: 4 years later

#184

Post by peaky_blinder »

fnord123 wrote: post #152
kaba0 wrote: post #114

Earlier quoted context omitted.

And much more error prone.

Depends where someone comes from. If they are from a weakly or dynamically typed language (C, python, Javascript) then Go is quite ok. If you're coming from Haskell, OCaml, or Rust, then sure Go might be frightening.

They're all weakly typed languages but C is statically typed.

Re: Go runtime: 4 years later

#185

Post by kaba0 »

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

Then you can sure list some differences between go's and JVM's runtime.

Re: Go runtime: 4 years later

#186

Post by kaba0 »

peaky_blinder wrote: post #184
fnord123 wrote: post #152

Earlier quoted context omitted.

Depends where someone comes from. If they are from a weakly or dynamically typed language (C, python, Javascript) then Go is quite ok. If you're coming from Haskell, OCaml, or Rust, then sure Go might be frightening.

They're all weakly typed languages but C is statically typed.

I think parent didn't say anything to the contrary, or maybe it was edited?

Re: Go runtime: 4 years later

#187

Post by zimbatm »

cube2222 wrote: post #37
Fire-Dragon-DoL wrote: post #21

Earlier quoted context omitted.

And don't forget, the plugin API has some super strong limitations. I wish that was fixed, otherwise platforms "similar to wordpress" can never become a thing on Go

Actually, folks usually just use gRPC or Yaegi in Go. You can write an SDK for your software that abstracts all of that away for the plugin developer. See Terraform[0], Traefik[1], or OctoSQL[2]. Though I agree plugins would be welcome, especially for performance reasons, though also to be able to compile and load go code into a running go process (JIT-ish). [0]: https://github.com/hashicorp/terraform [1]: https://gi…

I have had cases where Terraform would OOM because each Terraform provider instance maps to a fresh new Go process.

Most of the time this approach is not an issue, and it works really well. But you need to be aware that it's best to keep the number of providers in the 0-20 range per root module.

Re: Go runtime: 4 years later

#188

Post by kweingar »

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…

One of the underrated difficulties of learning Java is the fact that it demands separate files for each exported class.

Writing and reading simple Go libraries is a breeze. I’ve written tiny libraries that fit in one file. You can read it linearly, starting at the top and following the logical progression of type declarations, functions, globals, etc.

Whereas with an identical Java library, a reader would be presented with several small files and have no idea where to start reading.

Re: Go runtime: 4 years later

#189

Post by sph »

throwaway2037 wrote: post #172
masklinn wrote: post #135

Earlier quoted context omitted.

> 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?

Perhaps https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

Re: Go runtime: 4 years later

#190

Post by bborud »

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…

The error handling was a disappointment at first, but in practice it is a lot clearer and more usable than any other kinds of error handling I've tried. It could perhaps do with some syntactic sugar, but it isn't a big issue since IDEs can pick up that slack. After about half a decade of Go I'd say that the error handling is something I've come to like.

"More expressive" in my opinion tends to mean "less readable", but there is some personal bias here. The people I've met during my career who like "more stuff" are usually the younger, less experienced programmers who aren't as concerned about long term viability.

I'm in my fifth decade of programming and my approach is "do more with less". When people want more stuff, for me, it means that I'll be dealing with more cases of people not knowing how all the stuff works. Everyone likes to think they can deal with more cognitive overhead, but mostly people can't.

I'm not sure if pattern matching belongs in a language like Go at all. Admittedly I haven't given it much thought, but it doesn't feel right for what Go aims to be. If you want to do Erlang, do Erlang, but I might be wrong about this.

What's error prone about the for statement? I don't use the C-style for statement all that often as way more than 50% of my for loops are ranging or naked for loops with break/continue/return.

Not having nil tends to lead to having to invent sentinel values all over the place, doesn't it? Is that really better? And since you often end up doing things by value in Go anyway, it isn't like you don't have any choice.

Post reply on HN