HN2new | past | comments | ask | show | jobs | submitlogin

What it needs is Rust style static lifetime management.


As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly.

Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifetime management work. Unless something has changed radically in the recent past, that's not something that the Go community had much interest in (yes, I know that generics are one step in that direction, but I'm not aware of further steps being discussed).


If you're at the point that serious GC performance is being examined, then a rewrite to rust is something that should be considered on the strategic roadmap if it is code you have control over (versus third party / OSS software).

I think Go has a maximum expansion footprint. People presumably use Go because it is faster and better GC than Java. Rust will probably eat a lot of that territory. That will leave people that like it strictly for language/idiomatic reasons, and that won't be enough.

The entire meta-point of the post is to try to argue that Go is "better" than Java GC-wise. Well, it is and it isn't in reality, as benchmarks and people in the know have said. If it is "better" it is a very unconvincing win.

As someone wise said 10 years ago, you almost need 10x the performance to have a convincing improvement to get laypeople to notice, and to get dev people to consider switching from legacy/entrenched ways of doing things.

Here, there's basically no real world improvement to point to.


> You require a pretty strong type system to make static lifetime management work

Go is strongly and statically typed.


Go's type system is much, much weaker than what is needed for safe static lifetime management be even remotely close to workable.

Static typing is not an on-off, there are statically typed languages with extremely weak type systems (e.g. C), languages with somewhat weak type systems (e.g. Java, Go), languages with strong type systems (e.g. OCaml, Haskell) and languages with extremely strong type systems (e.g. ATS, Idris).

And that's a simplification because it's not linear either.


Rust's lifetimes need full subtyping, with covariant and contravariant type constructors (though I don't think it supports annotations for them, and always infers them instead), which I think would make the generics implementation quite a bit more complicated than it currently is...


Yeah, the fact that co/contravariant type constructors aren't (or aren't always?) annotated has always felt a bit awkward to me. Ah, well, it works :)


For some value of "strongly". It has nil and lacks sum types, so it is comparatively much weaker than even Rust/Swift.


It's a spectrum. Rust is further than Go in the direction of "strong type system", and somewhat lateral wrt Haskell, F# or OCaml, for instance (each is more strongly typed in different directions). Idris or Coq are further than Rust in most directions, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: