Live data from Hacker News

Go runtime: 4 years later

go.dev

261–270 of 296 posts

Re: Go runtime: 4 years later

#261
post #238

Earlier quoted context omitted.

Quoted post unavailable.

That's complete and uncalled for troll nonsense. V has hundred of releases ( https://github.com/vlang/v/releases ), with hundreds of contributors to its open-source project (577 and growing). It exists and works. It's one thing to like some other language, its another thing to spew disinformation, lies, and flames about others.

The V creator makes a lot of promises but most don't pan out. When pressed on them, they often say it's "planned," not actually here, even though their marketing says it is here.

Some good links to read:

https://news.ycombinator.com/item?id=20230351

https://xeiaso.net/blog/v-vaporware-2019-06-23

https://xeiaso.net/blog/OVE-20190623-0001

Re: Go runtime: 4 years later

#262

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.

I can't agree with that at all. Checked exceptions can all be bubbled up to a single catch if that's how you want to handle it. That hardly pollutes a codebase.

Re: Go runtime: 4 years later

#263

Earlier quoted context omitted.

> 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 ev…

they could have had a flag for people who prefer those issues to be warnings. for me, they slow my debugging down a great deal

Re: Go runtime: 4 years later

#264
post #155
post #142

Earlier quoted context omitted.

What do you have against BLM?

Not him, but people outside of US don't care about US social and political issues. Even if Go is used 90% by Americans, website for programming language is still not a place to push politics.

I'm from New Zealand. There's support for BLM here. It's not like being non-white is a US only issue

Re: Go runtime: 4 years later

#265
post #201
post #142

Earlier quoted context omitted.

What do you have against BLM?

My personal opinions aside, what does a programming language has to do with a political movement in one of the 195 countries in this world? Nothing, that's what. The political activists hijacked the Go community they had access to and power over for their own personal beliefs and agenda disregarding every bit of ethics or responsibility they were entrusted with. As the saying goes, with great power comes great respon…

Whereas I appreciate their actions. I don't feel that respecting people's human rights is "forcefully shoving their own personal beliefs down my throat"

Re: Go runtime: 4 years later

#266

Earlier quoted context omitted.

If you really need this, you can always expose all your actual classes as public static class members of a single wrapper class: public class Wrapper { public static class C1 { } public static class C2 { } } //other module: var x = new Wrapper.C1();

You could do that, but it doesn’t work with interfaces. The Go style just lets your code live together for easy reading, no problem. You can comfortably fit all of this into one file: a one-function interface, a couple of small functions that take the interface as a parameter, and two implementations of the interface. Compare this to 3 or 4 tiny Java files. You’d have to guess which one to click on first.

Interesting that you mention interfaces. Mostly I like Go, but one of my bugbears is the difficulty of finding out which interfaces are implemented by a type. It's much easier in Java. Java file organisation is more consistent and regular which is a win at scale.

Re: Go runtime: 4 years later

#267

Earlier quoted context omitted.

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 ev…

they could have had a flag for people who prefer those issues to be warnings. for me, they slow my debugging down a great deal

Then most (if not all) Go programs wouldn’t compile without that flag.

If something can be abused, it’s going to be abused.

Re: Go runtime: 4 years later

#268
post #183

Earlier quoted context omitted.

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.

Maybe, but then, when Jackson is throwing an IOException because of bad JSON, and the file you opened that had the JSON could also throw an IOException, then it's not just catch it at a single place, as you'd generally handle both differently.

Re: Go runtime: 4 years later

#269

Earlier quoted context omitted.

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.

I can't agree with that at all. Checked exceptions can all be bubbled up to a single catch if that's how you want to handle it. That hardly pollutes a codebase.

Sure. But the bubbling of checked exceptions adds a lot of "foo() throws DeepUnderlyingException", all the way up to your single catch.

And the worst part is when reading the code in such a situation, it can get very tricky to figure out exactly where the exception is thrown.

There's a reason that the JVM ecosystem has largely moved away from checked exceptions.

Re: Go runtime: 4 years later

#270
post #233

Earlier quoted context omitted.

> I think if Golang would have been invented a couple of years later it def would have had sum types. How to combine sum types and a precise garbage collector?

They're not mutually exclusive. Scala and Haskell had them for a long time now, and Java got them relatively recently.

How can a precise garbage collector work when it does not know if a value is or is not a pointer?
Post reply on HN