The one thing that would put rust over the top right now is something along the lines of gofmt - something simple, with zero configuration, that can be run on commit or even save.
gofmt is nice.
gofix: way more useful!
Announcing Rust 1.0 Alpha
141–150 of 255 posts
Re: Announcing Rust 1.0 Alpha
#142Earlier quoted context omitted.
You're arguing with a general observation. The fact that it's not universally true is unsurprising. If you take the average quality of third-party libraries and the average quality of libraries in the standard library, I think you will find that the standard library is generally pretty good.
Whether it's better than the average is irrelevant, that isn't the benchmark. It needs to be better than or equal to all of the third party libraries for it to be worthwhile, otherwise, why does it exist? When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those c…
> When you pick a library you don't pick all of them, you pick just the best one that meets the criteria you need, and the standard library can't beat the flexibility that other people will have to better meet those criteria without needing to partake in the process upstream.
So, you're using three libraries that all depend on something like urllib - and they each use the library that fits their usecase best. Now you need to debug/review/depend on updates for 6 (7 if you also use the stdlib for something) foreign codebases rather than 3 + the standard library.
It's a trade-off between old/new good/best simple/complex (or complicated/complected). A standard lib that needs to maintain stability for 10+ years can never be "best" for all that time. But by being "good enough" it can often still be the best choice overall when the life cycle of a project is considered.
Re: Announcing Rust 1.0 Alpha
#143The one thing that would put rust over the top right now is something along the lines of gofmt - something simple, with zero configuration, that can be run on commit or even save.
Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are times when you want things spaced out to align columns, or hide a distracting error handling case on one line (instead of making it take 3 lines of precious vertical screen real estate). I find gofmt to be too opinionated about certain things and I will never use it for my go programs.
Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.
Re: Announcing Rust 1.0 Alpha
#144Earlier quoted context omitted.
indent(1) has been around for ages. Where does this sudden need for universal style goose stepping come from?
1) A lot more code isn't read in vim or emacs nowadays. We don't have the equivalent of indent on the github web ui 2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes. 3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious…
Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone.
The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call should look like in the code I'm editing?
I'm not convinced that this should leave the bounds of a project. Within that, sure! Let's put a .rustformat right next to .gitignore, and whatever your source discombobulation utility is called just takes its hint from there. Certainly nothing wrong with a language having a good indenter, doc tool and linter in the core distribution. But one language, one style, one tab width!?!
This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.
Re: Announcing Rust 1.0 Alpha
#145Earlier quoted context omitted.
Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are times when you want things spaced out to align columns, or hide a distracting error handling case on one line (instead of making it take 3 lines of precious vertical screen real estate). I find gofmt to be too opinionated about certain things and I will never use it for my go programs.
Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.
It's good enough when you can configure it and apply it selectively. If I want to clean up a function in my code base, I can e.g. select it and run "perltidy" over it, which has a configuration dot file for the company code standard (or CPAN guidelines etc.).
Or just clean up some nags so that version control behaves better. But if the only option is not running it at all or having all the code automatically fit to whatever the people On High have deemed to be visually pleasing? Yeah...
Re: Announcing Rust 1.0 Alpha
#146Re: Announcing Rust 1.0 Alpha
#147Earlier quoted context omitted.
Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), tha…
While I'll readily agree that some parts of the standard library are rotten, that's not sufficient justification to say that there shouldn't be one. I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data…
The other thing that really needs to be in the standard library is protocols & interfaces that will be implemented by a number of userspace libraries. Go benefits immensely from having standard io.Reader and io.Writer types and most people implementing them instead of defining their own. Similarly, most of its web frameworks use http.ResponseWriter and http.Request instead of defining their own. Python's unittest module may be a mess as a test framework, but all the major Python unittest frameworks take a unittest.TestCase, which keeps tests portable among the different systems.
The worst case is exemplified by pre-STL C++, which didn't even have a string type in the stdlib. As a result, every project and library wrote their own, which meant that you basically had to choose a C++ ecosystem and develop for it rather than write libraries that are portable across multiple C++ projects.
Re: Announcing Rust 1.0 Alpha
#148Earlier quoted context omitted.
I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use. Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and str…
Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), tha…
What's wrong with the exceptions? I never noticed that problem but agree completely on all your other points. (Especially itertools – why aren't the "recipes" defined in the module?!)
Re: Announcing Rust 1.0 Alpha
#149Congrats to everyone involved (and there sure are a lot of you)! The TL;DR of the alpha is basically this: 1. The concept of a six-week release cycle begins today, with the first beta coming in March. 2. Breaking changes will basically cease, with the exception of a list of libraries that are still unstable and features that may be tweaked ( https://github.com/rust-lang/rust/wiki/Anticipated-breaking-... ). 3. Given…
It is now time to begin looking into Rust.
Good timing too! I have a few projects coming up that could really benefit from the memory safety and performance features rust offers.
Re: Announcing Rust 1.0 Alpha
#150Earlier quoted context omitted.
1) A lot more code isn't read in vim or emacs nowadays. We don't have the equivalent of indent on the github web ui 2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes. 3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious…
Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone. The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call shou…
I think you're kind of missing the point.
The point isn't to have a "house" style, it's to have an "everything" style.
Making it optional or configurable defeats the purpose.