Live data from Hacker News

My Struggles with Rust

compileandrun.com

321–329 of 329 posts

Re: My Struggles with Rust

#321
post #146

Use Nim

I'm so tired of these incessant incursions from the Nim Evangelism Strike Force!! :P

Sorry about that. These annoying posts led to a discussion on the language forum. The Nim community, generally speaking, does not seem to support this militant attitude.

Re: My Struggles with Rust

#323

Earlier 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).

Cool, thanks!

Re: My Struggles with Rust

#324
post #218

Earlier 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

The subject of your sentence never changed, and the "though" (used as "however" in this case) make the topics related. I think it's more of a solecism than a difference in interpretation.

Glad we're all on the same page though haha.

Re: My Struggles with Rust

#325
post #97

Earlier quoted context omitted.

While it's too late to change the name "expect", could one create an alias for it and call it say, "on_error"?

I'd expect 'on_error' to take a function as a callback, not a string. But yes, a better named function could be added

or_fail_with("") ?

Re: My Struggles with Rust

#326
post #308

Earlier 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…

There are books yes and I've read some of them mostly cover to cover (1 Haskell, 1 F# and 3 common lisp) and still can't proficiently use any of those. Yes there are some things you have to learn like macros, currying, monads. I fully agree with you on that, but feel the task could be much simpler with better intro material. Perhaps the shear amount of material failing to work for so many people is a 100% indication that you're correct and the hurdle can't be made easier to overcome...I don't know. Slightly off-topic, if you're correct...do you ever think FP will take off with the masses?

Re: My Struggles with Rust

#327

Earlier 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.

> I think better structuring would have helped the code much more than unit tests.

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

#328
post #299

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. ... 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.

Somewhat off-topic, but I'm curious to learn about the relatively recent changes in Python's exception hierarchy, could you point me to a link?

Re: My Struggles with Rust

#329

Earlier 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.

But wouldn't that kind of defeat the point? Sort of like how having a type system with only one type wouldn't be very helpful.
Post reply on HN