Comment by dualogy | Hacker News Reader

Comment by dualogy | Hacker News Reader

Parent Full thread

How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP".

But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all development at all, but there are select cases where I currently absolutely wouldn't use anything else) as these are those few programs where I really want to write (and later, read) exactly step-by-step "almost machine instructions" and where the only "expressiveness" needed is already fully afforded by Go and quite well at that. Dev-related mostly bulk-file-processing-based custom tooling (not bad to fire off sizable amounts of automatic background transformations from one weird format to another on file-system events etc.) .... filters through which to pipe vast/continuous data streams with just-some-processing over it .... providing out-of-process certain "low-level, must be lightning fast" tasks and logic with IPC for a higher-level codebase .... it's a great tool for such cases, especially given how simple the syntax is. Ie. the basics are grasped very easily very quickly and you don't have to recall "its pattern matching syntax and quirks, its generics syntax and quirks, its etc etc". =) I'm perplexed when teams choose to express their entire domain model or startup in Go, however.. fair game, maybe I'm missing something there

> robust/mature

Needs more context. It's more mature for some things than others, like many young languages.

> how are compile times

Not Go, for sure, but not the worst either.

> how much of a priority are they

Getting them down is a high priority, but has taken some time to make a dent in. The last few releases have all posted speed ups, and "cargo check" in the last release helps. Incremental recompilation is coming, you can try its initial implementation on nightly today. There's a lot more to do, but users really want improvements, so it is and will continue to be actively worked on.

> Incremental recompilation is coming

Good to hear, when that is in place compile times matter a whole lot less

> How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP".

I never get the compile time argument. Well I code a big Scala application and the most time it spents is integration testing. the 10 minute test suite would probably still run 9 minutes and 30 seconds on go. we heavily rely on the database and cover a lot of concurrency/parallelism things in our tests. some things which we would need to test in go, too.

the compile time argument always looks good on first, but later on it's just a dumb way to prefer a language since it never matters. (Actually even the go maintainers didn't cared for a while about the compiler performance).

Well, the thing is, with compile times of 2 seconds I can run my unit tests as fast as possible. At the same time, I'd just use a mock database for most of the tests.

It's great to be able to compile applications like kubernetes in 2 minutes.

Does kubernetes take 2 minutes to build? That seems super long. I csn compile juju (1mil LOC) in like 15 seconds.

I haven't compiled it myself but I've read it's something like that. Though I'm not a 100% sure.

with all dependencies (first time compiling) it takes way longer than 2 minutes.

If compile time is an issue, the new 'cargo check' tool may take some of the pain away.[1]

1 - https://blog.rust-lang.org/2017/03/16/Rust-1.16.html

More to the point, Rust is trying pretty hard on the compile time front. They've almost got incremental compilation out the door, on top of this.

My comment is aimed at the OP who has it very clear in their mind what Go's shortcomings are.

On the contrary, you haven't pointed out an objective issue that you have with Go. You offered some harsh remarks about the language but backed them up with praise.

I'd say you love the language, but apologetically so. You shouldn't it's a great language.

If ever you decide it's not for you then look at other alternatives, rust being one them.

> I'd say you love the language, but apologetically so. You shouldn't it's a great language.

I just think for me it absolutely shines for certain use-cases and sucks for many others, where I simply won't use it. The question then becomes "why Rust over [Haskell&friends]", not "why Rust over Go" ;)

Reply on news.ycombinator.com