231–240 of 329 posts
Earlier quoted context omitted.
Nim. It lets you get stuff done without having to drink the provably correct kool-aid.
GC, though, an a much, much smaller community.
fn gimme_config(some_filename: &str) -> MyConfiguration
{
toml::from_file(some_filename).unwrap()
}Isn't nim built for pythonists to do just this sort of thing?
I think Nim may be the most underdocumented project I've ever used. I spent a week or so with it, but quickly grew extremely frustrated as I was constantly scouring old forum posts to learn how to use the basic features of the language. That is not a tolerable situation for me.
Earlier quoted context omitted.
You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.
As someone whose first introduction to C was through K&R, and still has that torn and tattered copy on his bookshelf, the idea that we're still recommending K&R as "one of the best books about C" only validates arcticbull's (sadly-downvoted) point.
I've read some other "modern" books about C like "21st century C" but they are not for people that do not know C and they are not so good for people that know it.
Can you provide any arguments to support what you wrote? What alternative you would propose for learning C?
https://www.amazon.com/Programming-Language-Brian-W-Kernigha...
Read what majority of opinions say. It's really easy to criticize without giving better alternative.
Earlier quoted context omitted.
The nice thing about C++ is that it is so widely used that for just about any task you can find examples of how to do it (usually many different ways to do something), especially for tasks like this article. You will also find plenty of C example, which you could also use in C++.
Unfortunately 90% of them will be outdated/wrong/unsafe. Being backward compatible with 30 years of code means you're unlikely to find the right answer for the present. And worse, you won't know it.
If you are not being hyperbolic then please backup your 90% claim.
Earlier quoted context omitted.
You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.
As someone whose first introduction to C was through K&R, and still has that torn and tattered copy on his bookshelf, the idea that we're still recommending K&R as "one of the best books about C" only validates arcticbull's (sadly-downvoted) point.
Earlier quoted context omitted.
I would love a `#[derive(From)]` for newtype structs and enum variants. Would bring Rust error handling back below Java in boilerplate levels. :)
Check out https://crates.io/crates/newtype_derive
PS. To my earlier downvoters can I have my hard won karma back, please??? This is the response I have been advised to proffer after consulting on the Nim forum, after my earlier terse comment.
Earlier quoted context omitted.
I'd like to see error-chain standardized into the standard library as well. It seems by far the most sensible approach to building Error types.
Conversely, I really hope it doesn't . error-chain doesn't implement `PartialEq` which means that I can no longer write tests for my failure types. I'm a big believer in quick-error instead.
Might also be possible for error-chain to implement PartialEq if you didn't want some of its generalized error-boxing bits. If that's something you need, you might file an issue.
Earlier quoted context omitted.
You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.
As someone whose first introduction to C was through K&R, and still has that torn and tattered copy on his bookshelf, the idea that we're still recommending K&R as "one of the best books about C" only validates arcticbull's (sadly-downvoted) point.