Hacker News Reader

Comment by armitron | Hacker News Reader

Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project? (as if we didn't have enough of that already). The only niche I see for it is for those poor souls who are still wasting their time with Python/Ruby but that by itself surely can't lead to great things for the language, especially since it's riding on air. More dense air than Python but air nonetheless.

Also Rob Pike. If there's a guy with the king midas touch of shit, it's Pike.

View on HN

> If there's a guy with the king midas touch of shit, it's Pike.

Such personal attacks are a bannable offense on Hacker News. Please don't ever post anything like this again.

Generic programming language flamewar comments are a kind of trolling and also not wanted here.

The value of Go is:

1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better)

If you want a reasonably fast statically compiled language, what would you use?

Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClojure? Too obscure.

Please keep in mind I may have completely misinterpreted your comment.

> Java? Lots of JEE/App server issues to consider

Why? Why not just package as an assembly, scp it up to a server, fire up Netty in a main-class and call it a day (this is basically all Play Framework does)?

It's going to be faster/simpler in every way than any Ruby/Nginx stack you can imagine. No need to fight with matching cores to processes per deployment, no unnecessary proxies or additional services to watch/manage.

Sure you can go crazy. Or maybe even need to for some use case, but even in that scenario you can bet your business on the fact that it'll still be a far simpler solution than the comparable dynamic stack.

Not that I'm advocating Java exactly. I just feel like if deployment/server-issues are an issue, compared to a dynamic stack with similar throughput, then you've done something horribly horribly nightmarishly wrong. ;-)

Sorry, I used to work at IBM and in my mind Java is WebSphere and a lot of suffering.

Certainly, there are other simple ways to use the Java stack with things like Play. DropWizard, etc.

But there is certainly a lot more complexity around tooling and deployments and such in the Java ecosystem than either Go or Node.js (although I can't say I'm a Java expert, so it could just be I'm just wrong).

I can totally understand that. Feels a bit unfair to paint an entire platform with the same brush if you haven't tried the more modern alternatives though.

This is a full HelloWorld web-server in Spray: http://scastie.org/14680

Play can get you to Hello World even easier:

  $ brew install typesafe-activator
  $ activator new my-first-app play-scala
  $ activator run

That's going from an off-the-shelf Mac with only homebrew installed to running your first Play app. To deploy it just run the `dist` task instead, and copy the generated .zip file to a server. Unzip it and run `./bin/my-first-app`. The only dependency you have on that system is Java.

Stick a load-balancer in front and you're good to go.

It's light-years beyond anything I've ever experienced on any other platform on the *nix side of things. Especially since it's also so much faster than any other platform I've worked with (decade old c# doesn't count).

With Spring Boot (not saying Spring is one of the "uncomplex" parts of the Java ecosystem) build and deployment goes like this: `gradle build`, `scp` the jar file to a server and then you can symlink it to `/etc/init.d/` and just use it as a service.

>If you want a reasonably fast statically compiled language, what would you use?

I'd go for rust.

Rust seems like a nice systems language, but is it really best suited for non-system programming? I may be too risk adverse, but it seems too early to make that bet at this point.

I'm learning Rust by writing a toy compiler, definitely a high-level task, and I'm finding that Rust is pretty good for that. Some highlights:

- Algebraic datatypes and pattern matching: extremely nice for compiler work where you need to manipulate symbol data.

- Result + try! macro: a bit more verbose than a language that can let an exception bubble up, but definitely nicer than the boiler-plate that people in Go must use.

- Module system: easy to expose only what you want.

- Cargo: one of the best, maybe the best, language package manager that I've used. Super easy to add dependencies to your project.

I will say this however: I'm moving more slowly than I would in a language like OCaml. I still haven't assimilated all of the borrow checker rules in my programming sub-conciousness, so I still make errors and it can take a little while to figure out what's happening and how best to address the problem.

Works fine for the web needs.

* C/C++ like familiar syntax. * as fast as C++ (faster in some, slower in others) * type inference (auto keyword) * Garbage collected language by default. * Multiple compiler implementation (DMD, GDC, LDC) * Debugging symbol support * Package management with versioning and pkg repo * IDE/Editor support - Visual studio/xamarin/emacs * Very easy C FFI * compile type function evaluation * meta programming * The concurrency story is more "mainstream" than Go's (no "goroutine" and other fancy stuff). * Multiple new books on the topic

D has a lot going for it, except for breathless fans :) (not knocking breathless fans here. D can use some)

> If you want a reasonably fast statically compiled language, what would you use?

Anything that is C ABI compatible. I'm sympathetic to Go's philosphy, but Go is not that.

In general, I'd be on the lookout for Swift on the server in the next few years. It has the backing of Apple, is compiled, and the possibility of removing yet-another-language from your stack. Since many shops want or need an iOS frontend, running Swift on the server makes sense.

> If you want a reasonably fast statically compiled language, what would you use?

Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent quality.

Nim doesn't have interfaces. The amount of plumbing required to implement them is ridiculous. It has generics though. My point is how can recent OO languages miss this kind of stuff when designing their type system ? Crystal looks like a better bet, unfortunately it doesn't run on Windows.

At risk of sounding like a Go advocate when generics come up, the lack of interfaces doesn't bother me because interfaces themselves are a bit of a hack. When you have inheritance, object variants, generics, and a strong template/macro system, what's left for interfaces to do? I'd much rather have all of these other things than interfaces alone.

The fact that you can create an online interface and an unrelated library (which you didn't write) can have structures that implement your interface automatically is pretty useful (and cool) IMHO.

Fair point, but much of that benefit is lost without decent support for those third-party implementations to be loaded dynamically. So Nim is missing one piece, but those other features I mentioned can get you very close to the same place. Go is missing the other piece, with no really good way to make up for it. That problem's not even solvable as long as Go's runtime makes no provision for interfacing to code that doesn't play by its own (ever-changing, undocumented) rules about things like goroutines and GC. I know which shortcoming I'd rather live with.

> Go's runtime makes no provision for interfacing to code that doesn't play by its own

This alone makes Go really unfit for developing system libraries.

There is very little chance I could sell a CEO on using Nim. The fact of the matter is that the community and ecosystem are parts of the entire platform and the platform matters a huge deal when you're betting your business on it. Accident or not.

Not disagreeing with you, but that only matters if you need to sell a CEO on your choice of language. Many of us don't, and every language had to cross that chasm somehow. Once upon a time, there were plenty of CEOs who didn't believe you should use Java for anything that mattered. Ditto for Javascript. Most relevantly, ditto for Go. If size of the existing community and ecosystem were the main criterion for choosing a language, Go would still be in the same bucket as Nim. Somebody has to use a language because of its own inherent strength before the CEOs can be convinced.

Agreed, I think timing with Go is a huge factor. Though I think the size and scope of Go's popularity is overstated. I looked into it for a recent web project and found many formerly popular libraries now unmaintained. I felt more confident and went with Django on Python 3.5.

If I want something compiled, the killer for Go for me has always been C ABI incompatibility. It's its own island. I'm not saying I wouldn't consider using Go for some things, but that has been a big redflag vs other choices.

Nim is fun but it's not even at version 1 and has a very small developer and user base.

"The only thing in Go's favor ..."

The selectivity of a true ideologue.

It's the Go fanatics who are the ideologues here. Anything Go has is important, anything it doesn't have is trivial. What a horrible attitude to bring into any kind of technical discussion.

I've defended Go against detractors who say it's worthless because it has mandatory GC or doesn't have generics (which I do consider a weakness but not a fatal one). There's nothing particularly wrong with Go, but there's not all that much special about it either and it does have flaws. Can you name some other feature that (a) distinguishes Go from Every Other Language and (b) matters? Something that might sway a CEO, as we were discussing? "Goroutines" perhaps? Riiight. That CEO will be really impressed. Don't project your bias onto others.

Great tooling? Does Go have any quality IDEs with integrated debuggers yet?

I feel that open source developers mean something entirely different with the phrase "great tooling" than developers used to Visual Studio would mean. :)

Absolutely! They do not mean big GUI based IDE when they say tooling. Infact this is why Go will remain unviable option to .net developers. Go is likely to be much more popular among dynamic languages users and even some Java developers who are tired of enterprisey bloat.

https://github.com/visualfc/liteide exists with, basically, many of the same things as you see people augment vim, etc. with (autocomplete, format on save, etc.) but a GUI editor. It has interactive debugging, but I don't use it so I dunno how it is. I can't promise you'll like it, but I dig it for some uses and it's there. The GUI itself seems to be maintained by one developer and as such it is unlikely to ever have full feature parity with Visual Studio. :)

> Infact this is why Go will remain unviable option to .net developers.

Why should we even bother with Go, if we have C#, F#, JIT, AOT compilation to dynamic binaries (NGEN), AOT compilation to static binaries (.NET Native), NuGET already available?

And yes, I do know Go and even tried some early contributions before the 1.0 release.

For me it is only a step forward for C developers.

Still a very important one, as we need more widespread use of safer compiled languages.

Does go even have any good command-line debuggers? All of the things I've seen either involve insanity like preprocessing your source to inject hooks in between each line of code, or don't actually work.

Delve is an open source debugger for go. And many editors can work with delve such as Visual Studio Code. There is an animated gif of the debugger on the vscode-go page. https://github.com/derekparker/delve https://github.com/Microsoft/vscode-go

Due the way Delve rewrites Go source code and relies on having it available, I wouldn't call it a debugger.

> Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project?

Ignoring your broadside of insults, I keep asking myself the same thing after working with it: What is so compelling about Go? It's better than C, but we already have good choices in that area. I feel like there's a bandwagon effect around the language.

Personally, it's replaced Python and Ruby for my web development. I like the compile-time typechecking and the ability to annotate structs and then use those annotations as direct rules for serializing data via XML / JSON serializers. The compile-time typechecking means I don't need 100% coverage to make sure I haven't typo'd a variable name somewhere.

But if you weren't using Python or Ruby for your web development, YMMV.

I see Go as having a nice niche for "systems" code that is above C, but more low level than say python. I think that is why we see it used in docker, kubernetes, etc. The ability to distribute binaries is quite handy for containers.

I am surprised that people want to use Go for web apps though.

For whatever reason, Dart seems unpopular with the HN crowd, which is shame because it is a super productive language. It has a fast VM, great tooling, a sane package management system, and a lot of deployment options. Server side libraries are still lacking, but the situation is improving.

> I am surprised that people want to use Go for web apps though.

This. I'd put it under consideration for where I'd pick Java (an increasingly limited space now for myself), but I really do not think it competes directly with Python/Ruby or C-ABI compatible compiled languages like Rust. It's on an island like Java. As a result, you're going all-in with Go, but netting a much smaller ecosystem than Java's. I prefer to not go all-in with either.

If I were to reach for Go for webapps, I'd be just as if not more inclined to look at Swift as it matures.

The language enforces simplicity (making it easy to read), the standard library is dope, and the runtime is fast/robust.

> Go as a completely unnecessary move-along-now-nothing-to-see-here project

I don't like Go type system, but it handles concurrency quite nicely. It's fairly easy to learn and to use so I can see why managers chose it. And it's backed by Google so it can give a sense of safety and it can be used as an argument to sell the language. So it's a bit unfair to say it's unnecessary. It can help when performance is a concern and one doesn't want to go down to C or C++ for some reasons.

Devil's advocate:

> but it handles concurrency quite nicely

So does Erlang/Elixir, Haskell, Clojure.

> And it's backed by Google so it can give a sense of safety

How is Dart doing in this department?

Dart is doing fine.

It has not replaced Javascript (that was never going to happen) but it has seen a slow but steady growth in adoption.

There are some amazing things happening with Dart on mobile (flutter.io), Dart on embedded (fletch), and improved JS interop with things like the Dart Dev Compiler (DDC).

Angular 2 is still in Beta, but has first class support for Dart.

Perhaps it did not live up to it's initial hype - but Dart is a pretty "safe" bet

What would you suggest?

aside: Your history is riddled with inflammatory comments... I like outside-the-box discussion. I gave you an upvote and I really like Python.

Yeah, you're in the minority. Technology is more or less a popularity contest. I've seen plenty of really good programming languages that simply die out because they don't have high-profile personalities behind them. And there's plenty of "meh" or even terrible languages that make it big because the hype is strong with this one. It's not great but at the end of the day, bits are bits and bytes are bytes, most programming languages are all pretty decent ways to manipulate them. You'd have to do pretty badly to go so terribly wrong that nobody should ever use your language, and I don't think I've ever seen a language that bad.

Brainfuck wants a word with you

I thought esoteric languages were obviously excluded :P

Reply on news.ycombinator.com