Live data from Hacker News

The perfect language and why Go still isn't it

snazz.xyz

51–60 of 139 posts

Re: The perfect language and why Go still isn't it

#51

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

Sure, Go didn't turn out to be well suited for distributed systems either. But neither are JVM languages.

Re: The perfect language and why Go still isn't it

#52

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…

I'm a big fan of the Wirthian language family, and while I think FP is eminently usable, I still think Modula-3 would be a better fit for Gophers. A M3 frontend for FPC would be a great combination...

Re: The perfect language and why Go still isn't it

#53
post #17
post #16

Earlier quoted context omitted.

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

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

Yep. It is Pascal though. That's why I mentioned it

Re: The perfect language and why Go still isn't it

#54

Earlier quoted context omitted.

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 si…

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…

Maybe I've been looking at it wrong. Those books don't exist as you have to go through C# first unless you're just gifted maybe.

I've thought OCaml might be a good F# replacement as it has its own compiler and interpreter that doesn't need the CLR/JVM and F# was mostly based off of OCaml, but it's a little awkward to me on Windows and OCaml itself seems to be a little painful (more boilerplate than expected) for doing things like IO (which I do a lot of).

Re: The perfect language and why Go still isn't it

#55

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 lik…

Zig might become the perfect language, assuming OOP is not must-have :-) https://ziglang.org/

But it has pointless semicolons. No, thanks. ;-)

Re: The perfect language and why Go still isn't it

#56
post #28

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.

You know people write long articles explaining why PHP is not perfect, right?

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

Re: The perfect language and why Go still isn't it

#57
post #13

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…

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.

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 ← 2010's C (536 lines)

Re: The perfect language and why Go still isn't it

#58
post #49
post #39

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…

> 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 i…

Modern Go solved the problem of control over native threads threads. But it is puzzling indeed that it took almost 10 years despite popularity with containers.

Re: The perfect language and why Go still isn't it

#59
post #39

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…

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

Re: The perfect language and why Go still isn't it

#60

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

> And is etcd significantly better than Zookeeper ? Not really. So not a great example for Go's supremacy.

ZK is using Paxos and Etcd is using Raft. It's difficult to compare languages in this case as you will compare consensus algorithms mostly.

> Also with GraalVM you can equally support low memory, fast startup use cases.

How is GraalVM performance this days? Last time I've checked[1] it was a lot slower than JIT.

1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Post reply on HN