Use Nim
I'm so tired of these incessant incursions from the Nim Evangelism Strike Force!! :P
My Struggles with Rust
321–329 of 329 posts
Re: My Struggles with Rust
#322Re: My Struggles with Rust
#323Earlier quoted context omitted.
Does Crystal have YAML.load_file like Ruby does? Loading a YAML file only requires one method call in Ruby.
Crystal does async IO underneath, so this approach allows the use of a streaming parser (you're just passing it a file handle, not the contents).
Re: My Struggles with Rust
#324Earlier quoted context omitted.
>right now it's Elixir but I'm going to be evaluating Haskell, not a huge fan of the JVM langs tho FYI, Haskell is not a JVM language. It compiles to binaries, the compiler is called GHC. Elixir runs on the Erlang VM, also unrelated to JVM.
I was not trying to suggest that Haskell was a JVM language. I said I wasn't a fan of the JVM languages (like Scala and Clojure), but I can see how someone might think that due to how I worded it, perhaps a semicolon instead of a comma would have helped, there
Glad we're all on the same page though haha.
Re: My Struggles with Rust
#325Re: My Struggles with Rust
#326Earlier quoted context omitted.
No, the training material for something like Python is orders of magnitude easier to get into than things like OCaml, Haskell, and Lisp. Python has doc and many many books taking you from A through Z. Many of these other languages have "A" and then pick back up at "S", but skip over "B"-"R". You basically get a feel for syntax, control flow, and a few other topics, but don't get the meat of why that language is diffe…
If it is something that OCaml, Haskell and Lisp are not lacking, it is books written about them. We can argue on technical points. But the existence of documentation is a non-issue for all of these languages. https://ocaml.org/learn/books.html https://wiki.haskell.org/Books http://lisp-lang.org/books/ It could well be, that these books are written for experienced programmers who don't need basic concepts (control flo…
Re: My Struggles with Rust
#327Earlier quoted context omitted.
> The thing is that most of the conditionals were never hit under ideal conditions (like passing all args etc.). Your debugging work in this case might have also been alleviated by a good unit test covering this functionality.
It would have been. But it wasn't my code, I was merely using it. I think better structuring would have helped the code much more than unit tests. Unit tests are good to ensure you don't break things. But spaghetti code that passes tests is still considered broken by my standards.
This is why you TDD. Your code will automatically become more modular/structured by the very nature of having to unit-test it "right then and there" instead of hours later when you finished the component without any tests and decide to bang out a few basic integration tests and then head to happy hour and call it a day.
> Unit tests are good to ensure you don't break things. But spaghetti code that passes tests is still considered broken by my standards.
I agree, that's still technical debt. You literally cannot write spaghetti code if you TDD, though. You would feel a massive friction.
Re: My Struggles with Rust
#328Earlier 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. ... 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…
There's no exception hierarchy. Knowing what exception something can raise is very important. Often, you don't. Java has an exception hierarchy and exceptions as part of method signatures. If anything, Python's exception hierarchy started getting sorted out relatively recently.
Re: My Struggles with Rust
#329Earlier quoted context omitted.
Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more exceptions to the throws list). So you end up wrapping in RuntimeExceptions and then later having the whole app fall over because the framework that's expecting your class was only designed to handle the checked exceptions. So yeah, want your implementation to consul…
Checked exceptions probably would have been fine if there were only one kind of checked exception. Most methods would declare it and they'd all be compatible. This would be similar to how Go functions always return the same error type, but without the boilerplate.