13 ms·

The perfect language and why Go still isn't it

114 points by snazz 7y ago

ccday 7y ago
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.
- littlestymaar 7y ago
  > Go has a well defined set of design goals (including simple and pragmatic) that it has achieved. If your look how much changes are proposed as part of the Go2 work, I'm not sure the Go developers agree with you.
  - majewsky 7y ago
    Yet the concrete proposals keep getting shot down or reworked. If anything, this makes me more sure that the Go developers care about their core design goals. They are listening to community feedback, but they don't allow a vocal minority to bury the original vision.
themango 7y ago
There's never going to be a perfect language -- stick with what gets the work done for the situation at hand. Also make some popcorn and enjoy the Twitter flame wars while you're at it.
thegabez 7y ago
The perfect language is the one humans won't have to write.
analognoise 7y ago
This already exists, but it isn't trendy. 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.
- pjmlp 7y ago
  As much as I like Pascal, and I am a big fan since Turbo Pascal since version 4 for MS-DOS, using all of them until about Delphi 3, lack of some kind of automatic memory management is a killer for anyone that cares about code security. Delphi only supports it for COM and Objective-c/Swift interoperability, everything else is as manual as TP for MS-DOS, and I bet FP hasn't improved in that regard.
  - ckok 7y ago
    RemObjects Oxygene does. All targets have a GC (boehm on win32,64, Linux and Darwin, .net and java have their own of course) or arc (cocoa).
    - pjmlp 7y ago
      Thanks for the heads up. However that isn't Free Pascal, which was the OP's point. Having said that, RemObjects Oxygene is probably an alternative then. :)
      - ckok 7y ago
        Yep. It is Pascal though. That's why I mentioned it
  - _ph_ 7y ago
    Ah, a young lad :) I started tinkering with Turbo Pascal 3 and even have some experience with Pascal on the Apple II. (Not because I am THAT old, but that were the only computers my school had at the end of the 80ies) The successors of Pascal are also highly interesting. I used Modula-2 quite a lot, but never got deep into Oberon. I do think one big advantage of Go is, that it so strongly draws on the Wirth languages that it almost can be considered a modern successor. And I fully agree, one shouldn't use a language these days for general programming without some kind of automatic memory management. Which is the other aspect which drew me towards Go, a nice nativley compiled language with a GC.
    - 7y ago
pjmlp 7y ago
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.
degraafc 7y ago
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. [1]: https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/ https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...
shmerl 7y ago
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.
- chewxy 7y ago
  > Language can't be small, if it's universal enough t, u := x | λx.t | (t u) Small language (three production rules), definitely universal. Of course the semantics is a lot more complicated than most people expect. But it IS syntactically very simple
  - shmerl 7y ago
    Theoretical cases that are unusable in practice aren't interesting in the above context. We are talking about practical languages. It's not about Turing completeness.
    - chewxy 7y ago
      s := a | (s s) common lisp syntax. Even simpler, but that shifts much of abstraction capabilities to the operational semantics.
- Someone 7y ago
  I agree that every language has its trade-offs, but you can move lots of stuff into the standard library of the language. Taken to the extreme, the result can be an extremely small language. If your language is expressive enough, the result can also look like it is a much larger language. For example, Forths implement if/else, for/do, while/do, repeat/until, switch/case in terms of some stack manipulation and ‘jump’. Similarly, Common Lisp builds its control structures, object oriented programming support, etc, out of a few primitives.
tus88 7y ago
Go isn't even close. It has an interesting runtime though.
holografix 7y ago
I think Go could be fundamentally improved if it somehow offered a REPL.
- random42 7y ago
  Checkout https://github.com/containous/yaegi https://github.com/containous/yaegi . Don't think its very mature though.
- H8crilA 7y ago
  So you're at step 3?
  - Dylan16807 7y ago
    From the article? Not at all. It doesn't matter if it's easy or difficult, because it only needs to be coded once. And it's not a request to change the language at all, just the tooling.
    - marcus_holmes 7y ago
      I don't really understand how a REPL would help with coding Go. I think I use tests to do what I think people use REPLs for, and I don't get why I'd change that to a REPL if I could - having those tests permanent is a good thing. What would a REPL bring to the party?
      - casion 7y ago
        A REPL allows you to work in real-time with the system as it's written. It's nothing like unit testing. It's like running around in the system able to poke-prod things as you go. Particularly important is that it doesn't mean working in a console. Most REPL-based dev is done in the source code file itself, and you send code from the document to the REPL process. Code is written in a file as usual, and you utilize the REPL to massage the system as you want. Though it's Clojure-based, you might want to watch this talk: https://vimeo.com/223309989 https://vimeo.com/223309989
open-source-ux 7y ago
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.
- pjmlp 7y ago
  Even C is full of features if you compare C11 with K&R C, and C20 is already ongoing. And if we consider the amount of compiler specific C extensions, across all C implementations, it gets even bigger.
  - jart 7y ago
    http://www.lysator.liu.se/c/ANSI-C-grammar-y.html http://www.lysator.liu.se/c/ANSI-C-grammar-y.html ← 1980's C (429 lines) http://www.quut.com/c/ANSI-C-grammar-y-2011.html http://www.quut.com/c/ANSI-C-grammar-y-2011.html ← 2010's C (536 lines)
    - pjmlp 7y ago
      What is that supposed to say? A language grammar is only a tiny part of what makes a programming language. Compare ISO C pages and C compiler manuals instead.
AdeptusAquinas 7y ago
F# hits all his 'perfect language' points for me. It feels like a more concise, opinionated and beautiful refinement of C#.
- 6thaccount2 7y ago
  I really like F#, but it has a few major pain points that hinder adoption: The first is that once a user reads over the various functional things like let statements, record types, union types...etc, you still don't really know how to code in F# unless you already have a .NET and in particular C# background. Nearly all the documentation and books (I have 3 of them) assume you're a C# dev making the switch. This is similar to learning Clojure/Kotlin/Scala on the JVM without knowing any Java. Everytime I post this someone tells me that is untrue, so I give it another shot and an dissapointed. With Python, there are dozens of books written for beginners that show you the building blocks (lists, control flow, dictionaries, tuples, functions, classes, file IO...etc) and how to use the blocks to build useful programs. With F# you get three sentences in and then hear how this is just like this thing in C# that I also know nothing about. Microsoft also seems to not be very dedicated to providing F# tooling support. On the plus side, I've found the community to be super smart and helpful and the language itself is very beautiful from an aesthetics point of view to me somehow (just looking at a bunch of code ). In comparison to C#, there is sooo much less noise (); everywhere. Go is a pretty simple language that compiles to static binaries. F# ain't that as there is all the bloat and baggage of .NET. Even with .NET core, that is more confusion for me.
  - AdeptusAquinas 7y ago
    You are not wrong. In fact I would argue it would be very hard to learn F# without knowing C# even if resources did not assume you did, since one of F#'s major strengths is the ability to use the entire .NET ecosystem just like Clojure as you said, and the .NET ecosystem is written for C# semantics (usable from F# but generally with some slight syntax switching). On the tooling front, Microsoft include it as a prime language with C# and VB.NET in dotnet core, and ship F# tools with their latest IDEs, which I appreciate and is almost more than I would expect, since their flagship is C#. It would be nice if it was better, but that would require it to be a lot more popular which is fair enough. Static binaries are something that would be real nice. I've done it with F# using CoreRT, but its certainly not as simple as Go.
abvr 7y ago
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.
namelosw 7y ago
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.
- agumonkey 7y ago
  pirlelang: perfect idris rust lisp erlang
- networkimprov 7y ago
  Zig might become the perfect language, assuming OOP is not must-have :-) https://ziglang.org/ https://ziglang.org/
  - lazyjones 7y ago
    But it has pointless semicolons. No, thanks. ;-)
    - coldtea 7y ago
      I like "pointless semicolons" and other redundant info to help the parser (and make things more explicit)
    - Avamander 7y ago
      So what we want is a typed compile-able Python? :D
    - apta 7y ago
      golang puts semicolons behind the scenes anyway, resulting in bizarre behaviors like not being able to write braces that follow "if" or "for" on separate lines.
signa11 7y ago
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. - alan-j-perlis
- coldtea 7y ago
  Nobody says that in the post or in this thread though...
dis-sys 7y ago
Go never intended to be perfect, it made no claim to be perfect. When people still write long articles explaining why Go is not perfect, for me, it is pretty strong indication that Go is actually pretty close to be perfect.
- Dylan16807 7y ago
  You know people write long articles explaining why PHP is not perfect, right?
  - eternalban 7y ago
    "It's the economy, stupid", said a former US President. It's the economic attributes of a language that contribute to its market share. Go is a very good language from an economic point of view. (Java was also a remarkably good language, from an economic point of view.) As to the your specific point, I suggest a sufficiently large slice of software workers will include the sub-set that write long articles defending their theoretically so-so but economically superior languages: Those blog posts are a feature, not a bug, of economically viable programming languages. The bottom line is no one has proven that "the bottom line" is positively affected by use of sophisticated languages. The killer app of ho-hum languages is their demonstrated economic value.
    - Dylan16807 7y ago
      PHP has a couple attributes that make it easy to start using and deploy, and a massive pile of network effects. Those attributes have nothing to do with why it's a garbage fire, and 'sophistication' also has nothing to do with it. You could redo PHP to be equally sophisticated, and still have the things that make it popular, but also be a hundred times more consistent and less buggy. Heck, fixing refs and inconsistent syntax could make it less sophisticated. At least they've been fixing some of it...
alkonaut 7y ago
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.
- pdpi 7y ago
  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
  - klez 7y ago
    Not a datapoint by any means, but I think kotlin gained grounds mostly on Android, seeing the questions on stack overflow. When they ask about kotlin it's almost always in the context of Android, while Java questions seem to cover a wider range of fields and platforms. So, could it be more of a reaction to java-for-android being sub-optimal or the fact that Google suggests kotlin to new developers than Java itself being sub-optimal for the task?
  - pjmlp 7y ago
    I think Kotlin's future is tied to Android's. Outside Android there are better options. On the JVM, just like any other platform, is safer to bet on the systems language of the platform than guest languages with extra debugging layers, tooling and their own wrappers for idiomatic code. Then Kotlin is trying to stretch too much, meaning that any portable Kotlin code cannot depend on any platform or needs multiple implementations. Finally Kotlin/Native has special semantics for handling data structures, as it tries to be Swift like, so special care is needed when the code is supposed to be used from Kotlin/Native as well.
    - 7y ago
ypcx 7y ago
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). One such direction seems to be Carp (https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp), but I haven't tried it yet.
- amelius 7y ago
  > 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.
  - pjmlp 7y ago
    Modules are in C++20 and you can already play around with them.
  - treypitt 7y ago
    aren't header files quite useful for yourself and especially other devs as a quick summary? I've found myself wishing my IDE would automatically make a header file equivalent for my python code (VS Code actually does this, but gives a lot of other info that's extraneous in my opinion)
- otterley 7y ago
  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.
  - threeseed 7y ago
    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.
calebclark 7y ago
There will never be a perfect language until there is a perfect programmer.
Wowfunhappy 7y ago
I feel like a variation of these steps could describe a lot of software in general, across industries.
zidoo 7y ago
There is no such thing as perfect. Good is good enough. Go is good for a lot of things.
mijoharas 7y ago
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.
- asdvxgxasjab 7y ago
  Curious about your use cases for generics. I write a lot of Go and don't often find myself missing generics. I also used to write a good deal of C++ and didn't find myself often needing templates either.
  - thanatos_dem 7y ago
    How often do you find yourself writing or using `interface{}`? It’s littered all over the go code I’ve seen, including the standard library. `interface{}` is the equivalent to using `Object` in java land. It completely punts on any sort of type safety, relying on the developer to handle messy edge cases correctly. I think one of the only reasons that it hasn’t been as severe a problem in go as java is thanks to that explicit error checking that go makes developers do (and that gets so much hate online), forcing developers to consider the case that the type isn’t what they assume. But genetics provide a useful way to safely make those assumptions, and cut down on the boilerplate around them.
    - asdvxgxasjab 7y ago
      I use it all the time indirectly when using a map or working with JSON. I don't find it all that messy to work with. If you're talking about type assertions, I don't use them all that much but they do come up. It doesn't require much boilerplate or special handling. If the assertion fails I return an error like I do everywhere else.
    - majewsky 7y ago
slx26 7y ago
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.
- zinclozenge 7y ago
  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.
  - nathcd 7y ago
    In case you haven't heard of it, you should check out Pony (https://www.ponylang.io/ https://www.ponylang.io/). It's definitely got its own flair, but characteristically it's a lot like what you describe.
rb808 7y ago
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.
- Retric 7y ago
  Usually, people start building demo’s or other side projects at their main job using whatever new tech they want to pad to their resume. This is bad for the company and your coworkers, but for people jumping ship every 2-3 years leaving a mess has few downsides. A more ethical approach is to simply learn at work during downtime over browsing the web. It even looks like work, so few people complain.
  - geofft 7y ago
    Building demos to pad your resume is bad for the company, but building demos to achieve unmet business needs is good for the company, and usually there are plenty of those lying around.
    - 0x445442 7y ago
      What I've noticed is in a lot of big enterprise shops that are playing "Agile" there is a big gap in support/tooling software; that is, software that makes developers more productive by automating repetitive tasks. Since this type of software doesn't exist to management because it won't fit nicely onto a Jira board or it can't be bent to fit a specific OKR, it's the perfect type of software to explore other languages.
      - geofft 7y ago
        Yes! It's also software that matters very little if you can't get a good support story for it - it's not customer facing and there are no SLAs, so worst case, everyone's automation fails but they can still get their job done. If you want to build a CLI for handling code reviews or an automated bisection tool using OCaml on a Raspberry Pi or whatever, that's way more acceptable than building customer-facing software (either services or shipped software) using OCaml on a Raspberry Pi. Also, writing this type type of software makes you an actual 10x engineer (by making 10 other engineers more productive).
cygned 7y ago
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.
- hodgesrm 7y ago
  Simple things like gofmt have helped enormously. Leaving out exceptions and templates have made the code harder to write (for me at least) but easier to read. It's the code equivalent of "schema on write."
patientplatypus 7y ago
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...
- cpuguy83 7y ago
  The alternative approach here would be to gernerate code for things that need genetics rather than using empty interface. Of course as with all things there are trade-offs... as there will be if/when generics are introduced.

114 points by snazz 7y ago

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.

littlestymaar 7y ago
> Go has a well defined set of design goals (including simple and pragmatic) that it has achieved. If your look how much changes are proposed as part of the Go2 work, I'm not sure the Go developers agree with you.
- majewsky 7y ago
  Yet the concrete proposals keep getting shot down or reworked. If anything, this makes me more sure that the Go developers care about their core design goals. They are listening to community feedback, but they don't allow a vocal minority to bury the original vision.

themango 7y ago

There's never going to be a perfect language -- stick with what gets the work done for the situation at hand. Also make some popcorn and enjoy the Twitter flame wars while you're at it.

thegabez 7y ago

The perfect language is the one humans won't have to write.

analognoise 7y ago

This already exists, but it isn't trendy. 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.

pjmlp 7y ago
As much as I like Pascal, and I am a big fan since Turbo Pascal since version 4 for MS-DOS, using all of them until about Delphi 3, lack of some kind of automatic memory management is a killer for anyone that cares about code security. Delphi only supports it for COM and Objective-c/Swift interoperability, everything else is as manual as TP for MS-DOS, and I bet FP hasn't improved in that regard.
- ckok 7y ago
  RemObjects Oxygene does. All targets have a GC (boehm on win32,64, Linux and Darwin, .net and java have their own of course) or arc (cocoa).
  - pjmlp 7y ago
    Thanks for the heads up. However that isn't Free Pascal, which was the OP's point. Having said that, RemObjects Oxygene is probably an alternative then. :)
    - ckok 7y ago
      Yep. It is Pascal though. That's why I mentioned it
- _ph_ 7y ago
  Ah, a young lad :) I started tinkering with Turbo Pascal 3 and even have some experience with Pascal on the Apple II. (Not because I am THAT old, but that were the only computers my school had at the end of the 80ies) The successors of Pascal are also highly interesting. I used Modula-2 quite a lot, but never got deep into Oberon. I do think one big advantage of Go is, that it so strongly draws on the Wirth languages that it almost can be considered a modern successor. And I fully agree, one shouldn't use a language these days for general programming without some kind of automatic memory management. Which is the other aspect which drew me towards Go, a nice nativley compiled language with a GC.
  - 7y ago

pjmlp 7y ago

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.

degraafc 7y ago

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. [1]: https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/ https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-releas...

shmerl 7y ago

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.

chewxy 7y ago
> Language can't be small, if it's universal enough t, u := x | λx.t | (t u) Small language (three production rules), definitely universal. Of course the semantics is a lot more complicated than most people expect. But it IS syntactically very simple
- shmerl 7y ago
  Theoretical cases that are unusable in practice aren't interesting in the above context. We are talking about practical languages. It's not about Turing completeness.
  - chewxy 7y ago
    s := a | (s s) common lisp syntax. Even simpler, but that shifts much of abstraction capabilities to the operational semantics.
Someone 7y ago
I agree that every language has its trade-offs, but you can move lots of stuff into the standard library of the language. Taken to the extreme, the result can be an extremely small language. If your language is expressive enough, the result can also look like it is a much larger language. For example, Forths implement if/else, for/do, while/do, repeat/until, switch/case in terms of some stack manipulation and ‘jump’. Similarly, Common Lisp builds its control structures, object oriented programming support, etc, out of a few primitives.

tus88 7y ago

Go isn't even close. It has an interesting runtime though.

holografix 7y ago

I think Go could be fundamentally improved if it somehow offered a REPL.

random42 7y ago
Checkout https://github.com/containous/yaegi https://github.com/containous/yaegi . Don't think its very mature though.
H8crilA 7y ago
So you're at step 3?
- Dylan16807 7y ago
  From the article? Not at all. It doesn't matter if it's easy or difficult, because it only needs to be coded once. And it's not a request to change the language at all, just the tooling.
  - marcus_holmes 7y ago
    I don't really understand how a REPL would help with coding Go. I think I use tests to do what I think people use REPLs for, and I don't get why I'd change that to a REPL if I could - having those tests permanent is a good thing. What would a REPL bring to the party?
    - casion 7y ago
      A REPL allows you to work in real-time with the system as it's written. It's nothing like unit testing. It's like running around in the system able to poke-prod things as you go. Particularly important is that it doesn't mean working in a console. Most REPL-based dev is done in the source code file itself, and you send code from the document to the REPL process. Code is written in a file as usual, and you utilize the REPL to massage the system as you want. Though it's Clojure-based, you might want to watch this talk: https://vimeo.com/223309989 https://vimeo.com/223309989

open-source-ux 7y ago

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.

pjmlp 7y ago
Even C is full of features if you compare C11 with K&R C, and C20 is already ongoing. And if we consider the amount of compiler specific C extensions, across all C implementations, it gets even bigger.
- jart 7y ago
  http://www.lysator.liu.se/c/ANSI-C-grammar-y.html http://www.lysator.liu.se/c/ANSI-C-grammar-y.html ← 1980's C (429 lines) http://www.quut.com/c/ANSI-C-grammar-y-2011.html http://www.quut.com/c/ANSI-C-grammar-y-2011.html ← 2010's C (536 lines)
  - pjmlp 7y ago
    What is that supposed to say? A language grammar is only a tiny part of what makes a programming language. Compare ISO C pages and C compiler manuals instead.

AdeptusAquinas 7y ago

F# hits all his 'perfect language' points for me. It feels like a more concise, opinionated and beautiful refinement of C#.

6thaccount2 7y ago
I really like F#, but it has a few major pain points that hinder adoption: The first is that once a user reads over the various functional things like let statements, record types, union types...etc, you still don't really know how to code in F# unless you already have a .NET and in particular C# background. Nearly all the documentation and books (I have 3 of them) assume you're a C# dev making the switch. This is similar to learning Clojure/Kotlin/Scala on the JVM without knowing any Java. Everytime I post this someone tells me that is untrue, so I give it another shot and an dissapointed. With Python, there are dozens of books written for beginners that show you the building blocks (lists, control flow, dictionaries, tuples, functions, classes, file IO...etc) and how to use the blocks to build useful programs. With F# you get three sentences in and then hear how this is just like this thing in C# that I also know nothing about. Microsoft also seems to not be very dedicated to providing F# tooling support. On the plus side, I've found the community to be super smart and helpful and the language itself is very beautiful from an aesthetics point of view to me somehow (just looking at a bunch of code ). In comparison to C#, there is sooo much less noise (); everywhere. Go is a pretty simple language that compiles to static binaries. F# ain't that as there is all the bloat and baggage of .NET. Even with .NET core, that is more confusion for me.
- AdeptusAquinas 7y ago
  You are not wrong. In fact I would argue it would be very hard to learn F# without knowing C# even if resources did not assume you did, since one of F#'s major strengths is the ability to use the entire .NET ecosystem just like Clojure as you said, and the .NET ecosystem is written for C# semantics (usable from F# but generally with some slight syntax switching). On the tooling front, Microsoft include it as a prime language with C# and VB.NET in dotnet core, and ship F# tools with their latest IDEs, which I appreciate and is almost more than I would expect, since their flagship is C#. It would be nice if it was better, but that would require it to be a lot more popular which is fair enough. Static binaries are something that would be real nice. I've done it with F# using CoreRT, but its certainly not as simple as Go.

abvr 7y ago

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.

namelosw 7y ago

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.

agumonkey 7y ago
pirlelang: perfect idris rust lisp erlang
networkimprov 7y ago
Zig might become the perfect language, assuming OOP is not must-have :-) https://ziglang.org/ https://ziglang.org/
- lazyjones 7y ago
  But it has pointless semicolons. No, thanks. ;-)
  - coldtea 7y ago
    I like "pointless semicolons" and other redundant info to help the parser (and make things more explicit)
  - Avamander 7y ago
    So what we want is a typed compile-able Python? :D
  - apta 7y ago
    golang puts semicolons behind the scenes anyway, resulting in bizarre behaviors like not being able to write braces that follow "if" or "for" on separate lines.

signa11 7y ago

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. - alan-j-perlis

coldtea 7y ago
Nobody says that in the post or in this thread though...

dis-sys 7y ago

Go never intended to be perfect, it made no claim to be perfect. When people still write long articles explaining why Go is not perfect, for me, it is pretty strong indication that Go is actually pretty close to be perfect.

Dylan16807 7y ago
You know people write long articles explaining why PHP is not perfect, right?
- eternalban 7y ago
  "It's the economy, stupid", said a former US President. It's the economic attributes of a language that contribute to its market share. Go is a very good language from an economic point of view. (Java was also a remarkably good language, from an economic point of view.) As to the your specific point, I suggest a sufficiently large slice of software workers will include the sub-set that write long articles defending their theoretically so-so but economically superior languages: Those blog posts are a feature, not a bug, of economically viable programming languages. The bottom line is no one has proven that "the bottom line" is positively affected by use of sophisticated languages. The killer app of ho-hum languages is their demonstrated economic value.
  - Dylan16807 7y ago
    PHP has a couple attributes that make it easy to start using and deploy, and a massive pile of network effects. Those attributes have nothing to do with why it's a garbage fire, and 'sophistication' also has nothing to do with it. You could redo PHP to be equally sophisticated, and still have the things that make it popular, but also be a hundred times more consistent and less buggy. Heck, fixing refs and inconsistent syntax could make it less sophisticated. At least they've been fixing some of it...

alkonaut 7y ago

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.

pdpi 7y ago
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
- klez 7y ago
  Not a datapoint by any means, but I think kotlin gained grounds mostly on Android, seeing the questions on stack overflow. When they ask about kotlin it's almost always in the context of Android, while Java questions seem to cover a wider range of fields and platforms. So, could it be more of a reaction to java-for-android being sub-optimal or the fact that Google suggests kotlin to new developers than Java itself being sub-optimal for the task?
- pjmlp 7y ago
  I think Kotlin's future is tied to Android's. Outside Android there are better options. On the JVM, just like any other platform, is safer to bet on the systems language of the platform than guest languages with extra debugging layers, tooling and their own wrappers for idiomatic code. Then Kotlin is trying to stretch too much, meaning that any portable Kotlin code cannot depend on any platform or needs multiple implementations. Finally Kotlin/Native has special semantics for handling data structures, as it tries to be Swift like, so special care is needed when the code is supposed to be used from Kotlin/Native as well.
  - 7y ago

ypcx 7y ago

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). One such direction seems to be Carp (https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp), but I haven't tried it yet.

amelius 7y ago
> 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.
- pjmlp 7y ago
  Modules are in C++20 and you can already play around with them.
- treypitt 7y ago
  aren't header files quite useful for yourself and especially other devs as a quick summary? I've found myself wishing my IDE would automatically make a header file equivalent for my python code (VS Code actually does this, but gives a lot of other info that's extraneous in my opinion)
otterley 7y ago
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.
- threeseed 7y ago
  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.

calebclark 7y ago

There will never be a perfect language until there is a perfect programmer.

Wowfunhappy 7y ago

I feel like a variation of these steps could describe a lot of software in general, across industries.

zidoo 7y ago

There is no such thing as perfect. Good is good enough. Go is good for a lot of things.

mijoharas 7y ago

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.

asdvxgxasjab 7y ago
Curious about your use cases for generics. I write a lot of Go and don't often find myself missing generics. I also used to write a good deal of C++ and didn't find myself often needing templates either.
- thanatos_dem 7y ago
  How often do you find yourself writing or using `interface{}`? It’s littered all over the go code I’ve seen, including the standard library. `interface{}` is the equivalent to using `Object` in java land. It completely punts on any sort of type safety, relying on the developer to handle messy edge cases correctly. I think one of the only reasons that it hasn’t been as severe a problem in go as java is thanks to that explicit error checking that go makes developers do (and that gets so much hate online), forcing developers to consider the case that the type isn’t what they assume. But genetics provide a useful way to safely make those assumptions, and cut down on the boilerplate around them.
  - asdvxgxasjab 7y ago
    I use it all the time indirectly when using a map or working with JSON. I don't find it all that messy to work with. If you're talking about type assertions, I don't use them all that much but they do come up. It doesn't require much boilerplate or special handling. If the assertion fails I return an error like I do everywhere else.
  - majewsky 7y ago

slx26 7y ago

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.

zinclozenge 7y ago
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.
- nathcd 7y ago
  In case you haven't heard of it, you should check out Pony (https://www.ponylang.io/ https://www.ponylang.io/). It's definitely got its own flair, but characteristically it's a lot like what you describe.

rb808 7y ago

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.

Retric 7y ago
Usually, people start building demo’s or other side projects at their main job using whatever new tech they want to pad to their resume. This is bad for the company and your coworkers, but for people jumping ship every 2-3 years leaving a mess has few downsides. A more ethical approach is to simply learn at work during downtime over browsing the web. It even looks like work, so few people complain.
- geofft 7y ago
  Building demos to pad your resume is bad for the company, but building demos to achieve unmet business needs is good for the company, and usually there are plenty of those lying around.
  - 0x445442 7y ago
    What I've noticed is in a lot of big enterprise shops that are playing "Agile" there is a big gap in support/tooling software; that is, software that makes developers more productive by automating repetitive tasks. Since this type of software doesn't exist to management because it won't fit nicely onto a Jira board or it can't be bent to fit a specific OKR, it's the perfect type of software to explore other languages.
    - geofft 7y ago
      Yes! It's also software that matters very little if you can't get a good support story for it - it's not customer facing and there are no SLAs, so worst case, everyone's automation fails but they can still get their job done. If you want to build a CLI for handling code reviews or an automated bisection tool using OCaml on a Raspberry Pi or whatever, that's way more acceptable than building customer-facing software (either services or shipped software) using OCaml on a Raspberry Pi. Also, writing this type type of software makes you an actual 10x engineer (by making 10 other engineers more productive).

cygned 7y ago

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.

hodgesrm 7y ago
Simple things like gofmt have helped enormously. Leaving out exceptions and templates have made the code harder to write (for me at least) but easier to read. It's the code equivalent of "schema on write."

patientplatypus 7y ago

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

cpuguy83 7y ago
The alternative approach here would be to gernerate code for things that need genetics rather than using empty interface. Of course as with all things there are trade-offs... as there will be if/when generics are introduced.