Hacker News Reader

Comment by azth | Hacker News Reader

> Our former .NET engineer now says, “Being able to call a function that doesn’t return an error and know for sure that it must succeed is really nice.”

Except when it panics. The article lacks substance honestly.

That being said, it further cements the notion that golang has been a replacement for Python and Ruby, not Java/C#/C++ as originally planned.

View on HN

Go can easily replace Python or Ruby (because it is faster and libraries are available to do what you need). Go can replace Java and C# especially because concurrency is easier and performance is on par, if you can get along with the inferior libraries Go provides. Go cannot replace C++ in any function, because its compiler is just too primitive, low-level things are impossible and libraries will never be on par with what C and C++ have.

But generally, Go is nice because there is sufficient tooling to do most things nicely and the language is primitive enough to make the tooling work in almost all situations. Which is different from C++, because tooling there is always too stupid for templates, macros, inheritance and pointers. And it is different from Java where tooling is unusably complex, slow and enterpricey. Also, Go didn't accumulate too many "surprise" misfeatures yet, so code can be more reliably written and reviewed than in any of the other languages the parent named. Panic can be seen as the rare instance of such a misfeature, but usually it is only used to signal typically unrecoverable problems like "out of memory". So it is far from the footgun that exceptions are.

Rust has great tooling compared to C++, at least on mainstream platforms. It's a no-brainer choice for green-field projects where low-level development is required.

And the misfeatures of C++ are the stuff of legend, so Rust does way better from that POV as well.

> And it is different from Java where tooling is unusably complex, slow and enterpricey.

That's very subjective. In my opinion, nothing comes close to the excelent tooling that you can find in the JVM ecosystem. From IntelliJ to SonarQube, from VisualVM to Java Flight Recorder, etc. I'm not even talking about frameworks and the support that IDEs like IntelliJ offer for them, which is high quality.

If code can panic it should be documented. Code you write shouldn't ever panic without good reason during the regular runtime of your application. A panic means that the current goroutine has encountered an unrecoverable error, which is usually only the case for bugs such as out of range indexes or nil pointers.

Which would be exceptions you can handle in C#.

You can catch and recover from panic()'s in go, too.

The point being that an exception in C# can be any error. You can throw an exception if the weather is wrong.

A panic is fundamentally something that should never happen. You should catch panics at the root of your application for the sake of keeping the application running. But at no point should you ever expect a panic to be thrown like you would an exception. Errors are for that case.

Not handling panics is OK if you own your own code. But if you're sell an application that panics you can guarantee that's going to cause pain while supporting clients. An error log with details can be as useful but won't make the client think you're incompetent. I say this having given Go applications that panic-ed to clients before and they freaked out about these errors that weren't actually a big deal (a minor case in a controller of a web server).

Panics are prevented by culture, and I fail to see how a c# dev complimenting go invalidates gos competitive edge over c#?

Except that every nil pointer dereference panics. Every out of bounds access panics. Is that also prevented by culture?

Let's not forget that, for better or worse, exceptions in Java are checked. The types of exceptions that are errors in Go, must be explicitly handled or forwarded by the caller in Java - there is no way around it. The the type of exceptions that are panics in Go are just unchecked exceptions in Java: you don't have to explicitly handle them, but you can use the same mechanism for doing so, and handling them is more graceful, easier and culturally enforced than panic/recover. I have many criticisms of Java, but I'd argue Java culture is much more graceful in error handling there.

out of bounds panics aren’t all that common in practice. Yeah they’re easy to write, but usually if you have a slice you’re going to range over the whole thing or loop over it up to its length anyway. It’s not common to handle slice indexes on their own and keep them hanging around outside of the context of a for loop. The major exception to this is cases where you want the first element of a slice and didn’t check that the slice is non-empty first, which sucks. But in any case, it doesn’t come up all that often in production code. You can range over a nil slice or a slice of zero items safely.

Nil pointer dereferences are way more common, as is assignment into a nil map. Those I see coming up a lot in newer Go programmers’ code.

What is go’s competitive edge over c# ?

That's exactly the point - it must succeed, or panic. Panics are for programming errors and crash the program.

It's not as if programs in other languages cannot panic/crash.

panics != errors

that person is talking about application level error handling. In most cases if a functions panics generally the caller isn't expected to do anything about it other than perhaps have a panic handler at the top level of the app that logs things and lets it crash. So in general you don't need to think about catching or handling panics in most of your application code. It is the equivalent of a method that you are calling from your java code returning an undocumented NPE.

I'd say Golang has successfully started replacing Java everywhere...

Java is the new COBOL. It will not be replaced in this century.

(Checks calendar.) Oh. That's... quite a while. Longer than the entire history of high-level languages, in fact.

Not sure you're wrong, though...

COBOL is still used and the language gets releases. 220 billion lines of COBOL? We are still in the era of more things are becoming programmable and we are writing code for those new things, not consolidating and fixing up the old code.

Speaking based on direct experience, I doubt that is happening in Financial industry. I wrote a utility in Go that is heavily used in our build workflow. I could have written it in Python too but my objective was to have a dependency-free fast binary in a statically typed language with a decent standard library and Go checked all the boxes. The language is decent and I don't have any huge complaints.

Would I now choose Go to replace our core applications that are written in Java? Nope. Why? My personal main reason is that in pursuit of keeping things simple and homogenous, even everyday things take too much code. I can get the same functionality in Java in basically half loc while keeping the code totally boring and devoid of any interface-madness-programmer-creativity-expressivity black-holes. When you want to type less and deliver quickly, that is important.

Would I use Java to write a utility with objectives similar to what I mentioned in my first paragraph? Nope. Go is totally fine for it.

Panics that pop up in our logs are serious problems that we address. If you've got Go code panicking frequently, you're doing something wrong.

Panic is like sigsegv in C. Email the stack trace to the team that owns that server and if the numbers are high no more features till the stability is fixed.

Reply on news.ycombinator.com