Well, 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 ease of Go (e.g. w/ similar import system).
>Well, Go seems to have enabled a new wave of software renaissance - Kubernetes, Docker, you name it
Let's name it. I wouldn't call either of these a "software renaissance". Docker is a wrapper on top of Linux kernel containers, and Kubernetes is a 10000 pound gorilla on top (and port of a C++ app, some say even through a Java rewrite/transpile to Go).
Go was just at the peak of being fashionable at the time (and had some basic features not semantics/syntax related like easy static compilation and cross platform-ness) so got adopted by these projects, the same way many new projects now use Rust.
> 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.
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.
I've been learning a bit of Go and I like what I've understood so far but one thing that seems somewhat lacking in the Go Eco system is mathy projects. I know there are some but I couldn't find many that were both active and to my taste. I was looking to learn and hopefully contribute. I was mostly looking for something mature for either mathematical optimization (stuff like linear, quadratic or integer programming) and (non-DL) machine learning. For C++, Java, Scala, Python and Julia (less sure about this), there seems to be much more.
You can compare Go's gonum to Python's numpy. For Java's Weka, Scala's MLlib, Python's scikit-learn, C++'s Dlib to what Go is offering.
Maybe Go leans more on its C-interop for these sorts of things which is a bit like numpy.
Considering it took you that long to be a Lisp convert, I like to know more on how you came to the see the light. I’ve been doing coding for over 15 years, too. And, every time I tried to pick up a Lisp dialect (Clojure was the last) I couldn’t help but wonder what with all the buzz about this. I really wish that I could see the light someday, though.
I think it should always be mentioned when people call java fat, that the core language is usually fast enough. What makes java "fat" is the mentality of "Frameworks".
For me, Go seems like java, but without the fucking frameworks.
Every language has flaws. Some of the best languages are those that take existing languages and just throw out some of the bad legacy mistakes, making what’s often a slightly different but pretty much objectively “better” language.
For example: Kotlin is a better Java in almost every way.
The problem with almost all such languages is that they aren’t different enough from their “parent” languages, meaning they struggle to gain traction. Both D and Kotlin are here.
I think Kotlin has also leapfrogged D on this — Google blessing it for Android use and an Android community clearly hoping for something better than an aeons-old version of Java goes a very long way.
The Android success story might just be what the language needs to establish itself enough that it’ll become a backend staple too
Go is actually pretty close to the perfect language to me -- for "general purpose" computing, at least. Sure, it's plain and somewhat boring to write but it doesn't make me that much less productive. Error handling and generics are the only other features that I want, so I'm really looking forward to Go 2, if that ever comes around. I would be happy to see Go declared "feature-complete" at that point, similar to Elixir [1].
But even then, if I want to have fun and feel like I'm learning new things while I code, I'll always use something else that's more interesting.
Go and Rust are the latest languages I started to use. Neither is perfect, both are awesome, but more importantly, both are a step forward, both get a lot of things very right, and for the rest, most are at least acceptable. When I code, most of my frustrating moments come from underlying problems with cross compatibility, access to hardware, graphics, encodings, etc, which are rarely problems caused by languages themselves.
We are pretty new at this, we are still trying to figure out a lot of things. We are still experimenting a lot with many features. But step by step, new language after
new language, we keep improving.
Trying to be realist tends to be a painful exercise, but in the case of programming languages, I think the situation is looking pretty good. There might be a billion paths left to explore, but at least the ones we are exploring are bringing something useful to the table. I hope we soon start writing articles titled "the perfect languages and the exciting ways we are getting closer to them". The article was pretty good, by the way.
Go has some great 'under the hood' features, ie ones provided by its runtime, but man the language syntax makes it really annoying to take advantage of them. The sweet spot for me would be something between Go and Rust, ie a language with generics, algebraic data types, pattern matching, garbage collection, good concurrency primitives with a good work stealing scheduler.
So I'm basically asking for OCaml with multithreading.
Wait... We must having different definition of perfect. I would say Go is a very good language, and probably be one of the best in terms of simple and practical design, fast execution, fast compilation etc.
The perfection, however, is not something Go never meant to be. The perfect language possibly support fully dependent type like Idris while maintains zero abstraction cost like Rust, having precise syntax rule like Lisp, and a powerful runtime like Erlang, and the list goes on.
The success of Go lies in it's trade-offs, the designers are opinionated, knowing well what they want and what they don't, and executes things well in the implementation.
Every 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.
Go isn’t the perfect language because it doesn’t intend to be. Likely, as this article seems to hint at, there’s no such thing and there never will be. Go has a well defined set of design goals (including simple and pragmatic) that it has achieved.
Let me break it to you, there is no perfect language, just the ones most general purpose enough to cover most common problems and most suited for your applications. Each language has it own use and one doesn't trump another in terms of functionality or usage, they only compete when they lie in the same paradigm and this is where most language oriented comparisons are drawn whether be it time of execution or performance. This is also why there are more than one language within the same paradigm, as each one tends to have it's own intricacies and features that was solely developed for the purpose of improving upon it's predecessor. So there you are, stuck with more than one language to suit your needs and hence the untenable need for a perfect language.
Also, trying to bend a certain language to adopt features and functionality that are unwarranted for it's use cases is another reason for the criticism some languages draw upon from the community, therefore it's best for the language to stick to what it does best and stop it at that instead of trying to fit in to uses which it was never intended for when it was first developed. But the language itself is agreeable to evolve through time, but to constrain itself to it's actual purpose would be better for both the language and it's users.
Languages are software products like everything else, so they either improve to cater for their "customers" and survive against competition, or they wither and die into some kind of maintenance corner.
Even languages that supposedly no one uses like Fortran and Cobol, get their standards revisited every couple of years.
One might not want to re-write that surviving Cobol program into a reactive text UI with a couple of FactoryFactory classes, but it is surely possible as per latest language features.
Language can't be small, if it's universal enough. Otherwise you end up with trade-offs for its size, which limit scenarios where that language can be used.
So there is no "perfect" language. All languages have some trade-offs. If you want small - you pay for it.
It's a futile quest to find the perfect programming language. Any language that gains popularity will face a vocal demand for new features at some point. But it's not just about adding new concepts. Programmers also want new shortcuts for existing features to save them a few keystrokes. That then entails issuing recommendations on when to use such shortcuts to keep code consistent.
There are plenty of small languages, but they lack popularity or rich libraries. The only language I can think of that remains in widespread use and is fairly small in language size is C.
I'm strongly in the camp that small languages are preferable to large ones and wish language designers would follow this principle more closely. But small does not necessarily mean more readable. And language syntax design remains a neglected aspect of programming language design.
It's FreePascal. Nobody believes me, but we have perfection already. No crap you don't need. No crazy corner cases. No C++ templated metaprogramming lambda auto pointer garbage. No "I can't write a linked list without a Grimoire" Rust.
It's great. You get a ton done, and simply ignore the language wars. No VM trash (Java). No web trash (JavaScript/"Webasm"). No crap.
Try all the others, and try FreePascal. It's old enough that people aren't bolting on stupid shit. The community is awesome. Everybody just gets shit done. There's a lot of art if you go looking, but none of it requires a kilopage book to describe.
One of Go’s strength is the opinionated nature that makes it easy for me as a developer to read and understand other’s code. It’s trivial to jump into the implementation of the standard API to see how things work.
The frustrating thing about Go for me is that it lacks generics but is strictly typed, which encourages the passing of empty interfaces which can cause problems at runtime. You have to be very careful about storing all your data properly in structs or you face a big foot gun.
Which, like, fair enough. It's not perfect. But it's still really really good. I mean, people still use Java...
I really like Go (and Rust) and would like a job as its main language. However I don't have enough experience with the language, anyone know the job market and recommend a path or should I give up? I don't have time to spend a few hours/wk just to learn enough to get experience.
[+] [-] ypcx|6 years ago|reply
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 ease of Go (e.g. w/ similar import system).
One such direction seems to be Carp (https://github.com/carp-lang/Carp), but I haven't tried it yet.
[+] [-] coldtea|6 years ago|reply
Let's name it. I wouldn't call either of these a "software renaissance". Docker is a wrapper on top of Linux kernel containers, and Kubernetes is a 10000 pound gorilla on top (and port of a C++ app, some say even through a Java rewrite/transpile to Go).
Go was just at the peak of being fashionable at the time (and had some basic features not semantics/syntax related like easy static compilation and cross platform-ness) so got adopted by these projects, the same way many new projects now use Rust.
[+] [-] zzzcpan|6 years ago|reply
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.
[+] [-] otterley|6 years ago|reply
[+] [-] amelius|6 years ago|reply
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.
[+] [-] snowAbstraction|6 years ago|reply
You can compare Go's gonum to Python's numpy. For Java's Weka, Scala's MLlib, Python's scikit-learn, C++'s Dlib to what Go is offering.
Maybe Go leans more on its C-interop for these sorts of things which is a bit like numpy.
Am I missing something? Will this change?
[+] [-] mrbonner|6 years ago|reply
[+] [-] delusional|6 years ago|reply
I think it should always be mentioned when people call java fat, that the core language is usually fast enough. What makes java "fat" is the mentality of "Frameworks".
For me, Go seems like java, but without the fucking frameworks.
[+] [-] pjmlp|6 years ago|reply
[+] [-] alkonaut|6 years ago|reply
For example: Kotlin is a better Java in almost every way.
The problem with almost all such languages is that they aren’t different enough from their “parent” languages, meaning they struggle to gain traction. Both D and Kotlin are here.
[+] [-] pdpi|6 years ago|reply
The Android success story might just be what the language needs to establish itself enough that it’ll become a backend staple too
[+] [-] degraafc|6 years ago|reply
But even then, if I want to have fun and feel like I'm learning new things while I code, I'll always use something else that's more interesting.
[1]: https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
[+] [-] slx26|6 years ago|reply
We are pretty new at this, we are still trying to figure out a lot of things. We are still experimenting a lot with many features. But step by step, new language after new language, we keep improving.
Trying to be realist tends to be a painful exercise, but in the case of programming languages, I think the situation is looking pretty good. There might be a billion paths left to explore, but at least the ones we are exploring are bringing something useful to the table. I hope we soon start writing articles titled "the perfect languages and the exciting ways we are getting closer to them". The article was pretty good, by the way.
[+] [-] zinclozenge|6 years ago|reply
So I'm basically asking for OCaml with multithreading.
[+] [-] namelosw|6 years ago|reply
The perfection, however, is not something Go never meant to be. The perfect language possibly support fully dependent type like Idris while maintains zero abstraction cost like Rust, having precise syntax rule like Lisp, and a powerful runtime like Erlang, and the list goes on.
The success of Go lies in it's trade-offs, the designers are opinionated, knowing well what they want and what they don't, and executes things well in the implementation.
[+] [-] networkimprov|6 years ago|reply
https://ziglang.org/
[+] [-] agumonkey|6 years ago|reply
[+] [-] mijoharas|6 years ago|reply
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.
[+] [-] ccday|6 years ago|reply
[+] [-] abvr|6 years ago|reply
Also, trying to bend a certain language to adopt features and functionality that are unwarranted for it's use cases is another reason for the criticism some languages draw upon from the community, therefore it's best for the language to stick to what it does best and stop it at that instead of trying to fit in to uses which it was never intended for when it was first developed. But the language itself is agreeable to evolve through time, but to constrain itself to it's actual purpose would be better for both the language and it's users.
[+] [-] pjmlp|6 years ago|reply
Even languages that supposedly no one uses like Fortran and Cobol, get their standards revisited every couple of years.
One might not want to re-write that surviving Cobol program into a reactive text UI with a couple of FactoryFactory classes, but it is surely possible as per latest language features.
[+] [-] shmerl|6 years ago|reply
So there is no "perfect" language. All languages have some trade-offs. If you want small - you pay for it.
[+] [-] themango|6 years ago|reply
Also make some popcorn and enjoy the Twitter flame wars while you're at it.
[+] [-] open-source-ux|6 years ago|reply
There are plenty of small languages, but they lack popularity or rich libraries. The only language I can think of that remains in widespread use and is fairly small in language size is C.
I'm strongly in the camp that small languages are preferable to large ones and wish language designers would follow this principle more closely. But small does not necessarily mean more readable. And language syntax design remains a neglected aspect of programming language design.
[+] [-] pjmlp|6 years ago|reply
And if we consider the amount of compiler specific C extensions, across all C implementations, it gets even bigger.
[+] [-] analognoise|6 years ago|reply
It's FreePascal. Nobody believes me, but we have perfection already. No crap you don't need. No crazy corner cases. No C++ templated metaprogramming lambda auto pointer garbage. No "I can't write a linked list without a Grimoire" Rust.
It's great. You get a ton done, and simply ignore the language wars. No VM trash (Java). No web trash (JavaScript/"Webasm"). No crap.
Try all the others, and try FreePascal. It's old enough that people aren't bolting on stupid shit. The community is awesome. Everybody just gets shit done. There's a lot of art if you go looking, but none of it requires a kilopage book to describe.
[+] [-] AdeptusAquinas|6 years ago|reply
[+] [-] thegabez|6 years ago|reply
[+] [-] tus88|6 years ago|reply
[+] [-] cygned|6 years ago|reply
[+] [-] patientplatypus|6 years ago|reply
Which, like, fair enough. It's not perfect. But it's still really really good. I mean, people still use Java...
[+] [-] rb808|6 years ago|reply
[+] [-] Wowfunhappy|6 years ago|reply