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

71–80 of 296 posts

Re: Go runtime: 4 years later

#71

Post by wtetzner »

kevinmgranger wrote: post #55
pjmlp wrote: post #16

Earlier quoted context omitted.

As does OCaml since 1996, no need for sugar substitute instead of using the real deal. Compiles to native code, has a repl, version 5 is multicore for those not happy with Lwt or multiprocessing in the UNIX classical style of each tool does one thing, and a GC only second to GHC in handling immutable types.

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.

OCaml-on-Go also doesn’t exist…

Re: Go runtime: 4 years later

#72

Post by akira2501 »

aatd86 wrote: post #53
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…

If I may ask, I'm curious about why you wouldn't use it to build a User Interface?

One is Go's module/import system. It's pretty inflexible and the connection between exported functions and types and how they are Capitalized or not does create friction for me when I'm "building up" code bases from scratch. Puzzling about module boundaries and type definitions feels like it would consume more time than it's worth in a UI oriented program.

The other is most UIs are wrappers around other functionality, often in libraries. Working on anything other than pure Go code bases adds additional friction, and dynamic libraries add to that complication considerably.

Re: Go runtime: 4 years later

#74

Post by wejick »

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

Re: Go runtime: 4 years later

#75

Post by kungfufrog »

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 value prop is it's not Rust or C?

Re: Go runtime: 4 years later

#76

Post by lairv »

Zababa wrote: post #30
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…

> In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. OCaml kind of gives you that, but the dev experience isn't as good as Rust or Go in my opinion. Still, I enjoy it a lot, more than Go or Rust.

Does OCaml matches Go speed though ?

Re: Go runtime: 4 years later

#77

Post by drogus »

Thaxll wrote: post #64
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…

Rust is adding new features at the speed of C++/C# which is quite bad imo, it's good a recipe to have different code base / way of doing things in just couple of years apart. Now for Rust there are many things that could be changed, async etc ...

What exactly has Rust added in recent months or even years? The way I see it most changes in the language are making existing features work more consistently.

Re: Go runtime: 4 years later

#78

Post by pbohun »

I'm really grateful for everyone who has made Go possible and continues to make it better. Well done language design, extensive standard library, good tooling, and great documentation is something that's almost impossible to find despite there being a multitude of languages.

Re: Go runtime: 4 years later

#79

Post by qaq »

nu11ptr wrote: post #33
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…

I will agree Rust has a higher "cognitive load", but not if you write it every day. I think Rust might be tough to leave and come back say a year later, but Go admittedly would be easy. That said, having written 50K+ code in both languages, I never want to write Go again. Rust on the other hand is all I want to write now. I do wonder how many people who understand Go's limitations (and work around them as you point o…

Async code is way nicer in Go than it is in Rust. It makes up for a lot for me when writing web services. Also Go is much easier to read vs Rust.

Re: Go runtime: 4 years later

#80

Post by nu11ptr »

Thaxll wrote: post #64
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…

Rust is adding new features at the speed of C++/C# which is quite bad imo, it's good a recipe to have different code base / way of doing things in just couple of years apart. Now for Rust there are many things that could be changed, async etc ...

At first I thought this too, but if you look at the actual "features" they are adding they are all more less just smoothing out existing features. There aren't really any major new ones I can't think of that expand the "surface area" of the language. There is just a lot of polish still needed, esp. to things like async, const, etc. and most of the features appearing are about reducing the burden to use existing features.
Post reply on HN