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

191–200 of 296 posts

Re: Go runtime: 4 years later

#191

Post by simiones »

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.

Python is generally considered quite strongly typed, though dynamic. That is because Python has relatively few implicit conversions, and especially few that are surprising ("1" + 1 is an error, not 2 or "11"; and unsigned short + unsigned short does not equal a signed int).

Re: Go runtime: 4 years later

#192

Post by tialaramex »

akira2501 wrote: post #32
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…

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…

> The phenomenon I notice in languages that do have it, is the majority of uses cases seem to be a pattern match with two outcomes, one a Some() and the other a None(). It really seems like a more annoying way to write if {} else {}.

In Rust you write this type of thing as:

  if let Some(name) = order.get_name() {
   println!("Order ready for {name}!");
  } else {
   println!("Order number {} ready!", order.num());
  }
So, it's a destructuring pattern match just written as an if-else. Because we did the match here, we can't forget and end up using name when there wasn't one, the variable only exists when it's bound.

Re: Go runtime: 4 years later

#193

Post by morelisp »

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

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

"Nil is useful", in Go, means that for expensive objects it's often appropriate to pass nil instead of an empty or defaulted object, and call methods on it that act as if it was an empty object or with some default/no-op behavior. This is most obvious with lists/maps but can be applied to all concrete types.

While I can imagine a language in which `Option` can re-export some of `T`'s method set with a default behavior, in practice I don't know any which actually do this.

Re: Go runtime: 4 years later

#194

Post by simiones »

kweingar wrote: post #188
kaba0 wrote: post #163

Earlier quoted context omitted.

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

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();

Re: Go runtime: 4 years later

#195

Post by simiones »

kaba0 wrote: post #151
baby wrote: post #146

Earlier quoted context omitted.

I found it much easier than java, and a bit harder than python, for reference

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

I don't think that's really true, at least not anymore. It's definitely smaller than C++ or Rust, slightly smaller than C#, but larger than Python, JavaScript, Go.

Re: Go runtime: 4 years later

#196

Post by simiones »

pjmlp wrote: post #122
kevinmgranger wrote: post #55

Earlier quoted context omitted.

I get that everyone has their own favorite tools, but "use a version that isn't out yet, or use separate processes for parallelism" is a non-answer. I'm excited for version 5, but until it's out, it's hard for people to take seriously in conversations about _Go_ of all things.

It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help. Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.

I generally agree about the runtime and language semantics.

However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).

Re: Go runtime: 4 years later

#197

Post by simiones »

wejick wrote: post #74
throwamon wrote: post #3

Still yearning for an Ocaml-like language that uses the Go runtime.

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

I would wager there are far more embedded devices running Java than Go. Though, to be fair, it's usually a stripped-down version of Java.

Re: Go runtime: 4 years later

#198

Post by simiones »

intelVISA wrote: post #66
Thaxll wrote: post #14

Earlier quoted context omitted.

No one really care about binary size increase , especially because you can run a Go binary in a docker image with 0 dependencies ( scratch image ) which has a very small size.

You can build a much smaller 0 dependency binary in Rust/C so what's the value prop for Go here?

The single biggest silver bullet for provable bug reduction that has ever been invented: GC.

Perhaps the Rust burrow-checker will prove to be the second silver bullet for bug reduction, but for now, the only thing that has ever been invented in programming language design that provably reduces the amount of bugs in an application is having a GC (not types, not getting rid of null values, not monads or other HKTs, not CSP).

Re: Go runtime: 4 years later

#199

Post by bayindirh »

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.

I think it goes both ways. Yes, eliminating unused variables and imports accelerates compilation. Also, compilation speed is a great deal for Go, but keeping the code devoid of unused variables also reduces the cognitive load of humans a lot. Keeping language simple is another feature which helps both ways.

Re: Go runtime: 4 years later

#200

Post by fnord123 »

kaba0 wrote: post #186
peaky_blinder wrote: post #184

Earlier quoted context omitted.

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?

First iteration was didn't include the part about haskell/ocaml.
Post reply on HN