There will never be a perfect language until there is a perfect programmer.
The perfect language and why Go still isn't it
41–50 of 139 posts
Re: The perfect language and why Go still isn't it
#42Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it - Go seems to have filled the space that Java was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to use for (which is everything). After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the…
> C++ too difficult/fun-less
C++ would be a lot more fun without the obligation to maintain header files all the time.
This is one thing that modern languages get right.
Re: The perfect language and why Go still isn't it
#43I feel like a variation of these steps could describe a lot of software in general, across industries.
Re: The perfect language and why Go still isn't it
#44There is no such thing as perfect. Good is good enough. Go is good for a lot of things.
Re: The perfect language and why Go still isn't it
#45Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it - Go seems to have filled the space that Java was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to use for (which is everything). After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the…
Kubernetes was transpiled to Go from Java, so I wouldn’t use it as an example in support of your point. (Read the source code; it’s pretty obvious — and it’s been confirmed elsewhere.). Some components such as etcd, however, are pure Go.
Re: The perfect language and why Go still isn't it
#46Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it - Go seems to have filled the space that Java was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to use for (which is everything). After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the…
Kubernetes was transpiled to Go from Java, so I wouldn’t use it as an example in support of your point. (Read the source code; it’s pretty obvious — and it’s been confirmed elsewhere.). Some components such as etcd, however, are pure Go.
And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy.
Also with GraalVM you can equally support low memory, fast startup use cases.
Re: The perfect language and why Go still isn't it
#47Earlier quoted context omitted.
Kubernetes was transpiled to Go from Java, so I wouldn’t use it as an example in support of your point. (Read the source code; it’s pretty obvious — and it’s been confirmed elsewhere.). Some components such as etcd, however, are pure Go.
And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy. Also with GraalVM you can equally support low memory, fast startup use cases.
I’m not sure that people are arguing about “supremacy” as much as they are arguing that Go was an attractive choice for the authors vis-a-vis other languages.
Getting into language or tool superiority arguments without deeply analyzing the environmental factors and use cases seems like a pointless exercise to me, and ought to be discouraged here IMO.
Re: The perfect language and why Go still isn't it
#48Earlier quoted context omitted.
Kubernetes was transpiled to Go from Java, so I wouldn’t use it as an example in support of your point. (Read the source code; it’s pretty obvious — and it’s been confirmed elsewhere.). Some components such as etcd, however, are pure Go.
And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy. Also with GraalVM you can equally support low memory, fast startup use cases.
Etcd may not be, but Consul is in my experience substantially easier() to run in production than ZK, and is also written in Go. I’d say this is nothing to do with implementation language and much more to do with a more understandable consensus model.
( based on having spoken to hundreds of operators of both over the last few years, while (disclaimer) working for HashiCorp and other distributed system vendors, but also having personally run both at serious scale)
Re: The perfect language and why Go still isn't it
#49Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it - Go seems to have filled the space that Java was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to use for (which is everything). After 20 years of coding, and having just recently discovered LISP and learned Clojure, I believe the perfect language will be a Clojure compiled to native with the…
> Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker
Go turned out to be a pretty bad choice for container tech due to its awful multithreaded runtime. Things could have been different if it focused on a single threaded runtime or provided control over OS threads, but it did neither.
Also neither of those projects were enabled by Go. One is a pretty low quality but strategic push into the cloud and other one is a pivot from an attempt to solve real problems of building a PaaS hosting platform.
Re: The perfect language and why Go still isn't it
#50Every time I've tried to write some go, I've always started reaching for some things that aren't there (essentially generics). I'm looking forward to go 2.0 and hope the inclusion of generics will make it more pleasant to write.
Also, while it's said comically often in HN comments, Rust (and particularly the iterator api) is very pleasing to write. I'd say it sits in quite a sweet spot language-wise.
Context, I'm a C++ programmer who had been writing in dynamic languages for the last couple of years.