Live data from Hacker News

Exploring Rust (from C#)

nblumhardt.com

121–130 of 132 posts

Re: Exploring Rust (from C#)

#121
post #115

Earlier quoted context omitted.

Thirty years of C obviously has fixed the mindset of many developers so much that they don't even want to think in different ways :-(

Please don't leap so quickly to psychoanalysing the presumed intellectual failings of people who disagree with you. (I do not think your analysis is anywhere near correct in my case, even though I think Nim's identifier comparison rules are very unwise.)

I just agree with http://blog.codinghorror.com/the-case-for-case-insensitivity....

Re: Exploring Rust (from C#)

#122
post #115

Earlier quoted context omitted.

Please don't leap so quickly to psychoanalysing the presumed intellectual failings of people who disagree with you. (I do not think your analysis is anywhere near correct in my case, even though I think Nim's identifier comparison rules are very unwise.)

I just agree with http://blog.codinghorror.com/the-case-for-case-insensitivity... .

But this isn't about case-insensitivity.

Re: Exploring Rust (from C#)

#123
post #122

Earlier quoted context omitted.

I just agree with http://blog.codinghorror.com/the-case-for-case-insensitivity... .

But this isn't about case-insensitivity.

There was a C++ developer at job mocking me for using Perl until he realized how much easier data can be parsed with it (and used my Perl code for himself). There are people who despise Lisp just for its parentheses without understanding their purpose which makes Lisp so elegant and powerful. People mock Nim for some things mentioned here without paying attention to the gain of productivity. I am always amazed how banal things can hinder smart people to advance.

Re: Exploring Rust (from C#)

#124

Earlier quoted context omitted.

Theoretically they (or whomever writes an OS in Go) could extend the runtime to add something like `makestack(Type, size IntegerType) Type` to mimic alloca or add in a guarantee that `var b [100]byte` will be allocated on the stack. (Right now I think it is , but I know there's a Go issue dealing with a function like this, and one of the comments was about potentially creating `a` on the heap and returning an invisib…

There's a lot more than that that you have to do. You can't even implement defer without allocation, just to name one example.

True, the amount of Assembly in a bare metal runtime in Go vs a runtime free version of Rust will be higher.

Still, there are quite a few scenarios that could be served by such implementation, instead of being implemented in C or C++.

As I mentioned in another thread, any embedded board computer similar to a Raspberry PI could most likely be easily targeted by such cross-compiler.

Re: Exploring Rust (from C#)

#125
post #20

Earlier quoted context omitted.

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring…

I tried to get into nim, but then I started reading the source for some of their stdlib and finding bugs. I pointed it out on the boards and the response wasn't all that great, so I decided to spend my time elsewhere. I started picking up Rust a few weeks ago, so far I'm having fun :)

I'm really sorry to hear that :(

Any chance you could give me a link to the thread/issue you posted? I really want to see where we went wrong.

Re: Exploring Rust (from C#)

#126
post #20

Earlier quoted context omitted.

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring…

I tried to get into nim, but then I started reading the source for some of their stdlib and finding bugs. I pointed it out on the boards and the response wasn't all that great, so I decided to spend my time elsewhere. I started picking up Rust a few weeks ago, so far I'm having fun :)

Would really appreciate some kind of link to the discussion you mentioned..

Re: Exploring Rust (from C#)

#127
post #118

Earlier quoted context omitted.

Way too ascii-centric. Getting case transformations right in the presence of unicode can be complicated.

Unicode in identifiers is ugly. I never use that.

Helps make code look more like the algorithm it's implementing - would rather just use α than keep spelling out "alpha" every time. Good editors and REPLs make it easy to enter unicode symbols by tab-completing the latex spelling, e.g. \alpha gets replaced by α.

Re: Exploring Rust (from C#)

#128
post #125

Earlier quoted context omitted.

I tried to get into nim, but then I started reading the source for some of their stdlib and finding bugs. I pointed it out on the boards and the response wasn't all that great, so I decided to spend my time elsewhere. I started picking up Rust a few weeks ago, so far I'm having fun :)

I'm really sorry to hear that :( Any chance you could give me a link to the thread/issue you posted? I really want to see where we went wrong.

I logged back into the forums to try and find it, but I didn't see a way to pull up old posts.

IIRC, the issue I posted about had to do with some of the underlying parsers. I was looking at the CSV stuff and I believe one of the types it relies on had a skipBOM function, or one of the functions would skip the BOM, or something along those lines.

But what it did was blindly increment the file pointer without checking it was looking at a BOM, or that it was at the start of the file.

To me the interface is a fairly big deal because you can't safely use the type without knowing that implementation behavior. People do stupid crap, and calling skipBOM at the wrong time will happen, even though it's obviously not intended. What I recall is recommending that it either fail noisily or turn into a noop. I'm on the side of failing noisily to help users of the class find their bugs quicker, but I can understand why someone would want it to be a noop since technically doing nothing if it's not a BOM is the right thing to do.

The response I got was the type wasn't meant to be part of the public interface for the stdlib and so wasn't an issue, and then I was pretty much ignored after that statement. I even offered to do the work myself, but pretty much got ignored.

It wasn't so much that the reaction was negative, as much as it wasn't conducive to improving the stdlib all that much. And from my perspective, one of the biggest problem nim had (at the time) is that the stdlib felt very unpolished. As if someone had written it for very specific use cases and then haven't revisited it. I guess what I'm saying is that it didn't feel like an stdlib in many places, it felt like someone who wrote some production code for very specific use cases. Which is perfectly acceptable for production code with a specific use case, but not for an stdlib (in my opinion).

The entire thing left a bad taste in my mouth and I lost a lot of trust in the quality of the stdlib and so decided to stop learning/using nim.

It's all a little fuzzy in my mind, so I may not have all the details correct but the loss of trust was definitely the result.

And who knows, perhaps I was misreading the code, I wasn't all that experienced with nim at the time. But even having someone point out it was my mistake would have felt better than simply being ignored.

It's too bad really, because I did like the language itself, which is why I had offered to try and help improve the stdlib. Nowadays I'm picking up rust for fun(putting together an NES emulator in it). I'm a little bit of a language whore :)

Re: Exploring Rust (from C#)

#129

Earlier quoted context omitted.

I tried to get into nim, but then I started reading the source for some of their stdlib and finding bugs. I pointed it out on the boards and the response wasn't all that great, so I decided to spend my time elsewhere. I started picking up Rust a few weeks ago, so far I'm having fun :)

Would really appreciate some kind of link to the discussion you mentioned..

I responded to dom96.

Re: Exploring Rust (from C#)

#130
post #125

Earlier quoted context omitted.

I'm really sorry to hear that :( Any chance you could give me a link to the thread/issue you posted? I really want to see where we went wrong.

I logged back into the forums to try and find it, but I didn't see a way to pull up old posts. IIRC, the issue I posted about had to do with some of the underlying parsers. I was looking at the CSV stuff and I believe one of the types it relies on had a skipBOM function, or one of the functions would skip the BOM, or something along those lines. But what it did was blindly increment the file pointer without checking…

It seems that the thread you are referring to is this one: http://forum.nim-lang.org/t/1569 (the forum profile view really needs a listing of the person's threads/posts).

From looking at the thread, it seems that this is a simple case of your thread becoming lost in the noise of the forum. Please don't feel that you were ignored on purpose. I think that Araq simply forgot to reply to you, it's easy for threads to get lost like this.

It really sucks, but the fact is that Araq doesn't have enough time to answer everyone and in this case he is the only one who could have assisted you.

In all honesty I think this is quite common in forums. I'm not sure how we can improve it, short of getting full-time Nim devs who ensure that everyone on the forum gets a response. What do you think?

Post reply on HN