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

161–170 of 296 posts

Re: Go runtime: 4 years later

#161

Post by IshKebab »

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 agree. I wonder if we'll start to see other languages target the Go platform, like with the JVM.

Re: Go runtime: 4 years later

#162

Post by [deleted] »

bobbylarrybobby wrote: post #101
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…

Two comments: There are two reasons to have match: exhaustiveness and destructuring/pattern matching. I don't think there's an if/else parallel to `match result { Ok(t) => { ... }, Err(e) => { ... } }` The fact that a `nil` value can be made useful (which, AFAICT, means it won't blow up your program?) is not a good enough reason to include them in the language. Rust can do perfectly useful things with, say, `Option >…

[deleted]

Re: Go runtime: 4 years later

#163

Post by kaba0 »

philosopher1234 wrote: post #156
kaba0 wrote: post #151

Earlier quoted context omitted.

What is hard about Java? It is a very small language.

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 will catch most of your problems at compile time, and first and foremost, very well-defined runtime semantics, even when errors happen, all of which help beginners greatly.

Re: Go runtime: 4 years later

#164

Post by jackosdev »

EdwardDiego wrote: post #159
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.

So if GetFoo returned a non-nil error, would the function abort and immediately return the error? I'm used to a question mark being around null handling, but you know, JVM languages lol, null is thought about a lot.

Yeah exactly, it makes everything so much more ergonomic, especially with combinators, as in chaining method calls that might return an error

Re: Go runtime: 4 years later

#165

Post by rob74 »

wooque wrote: post #155
baby wrote: 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 not from the US either, but I don't think that asserting that all people should be treated equally is "politics". Actually it's a basic human right that I think most of us agree with - at least in theory, the problems only come when applying it in practice...

Re: Go runtime: 4 years later

#166

Post by masklinn »

kaba0 wrote: post #150
baby wrote: post #144

Earlier quoted context omitted.

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

It’s not like sum types weren’t known a decade before that. Or generics. They just didn’t care.

These issues were also brought up immediately when the language was first shown, alongside nulls, tuples, error handling, etc…

Re: Go runtime: 4 years later

#167

Post by randomdata »

jackosdev wrote: post #157
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…

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 immediately and, if there is no better option, return your own error that describes the problem in a non-implementation-specific way.

It is possible that with other error-related features added to the language you could avoid those traps, but Go doesn't feature those either, so simply adding that construct without thinking about the problem much more deeply doesn't buy you much.

If you are solving a stop the world when you encounter an error-type problem that might be okay, although I'd argue that you may as well panic instead. But, again, Go isn't designed for those problems and I'm not sure it needs to be. There are already plenty of good languages designed for that type of work.

Re: Go runtime: 4 years later

#168

Post by cercatrova »

zarzavat wrote: post #86
steveklabnik wrote: post #54

Earlier quoted context omitted.

It’s funny how experiences differ; I can’t comment on how Go fares here, but if anything, I find that the compiler takes such a mental load off of my shoulders that Rust is the language I find easiest to make large refactorings in.

The differentiating factor is probably prior exposure to C++. If you have used C++ then Rust is so easy and convenient and fun. It takes hideous C++ monstrosities and turns them into easy one liners. If you have never used C++ and your baseline is Go or JavaScript then it probably looks like a confusing hellscape. You have to learn a whole new kind of type system, a new nomenclature (“Vec”s instead of “Array”s), new…

Not really. I come from TypeScript and started writing Rust, and they're quite similar in terms of type expressiveness. With both I feel the same level of comfort of refactoring.

Meanwhile Go doesn't even have algebraic data types. I can't imagine working with a language that doesn't have these kinds of functional features anymore after having gotten used to them.

Re: Go runtime: 4 years later

#169

Post by cercatrova »

amedvednikov wrote: post #61
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…

V fixes most of these, but it doesn't use Go's runtime: https://vlang.io/compare#go

No post body was provided.

Re: Go runtime: 4 years later

#170

Post by cygx »

int_19h wrote: post #145
wejick wrote: post #74

Earlier quoted context omitted.

go runtime is not VM like JVM [0]. Go doesn't run on top of runtime, more like run along side it. That's why there's go for embedded where it has no runtime. So it's very less likely other language reuse go runtime. [0] https://go.dev/doc/faq#runtime

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...
Post reply on HN