Hacker News Reader

Comment by kgthegreat | Hacker News Reader

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering engines.

Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages."

View on HN

They forgot the mindshare of PHP users. The tradeoffs Go makes are rather similar (simplicity, ease of deployment vs expressivenes and consistency).

I saw a tweetstorm by a longtime Go user who listed all the flaws and inconsistencies of the language. In the end it didn't look much better than PHP to me. Which is surprising, since PHP is a "grown" language and go has been "designed" by some longtime languages pros.

A lot of complaints usually affect niche or rare use cases in the language (or you learn them fast).

Though I guess the same applies to PHP.

It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP)

Also the stricter type system compared to PHP is nice in addition to static linking making it more portable than PHP (minus not being portable to shared hosters)

Yes, I'm not a big fan of PHP either.

Guess the global state access and easier parallelization are the main selling points.

I wrote a few APIs with long running queues in PHP and Node.js and found it both a bit too clunky for that job.

I don't think there's anything inherent in the language that prevents PHP from running like Go (daemon that receives requests, rather than being launched by an external server on each request). It's just a matter of convention.

Comparing PHP with Go it's a bit too much, don't you think? Type system, standard library, concurrency, compilation, packing ... I hardly find similarities.

Some don't mind: https://news.ycombinator.com/item?id=13430612

I can't agree though. I believe using that rationale same could be said about C and many other languages...If that's the case then, should we expect a "fix" for the master programmers (i.e. Go++)? Let's hope that won't happen. Go is nothing like PHP. It was an attempt to modernise C though I believe it failed because Go can't do realtime.

C is far from perfection, but it's very small, fit well to the hardware of its day, and had a colossal "killer app", Unix.

A fix for master programmers is e.g. Rust, and a bunch of GC-based languages, from newcomers like Crystal and Nim to the battle-hardened JVM ecosystem, or Erlang/Elixir.

The way C++ did not displace C, or the way Ruby and Python did not displace PHP, these guys will not displace Go.

>and go has been "designed" by some longtime languages pros.

Longtime systems and UNIX pros, not language/compiler pros though. That would be someone like Anders Hejlsberg or Lars Bak respectively.

Is that why Dart got so popular compared to Go? What about C?

>Is that why Dart got so popular compared to Go?

No, that was because the focus of Dart (replacing JS on web browsers) wasn't feasible, and even Google dropped it. Which says nothing about the quality of the language (which was selected for the Flutter SDK anyway).

Besides, popularity in tech, as in high school, doesn't say much. Engineering shouldn't be a pop culture.

>What about C?

What about C? That was made by Dennis Ritchie, not involved in Golang. And even so, it's not the best basis for a 2007-2017 language.

I think the bottom line for a language is to be successful not whether or not the founder has whatever acreditation someone worships. I believe C has been pretty successful thus the reason why I was asking you about it...was Dennis Richie a compiler designer or a unix developer? Dart seems to be used pretty much only by Google with few exceptions. I'm not saying it's a bad language but it's just not successful. I believe popularity is important because a death language doesn't solve problems. Engineering is about solving problems anyway not about developing the most complex/expressive language.

As far as Go design is concerned I believe that someone who designed few programming languages can be called a "pro" even if he doesn't agree with the mainstream opinion about what makes a good design. Simplicity is underestimated.

Though one thing that Go has which PHP doesn't is the rapidly braking changes (PHP3 and 7 have totally different idioms since early PHP decisions proved to be horribly insecure (register_globals))

A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?

How would you handle plugins? Some kind of cheap local RPC would probably be fine from both the complexity and the performance POVs.

You can write modules that you select at compile time, like Caddy does: https://github.com/mholt/caddy/wiki/Extending-Caddy

Perhaps this: https://gohugo.io/

There are bunch of comparisons Hugo vs Wordpress on internet.

Imagine a one-step converter: "put your WP configs here, take your [Go-based] new site there, just 3x faster", or something.

Good static site generators are many. The point of a product might be near-zero transition friction.

This actually makes a lot of sense. From the outside, it's hard to see why anyone uses Go. Using Go feels like going back in time 20+ years.

However if someone is coming from PHP, Go must look positively modern. Considering the millions of PHP programmers out there, Go can keep on growing for a long time.

Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome standard lib.

Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.

Concurrency primitives maybe (though languages had those for 20 years too).

But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?

Static linking: no more futzing around with package nightmares on systems. Making sure system packages are present so python virtualenv can install. Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years.

Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example.

Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity.

1. https://golang.org/doc/faq#What_compiler_technology_is_used_...

> Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years.

Because they are invented at a time before storage and RAM is dirt cheap and lightning fast. It was painfully wasteful and slow to load a copy of the standard library for every process. Dynamic linking was invented basically because static linking wasn’t feasible.

For me, coming from Java it was a breath of fresh air simply because of the simple build setup. (Modern) Java requires gradle (which is a magical setup, written in a language totally dead outside of gradle scripts), special magic for a "fat jar", and even then it doesn't create a exe/elf at the end. And the build is fast - even on a raspberry pi.

Oh, and the IDE environment is amazing - you literally don't need much more than VSCode or vim (the language tools have built in refactoring support, formating, quick compile for syntax error, godoc).

And you have closures, something Java didn't have until 8, and even now many libraries don't support it.

One of the reasons for the confusion from those of us on system programming side is that Go inherited mostly from Oberon...

https://blog.learngoprogramming.com/about-go-language-an-ove...

...that was used to build OS's and other system stuff. Here's a brief history I just submitted and the official pages.

https://news.ycombinator.com/item?id=15704806

http://www.ethoberon.ethz.ch/

http://www.projectoberon.com/

The Delphi product and the Oberon offshoot Component Pascal were used as C++ replacements. Here's an IDE for Component Pascal:

http://blackboxframework.org/index.php?cID=home,en-us

So, the point is that it's a variant of a Wirth-style language for writing operating systems and low-level apps. With that, many of us figured it can also target the same thing. It might need some modification in its runtime or something if not originally aimed at it. I see no reason why a language stronger than Oberon couldn't be used for at least what Oberon was used for, though. As partial evidence, people are already writing prototypes for OS's in in.

https://news.ycombinator.com/item?id=14537691

https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item

Throw in real-time or selective GC's as a modification to get it closer to taking over a lot of stuff that C would be doing. There's also nothing stopping the low-level code from being straight-up unsafe with checks added by programmer since that's already the baseline with C. One would get a more pleasant language that was at least memory-safe in other components that could take a GC. House OS is an example where the H Layer wraps the unsafe, lowest-level parts of the kernel of an OS mostly written in type-safe Haskell.

I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python. If that's right, it might be fair to say Rust and Go were "originally" competitors, even if they aren't as much anymore :)

>I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python.

Yes, I think that was in an article by Rob Pike, might have been his article titled "Less is exponentially more."

Edit: Found that article:

https://commandcenter.blogspot.in/2012/06/less-is-exponentia...

Excerpt: [ I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. ]

Ha ha, my edit and your reply (which you later deleted) crossed in time, due to my messing up my original post a bit w/copy+paste :) Sorry for the confusion. Anyway, point made clear. I found Rob's statement surprising too. But also, I heard from Josh Fraser, founder of Torbit (acquired in a relatively short while after being founded), that they decided to use Go because it has a good balance between the performance of C and the productivity of dynamic languages like Python and Ruby.

I mean hell, Rust even had a GC and Green Threads at one point.

As a C/C++ developer that doesn't surprise me at all. I looked at both Go and Rust and I'd go with Rust if given a choice between the two.

It might be that they underestimated how desperately people had already moved away from C/C++ if they had any choice at all :)

Curious, what are the "high deployment costs of JVM based languages"? Don't must standard workloads simply deploy a jar?

Likely they mean high RAM consumption?

I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.

To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.

Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8.

They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.

I suppose that "high-deployment costs" also includes JVM/application startup and warmup.

Most likely some old myth regarding the JVM.

Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer.

I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.

The unbelievable irony I'm observing with the Java-based things I need to deploy these days (Jenkins and Gerrit related) are that quite often they're making me build something, which then fails due to weird maven issues I don't understand (since I haven't been a Java dev since the ant days).

The entire point of java was that bytecode is portable, it's "write once, run anywhere". Don't make me build your stupid .jar and figure out all your dependency / build-time issues, just give it to me!

I don't think Jenkins is a good indication of modern Java :) If anything Jenkins is a hairy ball of mud you should try to avoid :p

I write exclusively Clojure on the JVM now; its like having all the advantages of the JVM and none of the inconvenients of Java!

Without using containers or fragile (and not very portable) executable wrappers you need to manage the JRE, JAR files and the right classpath.

With go you can just run 'go build' and get static executables for all common platforms with zero dependencies.

The key difference between that and just throwing jar files on random systems is that static executables truly work anywhere and will never crash because you don't have the right version of JDK and usually won't need messing up with arcane command line parameters or .properties files.

Deployment is one area where Go truly shines and I guess that helped its popularity. PHP also got immensely popular due to ease of deployment, although of a different kind, in a different era and with different expectations.

I am not sure if many programmers are "prepared to accept more complex syntax" (etc.) than those of C++...

Thankfully that wasn’t implied at all, and it’s not true that rust has more complex semantics (or, I think, syntax, although I could be wrong on that).

That said, it certainly is more complicated refactoring arbitrary data flows. There is certainly a cost for all the benefits! :)

I think the author is saying "more complex" relative to higher level languages like Go. They mean to put Rust in the same category as C++. It could be rephrased as "prepared to accept languages like C++, D, and Rust with more complex syntax"

Reply on news.ycombinator.com