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

241–250 of 296 posts

Re: Go runtime: 4 years later

#241

Post by Tozen »

todotask wrote: post #111
amedvednikov wrote: post #61

Earlier quoted context omitted.

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

I get you want to compare with Go, let have some benchmark. Despite V being new, the difference is quite insignificant for short-lived process in most case. You are more likely use Go for production at this time. https://programming-language-benchmarks.vercel.app/v-vs-go

Depends on the use case and persons involved. Nevertheless, V is on a constant march towards 1.0, and has been doing so at a higher pace than most other languages.

And, its not necessarily an "either or" or "us versus them" situation, people can use both or whatever else "floats their boat". It's a bit disheartening to see programmers that fall into being so closed-minded or disparaging to other options or something new.

Re: Go runtime: 4 years later

#242

Post by pdimitar »

pizza234 wrote: post #174
nu11ptr wrote: post #33

Earlier quoted context omitted.

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…

I've been surprised how writing Rust becomes smooth with experience (mostly; it's still complex in some areas), however, there's more to a language than just the formal part. Rust requires designing the memory management (ownership/lifetimes) of a program, which Golang doesn't, so even if/when the cognitive load is (hypothetically) equal, there's an additional, non-trivial demand. This is not something that everybody…

That's where I gravitate recently. I got a few more gray hairs learning and doing async Rust and I love the resulting program's speed and correctness.

But it's not easy to quickly prototype stuff with. Just recently I had to write no less than 7 small prototypes and I gave up on the second one, relearned Golang -- took me an hour -- and finished 3 prototypes in a day.

I tend to go all the way in languages so I can use them freely afterwards. But... In Rust's case I just can't justify the effort. Golang really helps you start off a project faster.

I'll still 100% Rust. I'm working on it every day. But indeed, let's use languages where they are at their best.

Re: Go runtime: 4 years later

#243

Post by [deleted] »

baby wrote: post #149
crudbug wrote: post #51

Earlier quoted context omitted.

Go disliking is due to its syntax not semantics. Go as a dynamic language runtime platform will be interesting; the platform defines the semantics and languages define syntax. On similar lines, Fable [0] project recently announced rust & dart runtime support making F# a very attractive choice. [0] https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.htm...

What? Go’s syntax is great. But it lacks sum types.

[deleted]

Re: Go runtime: 4 years later

#244

Post by cygx »

int_19h wrote: post #230
cygx wrote: post #170

Earlier quoted context omitted.

Not every runtime environment is a virtual machine...

That's true, but I would argue that any runtime with custom green threads is.

Would you consider the C runtime a virtual machine once you link against libdill or use OpenMP? If not, why not? If so, well, then we just disagree on the term 'virtual machine'. My litmus test would be the presence of some sort of well-defined instruction set.

Re: Go runtime: 4 years later

#245

Post by seer-zig »

baby wrote: post #134
nu11ptr wrote: post #33

Earlier quoted context omitted.

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…

I have a similar experience. Used to write a lot of golang, and now I write a lot of Rust. I think I would have pointed out the same issues: auditing Golang network code you can often find easy DoS attacks due to nil values being dereferences (protobuf I’m looking at you), there’s no sum types or enums, etc. Still though, I miss how easy it is to read golang and ramp up on a codebase. Even today I sometimes come acro…

It shouldn't be a Rust vs golang. golang is mostly a somewhat better python, and mostly for writing backend services.

You can compare its domain (to a certain degree) to Java or C#, in which case the latter two are superior due to the reasons mentioned previously (enums, pattern matching, etc.).

Re: Go runtime: 4 years later

#246

Post by seer-zig »

cies wrote: post #171
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 agree. It feels a bit like where Java/JVM is at: popular, solid runtime, large community/ecosystem, but Java made some bad choices. In my opinion: Go needs a Kotlin. First and foremost to do away with implicit nulls (imho the biggest mistake), but here are other things that could be impoved you've already mentioned.

The good thing is that Java is incorporating the proven features of other languages. It has gotten records, pattern matching (better than Kotlin's), and in the latest release, virtual threads with structured concurrency, better than async/await, and also better than golang as it lacks structured concurrency.

Re: Go runtime: 4 years later

#247

Post by seer-zig »

0xjnml wrote: post #233
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

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

Re: Go runtime: 4 years later

#248

Post by yencabulator »

tbrock wrote: post #38

I am not a fan of new knobs like this. It reminds me of Java where you actually have to think about -xMx blah blah and setting it is a dark art. I would really prefer if we could somehow confer the memory limit from the container environment to go so this could be set intuitively at the container level without mucking about in the go GC internals.

Well, what you got is

1. runtime feature to limit memory use

2. a mechanism to configure it

What we just don't have yet is

3. standard way to read container memory limit

Once that comes to existence, the first two were gonna be needed anyway. And now you can experiment with #3 for the various container runtimes.

Re: Go runtime: 4 years later

#249

Post by seer-zig »

kweingar wrote: post #203
simiones wrote: post #194

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.

Having worked on even medium sized projects in golang, I started to appreciate why Java requires that. The golang code base was a mess, struct declarations and their implementations littered all over the place, making it hard to follow what's going on. You then need and IDE, and hope that those structs do not accidentally implement some random interface because of structural typing.

Re: Go runtime: 4 years later

#250

Post by Tozen »

seer-zig wrote: post #245
baby wrote: post #134

Earlier quoted context omitted.

I have a similar experience. Used to write a lot of golang, and now I write a lot of Rust. I think I would have pointed out the same issues: auditing Golang network code you can often find easy DoS attacks due to nil values being dereferences (protobuf I’m looking at you), there’s no sum types or enums, etc. Still though, I miss how easy it is to read golang and ramp up on a codebase. Even today I sometimes come acro…

It shouldn't be a Rust vs golang. golang is mostly a somewhat better python, and mostly for writing backend services. You can compare its domain (to a certain degree) to Java or C#, in which case the latter two are superior due to the reasons mentioned previously (enums, pattern matching, etc.).

Agree, about the "us vs them" mentality. The tribalism has gotten out of hand, though I kind of suspect some of it is corporate interests being behind it to push the illusion its a "winner take all" game and "putting the batteries in the backs" of many of the evangelists.
Post reply on HN