Hacker News Reader

Comment by klodolph | Hacker News Reader

Everyone I know who uses Go complains about it. Every day you write Go code you will come across some piece of code that would be shorter with templates in C++ or using <algorithm>, or you could do it more simply in Python, or if you were really clever it would be a single line of Haskell.

And yet we keep writing Go.

By comparison, I'm a bit put off by the Rust community's evangelism, but that might just be my personal experiences with Rust community members.

View on HN

A slightly different perspective. For the end user Go apps are by far the easiest to setup and use. Usually it's just a single binary to download. That is a huge advantage that can't be beat.

Other languages usually need a large number of dependencies, with Ruby and Node, often an entire build environment, with plenty of potential for dependency hell and hours wasted.

Some may advocate containers at this point, but it just hides the issue temporarily and may be too much for a certain category of end users. You now need to know how containers, ports, volumes and Linux systems work in far more detail when you actually just want to use an app.

All compiled languages support static linking, nothing special about Go.

At least historically speaking, this wasn’t true. And the fact that it’s true today for Java and C# is an anomaly, since for most of the history of those languages native compilation was either third party, second-class with missing features, or both. Look at GCJ or Excelsior (commercial).

Or look at Python, which is also compiled. Or Ruby, or JavaScript, TypeScript, Dart…

Language and implementation is not the same thing.

Does not matter where the implementation comes from, if it is free or commercial, what matters is that it exists.

With say a java app thou you'd typically get a .zip with all your class path dependencies and a launcher in one bundle. This is not the case for ruby, js (node), python etc where the norm is to splatter dependencies across your file system. Its not quite static linking but closer

This is not always true. Static linking with other language doesn't always have similar experience with Go. One of these is the compilation speed. With other languages you'll still have time to get a coffee break before its done.:)

Which other languages?

Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go.

There are lots of languages with modules support, with static linking and native compilation to choose from.

:D You're comparing turbo pascal with Go today? You're gonna write microservices and web applications with Turbo Pascal?

Ever heard of FreePascal and Delphi?

In any case it doesn't change the fact that Go's compilation speed is nothing to brag about, it has been done before in many other languages, Turbo Pascal was just one example.

If you wish I can provide other examples of languages that compile as fast, on such old hardware while matching Go's compilation speed, with richer language features.

Yes, I heard about these FreePascal and Delphi but I have no prior experience with them.

Well, personally I wouldn't, but generally, why not?

>Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go.

What relevance does this have on the compiler landscape today ?

If you have to use a compiler from ~30 years ago to find a comparison supporting your claim, it sounds very much like Go is indeed much faster than what it competes against today.

The relevance is that a compiler running in 90's hardware is able to beat Go's compilation speeds of 2017. That same compiler has evolved through the years.

If you want the 2017 version of it, it is called Delphi. Beats Go in language features and compilation speed.

Go's compilation speed only surprises those developers that never used anything else beyond C and C++.

>The relevance is that a compiler running in 90's hardware is able to beat Go's compilation speeds of 2017

And beat 99% of other compilers today, meaning that overall compiler complexity has grown.

>If you want the 2017 version of it, it is called Delphi.

Ok, this is something actually relevant.

>Go's compilation speed only surprises those developers that never used anything else beyond C and C++.

For me (tm), Go compilation speed has compared equal or favorably against C, C++, Java, C#, Rust at least.

> And beat 99% of other compilers today, meaning that overall compiler complexity has grown.

Which ones?

> For me (tm), Go compilation speed has compared equal or favorably against C, C++, Java, C#, Rust at least.

Since when does Go compile faster than Java and C#?

When I hit Ctrl+S my binary is already on the disk, thanks to incremental compiler integration on the IDE.

I have a full blown WPF application with multiple plugins, including data visualization, talking to Oracle and Postgres, total compilation time after check out 12s.

Eiffel, D, Nim, Jai are other fast compilation examples.

Aren’t JVM language equally simple? Just a fat JAR.

You're forgetting Java.

Java isn’t required for the JVM of course. Scala is pretty great. I’ll throw my hat in the ring for C# on .NET Core. Just need the dotnet binary to init, build, install, restore, run. It’s like if node included npm in the same binary.

But nowadays it's pretty much installed everywhere? If not installed yet - it's a really easy and quite unobtrusive to install, one-liners in many OSes. So in the strict practical sense, is that such a big difference? What, extra 300MB for storing JVM? Who cares with 2TB commodity harddrives? (unless you're embedded, but then you wouldn't use Java or Go usually).

The JVM adds 64 MiB if compressed, for comparison, node.JS with CEF adds 280 MiB

Only if we are speaking about versions older than Java 9.

Java 9 added linking support for custom runtimes.

As far as I know this is only true for code written in Go. As soon as you try using C libraries you're going to have a non-trivial time statically linking everything. Isn't that the case?

No, only if by C you mean code compiled with gcc and linked against GNU libc.

There are other C compilers to choose from, with libc implementations that properly support static linking.

I use the quality of people's complaints in interviews all the time.

I like it when they have a complaint but can see why the trade-off was made.

I don't like it when they're obviously parroting HN group-think.

I really don't like it when they have no complaints at all, but are able to recite the marketing happy-talk verbatim.

Often people are in all of those categories, they use what I see as marketing speech to talk about their own experiences. Those experiences might differ from mine so what I dismiss as parroting or marketing is later shown just to be difference in opinion.

I admire people who can spot such things effectively and steer discussions in an productive manner. I see now that this is not really about interviews anymore but just everyday discussions.

Everyone who uses any tool sufficiently frequently will complain about it. This is not a good proxy for quality.

It's so prevalent our industry has a term for it. "Use it in anger". You know you've gotten to know a language when you have had to work around a quirk of it's semantics.

Go has many flaws (lack of generics is my biggest gripe) but I still manage to be productive in it and it's fun to write.

I think for many people, me included, it's flawed but good enough for the job and fun.

You're attempting to slaughter all the sacred cows of this community. I predict that will end badly

I'll give you my point of view then: I'm super happy with Go and way less happy when I have to read C++ with templates.

> And yet we keep writing Go.

Remember that Go is still a niche language, and the majority of programmers will never write a single line of Go.

There is a nice trend around Go nowadays, but most people are still writing PHP, Python or Java and Go isn't going to replace any of those.

One could equally remember that Java was a niche language in 2000 used by a few dot-com startups, and even today it has not replaced C++, COBOL, or Fortran.

Languages don’t get replaced, people just don’t use them as often for new projects.

> One could equally remember that Java was a niche language in 2000 used by a few dot-com startups, and even today it has not replaced C++, COBOL, or Fortran.

Ouch, the lack of historical accuracy of your comment is painful. Just a few points :

- Sun Microsystem was founded in 1982, it's far from being a dot-com start-up.

- Java was already ubiquitous by 2000, it was embedded in your phones, your credit cards, in your browsers thanks to applets etc.

- in fact it did replace COBOL or C++ for a wide number of applications, not everywhere but it still had a enormous impact on the industry. Netscape even went as far as re-implementing their whole browser in Java[1]. It was a bad idea, but that gives you an idea of the revolutionary impact Java had.

Go is nowhere near where Java was in 2000, by several orders of magnitude. It's not a criticism of Go, I don't even think we'll ever have a language as popular as Java in that time, because in the 90s there was a massive window of opportunity for a language that was at the same time : safe, portable, and licence-free.

[1]: https://www.cnet.com/news/netscape-sharpens-javagator-plans/

Well the size of industry was much smaller than it is today. Java kind of replaced or used in first place where people would have used C/C++ etc. Same is true for Go as lot of container/devops, cloud etc infrastructure is written in Go which would most likely be in Java.

Among the languages that came in last 10 years Go is most popular with exception of maybe Swift.

So compare to marketing juggernaut Java with billions sunk in by leading enterprise vendors Go is nowhere. But among non corporate driven language Go is definitely on top.

> Among the languages that came in last 10 years Go is most popular with exception of maybe Swift.

Go is indeed one of the most popular of the last 10 years, but I don't think it's the most popular one. Swift is way ahead (because of the iOS walled garden), and Typescript is probably more popular than Go (or at least in the same ballpark).

> But among non corporate driven language Go is definitely on top.

Go, «non corporate driven», really ? OK it's not «corporate-driven» like Java, but I don't think anyone would be using Go if Google wasn't behind it. I really think the impact of marketing in Go's success is bigger than its value-proposition (I'm not saying that Go doesn't have a value-proposition, I'm just arguing that marketing played a really big role in its adoption). Consider for instance the microscopic mindshare that Pony[1] has, despite being «Go from the 21th century» with a sound type system and a data-race-free concurrency model.

[1] https://www.ponylang.org/

Marketing aside, people evaluate languages for their community. The lack of a community is something that can be fixed by marketing, but marketing isn't necessary to create it.

Pony is also pre-1.0, and it doesn't look much like Go to me.

Ouch, I should have explained that I was being sarcastic. Javagator was canceled in July 1998, so by 2000 it was thoroughly dead. Sun using Java no more makes it a major language than Google using Go does.

What I remember from the time was that C and C++ was everywhere, and Java was this weird new thing with a bunch of promises that ran slowly (because the JIT wasn't standard until later). There were a lot of people who were dismissive of Java, which was stupid, and there are a lot of people today who are dismissive of Go, which doesn't make sense to me either.

> And yet we keep writing Go.

What are the alternatives if you want something with type checking? Java? No, thanks. Haskel? Where are the libraries? C/C++?

I guess Typescript is the only alternative

Kotlin.

Have you gone to production with it yet for your backend? Curious Android dev here.

Worked on at least 2 projects using it in production (backend) zero language issues

Not yet, but zero issues so far. Currently running Spring Boot 2M7 on AWS EB just fine. I was surprised how smooth it went.

Correction: found an issue with bean validation.

https://github.com/spring-projects/spring-boot/issues/11343

And it turns out it wasn't really an issue, just unintuitive. Documentation has been updated.

We use it in production for a Storm-based ETL pipeline. We've not had any problems that have been related to our use of Kotlin.

PHP has object checking. This is why I started using value objects in PHP.

The VO's I use trow exceptions when you construct them with some bad value. This is great because when you use for example a natural positive integer object you are sure it is one.

So now I have 'type checking' and more secure code in PHP.

PHP also supports other type declarations. But using lots of value objects is a good idea anyway.

http://php.net/manual/en/functions.arguments.php#functions.a...

Since when does PHP has value types? Aren't all the classes reference types or you mean that Array thingie?

And it is still the case with type declarations, that they make your code actually slower, because the runtime adds asserts in your code which gets evaluated at runtime?

Runtime type checking while useful does not offer the same level of safety as compiler time. It will catch sinner classes of errors but you'll still have bugs lurking in production.

I’d really like a strongly typed (or optionally typed) Python or Perl derivative. Rust feels most Perl-like so far.

Modern PHP is very nice to work with. Ignore the haters that haven't touched the language in 10 years.

To be fair to the haters, even modern PHP can be horrible. The old nightmares are still around; we've just agreed to ignore them, and maybe deprecate a couple of the worst. (And ternary syntax is still broken, and the standard library is anything but standard.)

But yes, if you're working on a modern PHP project, there's a lot to love: A solid module system, an enormous sea of high quality libraries, type checking, a really nice deployment and scalability story, decent performance, good tooling (IDEs, debuggers, etc.), a servicable C-style syntax. For many purposes (not all!) it's ten times better than, eg, nodejs. (Which might seem like a low bar, I admit...)

Is it better than nodets?

nodets, as in typescript on node? I haven't personally tried it, but I imagine so, again depending on your particular use case.

I quite like Typescript as far as syntax goes, but I think PHP 7.1+ is comparable. And PHP has a lot more support, libraries, and better tooling in my view. For example, my experience in node land is there aren't really any good ORMs; PHP has multiple, including one (Doctrine) which is easily the equal in my view of the highly regarded Python SQLAlchemy. Similarly with routing, frameworks, templating, etc., there's a huge amount of maturity on the PHP side that's missing from node.

The big question is going to be in the process model. Node has an event loop; PHP doesn't. For most purposes, I think an event loop makes writing good code harder to no real benefit, but in some cases (eg, acting as the endpoint for a ton of open websockets) it can be a big win. If you do need that, then you should probably lean towards node over PHP, and sure, why not use typescript? But for the general case, I'd still lean towards PHP.

(Then again, there's also a ton of other languages and frameworks. Just because PHP - or node - might be better than the other for some task doesn't mean there aren't a dozen more languages better than both.)

In your view, if someone created an ORM for node which focused on creating object graphs for tables and fields (a-la sqlalchemy) instead of focusing on SQL building syntax (a-la knex) would it be popular?

Solid module system?

It's still the same as C, which is _not_ a solid module system.

I'm assuming he meant the dependency manager, which is really nice.

https://getcomposer.org/

Correct. :)

I wrote some PHP last month and I still hate it :)

Though it has improved dramatically.

Did you write clean OOP code? You can still write bad code with it, no doubt about that.

https://docs.python.org/3/library/typing.html

http://mypy-lang.org/

Why do you say that? I love both Perl and Rust, yet the latter doesn't feel very perlish to me.

Seems it’s optimized for developer enjoyment and is a big language that allows for terse expression, as well as a few ways to achieve the same thing.

Any measure by which Rust allows for “terse expression” has to be horribly broken. (And I don't even dislike Rust.)

Have you looked into Nim?

Maybe you should look at Crystal, a Ruby derivative.

https://nim-lang.org/

I've been eyeing up Pony (https://www.ponylang.org/) a lot lately. To my eye, it has a lovely syntax and a very useful mix of modern programming features. I'm particularly enamored of the types, safety, actor model, and absence of exceptions. From a distance, it looks like the best parts of Rust, Golang, and Python.

> Haskel? Where are the libraries?

Well, I suppose the same drawback would apply to Pony. :)

I've seen a lot of stuff on Pony as well and it looks promising. Have you built anything with it yet?

Not yet, but I'm looking forward to it; just need to find a good project.

What about Apple's language Swift?

Scala, or C# ?

There's Nim and D too, but I get the lack of big commercial backing could disqualify them.

Scala is a perfect example of how NOT to design languages.

Modern PHP is really nice to work with. I uploaded the sample code from my book on Github if you want to have a look (check inside the src directory).

https://github.com/PatrickLouys/professional-php-sample-code

C#. Its pragmatic and now cross platform, has got OOPS and the functional features you need.

I like C# as a language but everytime you use it a puppy dies (MS exists)

Java, C#, F#, C++, D, Rust, OCaml, Haskell, FreePascal, Ada, Swift, Nim look all pretty fine to me, and yes there are ways to compile Java and .NET languages to native code just like Go.

As for libraries, what matters is if the desired use case is covered, not winning the App Store count.

I like go for most things more than all of those, though F# would be promising if I felt better about .net stuff and Linux.

Kotlin, C#, Scala

Because Typescript (or Javascript) has more quality libraries than Haskell?

What is your problem with Java? What does "No thanks" mean? It's interesting to hear your perspective, but hard to know what you mean if you don't write it. (Also have you even looked at Scala, Kotlin, Groovy with static typing, and perhaps others?)

"Haskel? Where are the libraries?"

What libraries are missing? The only issue I've had with libraries are that some client libraries are wrappers over C libraries and this makes static linking difficult (or seemingly impossible on a Mac)

A few years ago there was a lack of libraries in some areas but that's not the case these days.

Can't help but think of: "The grass is greener on the other side of the fence."

Or "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

I write Go on the daily and I really enjoy it. But hey, whatever floats your boat!

Not me, I only touch it when the customer says so, and it is usually Docker related assignment.

Reply on news.ycombinator.com