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

211–220 of 296 posts

Re: Go runtime: 4 years later

#211

Post by randomdata »

kaba0 wrote: post #182
randomdata wrote: post #167

Earlier quoted context omitted.

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…

Casting errors to exceptions (panic/recover) are considered a valid approach in Go within your application logic. Its built-in HTTP handlers will even 500 out of the box if a panic isn't recovered beforehand.

But other layers of abstraction lose their utility value if they start to make assumptions about the caller. Maybe in your web service a 50x stop the world error is all you'll ever need if there is a database error, but the next guy using the code for another purpose could have very different requirements and when you have to actually deal with errors, exceptions become a royal pain very quickly. As such, the official line is simply that you shouldn't let errors casted to exceptions cross package boundaries.

But, again, Go isn't really designed for stop the world programming and it's okay to use another tool if your problem space is suited to stopping the world.

Re: Go runtime: 4 years later

#212

Post by cygx »

kaba0 wrote: post #208
cygx wrote: post #202

Earlier quoted context omitted.

Most relevant in context of our discussion: The JVM is a (virtual) stack machine with its own instruction set and semantics specified in the Java Virtual Machine Specification . As far as I'm aware, something equivalent does not exist for Go, or as an internal implementation detail at best (some intermediate representation might potentially qualify if you squint at it the right way).

That's also an implementation detail, because the majority of execution time happens in native code with a native GC "managing it" the exact same way, not by interpreting abstract virtual machine instructions .

It's not an implementation detail, the interface is mandatory and public (Java bytecode).

Re: Go runtime: 4 years later

#213

Post by kaba0 »

randomdata wrote: post #211
kaba0 wrote: post #182

Earlier quoted context omitted.

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…

Casting errors to exceptions (panic/recover) are considered a valid approach in Go within your application logic. Its built-in HTTP handlers will even 500 out of the box if a panic isn't recovered beforehand. But other layers of abstraction lose their utility value if they start to make assumptions about the caller. Maybe in your web service a 50x stop the world error is all you'll ever need if there is a database er…

I don’t get what you mean by stopping the world. An exception (in most languages) only interrupts the executing thread.

Re: Go runtime: 4 years later

#214

Post by randomdata »

xpressvideoz wrote: post #176
bayindirh wrote: post #154

Earlier quoted context omitted.

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.

Fast compilation times are a human-centric goal. The machine couldn't care less if it takes a millennia to compile your program. Only humans care about fast compile times.

But, I'm not sure that is even the primary benefit. The primary benefit is that you won't be incentivized to leave unused imports and variables to litter your code, as I see happen all the time in languages that aren't so strict. The Go team has even stated that they decided there would be no warnings because they've learned that warnings get ignored.

Re: Go runtime: 4 years later

#215

Post by steveklabnik »

scoutt wrote: post #128
steveklabnik wrote: post #96

Earlier quoted context omitted.

That's fair. In my mind, they're at least related: if I'm trying to learn about some code, I change stuff and see what breaks.

Just as parent, my greatest struggle with learning Rust is to open someone else's code and trying to understand what is going on. With C that's a lot easier. I you were to learn Rust from scratch, what project would you recommend for the "changing and breaking" approach?

I don't know if I use that to learn the language itself, but also, different people have different learning styles. What I personally do to learn new languages is write some sort of program that I know well. So for me, that's text adventure games. When I'm trying to learn a new language, I go and make a very simple one. This helps because you're not learning a new domain and a new language at the same time.

But along the whole "break it" idea... I don't know if you're an IDE person or a text editor die-hard, but I've found that rust-analyzer helps a ton. I'm historically a "vim with no plugins" kind of guy, but I'm using VS: Code with the vim keybindings now, and even if I'm not changing some code and getting feedback from the compiler itself, using rust-analyzer to go "hey what's this type here? Where's it defined, let's go take a look" has helped a ton.

That said, types help and poking around helps, but it's not always a panacea. Today I'm working on fixing something that doesn't quite work, even though yesterday I figured out how to assemble everything I'm supposed to need from this library I'm using. "It compiles it works" is a thing people say, and while I feel that way often, it's not true all of the time, of course.

Re: Go runtime: 4 years later

#216

Post by pjmlp »

simiones wrote: post #206
pjmlp wrote: post #205

Earlier quoted context omitted.

What happened to microservices and UNIX way, each tool does one thing? Yes, multithreading support is only in version 5.0, yet for many decades UNIX was multi-process only, and thanks to the latest security exploits, sandboxing with multi-processing alongside IPC seems to be the latest fashion anyway, so no big deal. OCaml has several backends, including a bytecode one that is used for the REPL and porting purposes.

Doing one thing on multiple threads is very much possible. Threads enable (simple) shared memory multi-processing, which is the most efficient version of multi-processing. You can theoretically get something similar with different processes and memory-mapped files, but multi-threading is much easier in general. For example, if you want a high-performance web server, it's much more efficient to serve requests through…

They also enable plenty of data races and security exploits, as proven in recent years.

Re: Go runtime: 4 years later

#217

Post by randomdata »

baby wrote: post #144
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…

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.

Re: Go runtime: 4 years later

#218

Post by Fire-Dragon-DoL »

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

Earlier quoted context omitted.

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.

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

Re: Go runtime: 4 years later

#219

Post by lsaferite »

baby wrote: post #138
Klonoar wrote: post #87

Earlier quoted context omitted.

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

That’s probably because you’re not used to it. I think it’s common knowledge that Golang is easy to read.

Couldn't the same be said of rust though? The biggest barrier, in my experience, is almost always familiarity with the syntax.

Re: Go runtime: 4 years later

#220

Post by pjmlp »

RhodesianHunter wrote: post #98
dopidopHN wrote: post #70

Earlier quoted context omitted.

Look at you guys using nice looking languages! Haha, Java got better, but oh god it’s still verbose. We got rid of the getter setter silliness to be in “constructor land.” ( immutable records from Java 17 ) Function are still not first class citizens, but … they have a working visa now. You can shove lambda anywhere. It’s still awkward to write functional code Meh. Recently I’ve been really productive with it and I l…

Most developers on the JVM with any freedom have switched to Kotlin.

Better check those numbers, only those forced by Mountain View minions have done so.
Post reply on HN