Hacker News Reader

Comment by iends | Hacker News Reader

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.

View on HN

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

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.

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

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

Works fine for the web needs.

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.

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

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.

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.

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com