291–300 of 329 posts
Earlier quoted context omitted.
Yeah I found this odd too. Rust docs say unwrap() shouldn't really be used, but through the rest of the documentation examples it's used everywhere. I suppose it's to keep the documentation simple and focused
Yes, that's why. When ? Can be used in main, we will switch to that en mass.
Being able to port a 20 line Python script to a 20 line Rust is the holy grail. Surely Rust has the ambition to one day achieve that, but it is by no means the main priority nor the original design goal of the language. Justin criticizes the file_double function, it being complex with nested maps and conditionals. All of this complexity is also in the Python code, just hidden away in abstractions, the library and the…
Rust hasn't made significant incursions into math modelling or industrial processing. It's advantages are slim there. Embedded will fracture into network interfacing and realtime where user input is less hostile, more predictable and doesn't require extensive constraint.
I'd like to contribute to many of these packages, but have little interest in learning the languages. Rust could provide a good replacement (and one which is more productive for people used to higher-level languages). There hasn't been much uptake so far, but I'm hopeful.
If the goal is [fast, compiled, statically typed], a language like Crystal [1] would probably be a better fit for the author: require "yaml" config = YAML.parse(File.open("test.yaml")) [1] http://crystal-lang.org
Earlier quoted context omitted.
That is a compiler specific implementation, the ANSI C++ standard doesn't require it.
The ANSI C++ standard requires exceptions in the first place. The moment we start talking about disabling them, we're not talking about standard C++ anymore.
Language != Implementation.
If the language would be "In GCC the thing X happens when ...", then ok.
Earlier quoted context omitted.
Too much kool-aid. Most programmers are not writing system code and they'd be much better served with languages like Go, Nim, and D. In fact, the example the author is trying to port over would have been much easier in Nim. The actual question is then about the author learning a new paradigm and way of expressing system code. If that is the case these are just pains he has to go through because Rust will never be lik…
can nim handle gc across threads yet?
Earlier quoted context omitted.
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.
I think the idea has great potential, but the absence of a strong community is killing it :(
Simplicity is under-rated. With Nim, most problems are easy to grasp just by reading source code. And when I don't understand the docs, I look for a simple example at http://rosettacode.org/
(Scroll to the examples.)
An exception would be thrown on error. That exception could be trapped in a simple try/catch block.
Nim is very similar to Python -- but statically typed and compiled (quickly) to machine code. There are many situations where Python is a better choice than Nim, but if you're looking to translate Python code for speed and type-safety, Nim is worth considering.
And if you want to translate Python to Nim gradually, look at this magic:
For calling Nim from Python: * https://github.com/jboy/nim-pymod
For calling Python from Nim: * https://github.com/nim-lang/python/tree/master/examples
Earlier quoted context omitted.
The ANSI C++ standard requires exceptions in the first place. The moment we start talking about disabling them, we're not talking about standard C++ anymore.
Which is why people cannot just state "In C++ the thing X happens" without regarding what the standard says, instead of what the installed compiler does. Language != Implementation. If the language would be "In GCC the thing X happens when ...", then ok.
Earlier quoted context omitted.
I think the complaint is more that Rust has seemingly tried very hard to make error handling "simple". But in the process it has managed to invent a whole series of new idioms and special syntax that is alien to pretty much everyone. There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on…
I think the complaint is more that Rust has seemingly tried very hard to make error handling "simple". But in the process it has managed to invent a whole series of new idioms and special syntax that is alien to pretty much everyone. ... ways to write this that are split into clear sedimentary layers depending on when the writer learned the language. That's been my criticism of Rust error handling. Rust's error handl…
Java has an exception hierarchy and exceptions as part of method signatures. If anything, Python's exception hierarchy started getting sorted out relatively recently.
Earlier quoted context omitted.
See above where one user is using .unwrap for parsing errors (input errors are recoverable).
I think this discussion is muddying the meanings of "recoverable" between "recoverable as a class" and "recoverable in this instance." Parsing errors are recoverable as a class—you haven't irretrievably corrupted your process memory when you encounter one. Therefore, the parser itself should not panic(); it should just return an option type. Parsing errors may very well be unrecoverable in a particular instance. The…
.unwrap is only suitable for the unrecoverable case, while exceptions are suitable for both cases. Hence why .unwrap in examples is harmful imho.