5 ms·

"I guess that's why the Go compiler is so fast - it barely checks for anything!" Any serious Go programmer ought to have golangci-lint or equivalent running so

by jerf 5y ago

"I guess that's why the Go compiler is so fast - it barely checks for anything!" Any serious Go programmer ought to have golangci-lint or equivalent running somewhere. I prefer pre-commit, but CI/CD will do too. An advantage of golangci-lint is that is not in the core compiler, so you can get some really opinionated linters from the community, some of which you're going to love and some of which you're going to hate, or linters written really quickly and hammered out in the real world rather than waiting for the full release cycle. A disadvantage of golangci-lint is that it's not in the core compiler, so you have to actually fetch it yourself, maintain it (configure it), etc. With golangci-lint, Go is still not Rust, of course, but it gets it a pretty decent way towards being a serious, quality language. Most languages need some augmenting to be serious, quality languages, because it isn't generally appropriate to put all the requirements for code into the compiler, for many reasons. Rust is somewhat exceptional in how much they've put in their compiler. Things like C and C++ need immense, high-quality support from static analyzers to be even remotely safe to use on a network. (So, yes, I don't consider C or C++ "serious, quality" languages in the absence of that static support. I don't even consider it close, honestly. I don't consider very many languages to be serious, quality languages out of the box.)

roblabla 5y ago
I suspect you know this, but for anyone not aware: Rust's equivalent to golangci-lint is Clippy, which is distributed as part of Rust (at least, with rustup, it comes with the compiler in the default configuration). You have to run it separately, but it contains a ton of lints[0]. The default configuration is pretty good (Most of the warnings I've got with it were either bugs or nudging me towards better APIs to do what I wanted). And what's really nice about clippy is that it re-uses a lot of the compiler's infrastructure instead of having to duplicate it, so it has the same high-quality error messages, and stays in sync with rust's new language features. [0]: https://rust-lang.github.io/rust-clippy/master/index.html https://rust-lang.github.io/rust-clippy/master/index.html
zozbot234 5y ago
I don't think that was intended as a serious remark, because the compiler-checks part of Rust compilation is not that slow. Rust compiles are slow when generic monomorphization or macros generate a lot of code to be compiled, or when complex macro packages are used as a kind of (slow) compile-time computation. The former can probably be addressed by some version of non-MVP const-generics; we will likely be able to "forward" implementations of generic functions and traits to code that only has to be built once for each set of type-derived parameters.
UnpossibleJim 5y ago
This question may be a bit off topic, so I apologize. I don't work with Rust on anything except homebrew projects, so time is never really of the essence. At work, I use scripting languages (Python and Javascript - mostly Python). Is compile time anything except an annoyance, in the real world? Has it really run you up against such close deadlines that an hour of compile time is going to break the company so far as the projects that Rust is being used on? Now, I will fully grant you, I enjoy Rust and like programming in it for fun, but have not kept up on what projects have been made in the wild and professional worlds with it, past Mozilla, TBH. I know a lot of companies are recruiting, but haven't seen much coalesce. Could be my ignorance, though.
- assbuttbuttass 5y ago
  It's not about missing deadlines, it's about staying focused and not being interrupted while I'm working. At work I use both C++ and go. My experience working on a C++ project is that it takes several minutes just to build, so when I make a change and try to run the unit tests, I find myself wasting a lot of time. I'll often get bored and go on HN for example :) When working on go it's like night and day. Projects mostly compile in less than 30 seconds (unless it has a lot of C++ dependencies). With this pattern I can maintain my focus and continue the modify-build-test loop, I find I end up being a lot more productive.
  - anamax 5y ago
    https://xkcd.com/303/ https://xkcd.com/303/
  - zozbot234 5y ago
    > when I make a change and try to run the unit tests, I find myself wasting a lot of time You might want to adjust your workflow and make it fit the language better. Avoid relying on unit tests for semantics that can be trivially checked by the type system. Get into the habit of launching builds as part of your work, then check back on the test results after they're done. A build doesn't have to "interrupt" your flow if you plan it correctly.
- 5y ago

by jerf 5y ago

roblabla 5y ago

I suspect you know this, but for anyone not aware: Rust's equivalent to golangci-lint is Clippy, which is distributed as part of Rust (at least, with rustup, it comes with the compiler in the default configuration). You have to run it separately, but it contains a ton of lints[0]. The default configuration is pretty good (Most of the warnings I've got with it were either bugs or nudging me towards better APIs to do what I wanted). And what's really nice about clippy is that it re-uses a lot of the compiler's infrastructure instead of having to duplicate it, so it has the same high-quality error messages, and stays in sync with rust's new language features. [0]: https://rust-lang.github.io/rust-clippy/master/index.html https://rust-lang.github.io/rust-clippy/master/index.html

zozbot234 5y ago

I don't think that was intended as a serious remark, because the compiler-checks part of Rust compilation is not that slow. Rust compiles are slow when generic monomorphization or macros generate a lot of code to be compiled, or when complex macro packages are used as a kind of (slow) compile-time computation. The former can probably be addressed by some version of non-MVP const-generics; we will likely be able to "forward" implementations of generic functions and traits to code that only has to be built once for each set of type-derived parameters.

UnpossibleJim 5y ago

This question may be a bit off topic, so I apologize. I don't work with Rust on anything except homebrew projects, so time is never really of the essence. At work, I use scripting languages (Python and Javascript - mostly Python). Is compile time anything except an annoyance, in the real world? Has it really run you up against such close deadlines that an hour of compile time is going to break the company so far as the projects that Rust is being used on? Now, I will fully grant you, I enjoy Rust and like programming in it for fun, but have not kept up on what projects have been made in the wild and professional worlds with it, past Mozilla, TBH. I know a lot of companies are recruiting, but haven't seen much coalesce. Could be my ignorance, though.

assbuttbuttass 5y ago
It's not about missing deadlines, it's about staying focused and not being interrupted while I'm working. At work I use both C++ and go. My experience working on a C++ project is that it takes several minutes just to build, so when I make a change and try to run the unit tests, I find myself wasting a lot of time. I'll often get bored and go on HN for example :) When working on go it's like night and day. Projects mostly compile in less than 30 seconds (unless it has a lot of C++ dependencies). With this pattern I can maintain my focus and continue the modify-build-test loop, I find I end up being a lot more productive.
- anamax 5y ago
  https://xkcd.com/303/ https://xkcd.com/303/
- zozbot234 5y ago
  > when I make a change and try to run the unit tests, I find myself wasting a lot of time You might want to adjust your workflow and make it fit the language better. Avoid relying on unit tests for semantics that can be trivially checked by the type system. Get into the habit of launching builds as part of your work, then check back on the test results after they're done. A build doesn't have to "interrupt" your flow if you plan it correctly.
5y ago