Earlier quoted context omitted.
Is there any documentation or discussion on the justification for doing this? I'm scratching my head and asking why anyone would do this intentionally...
I don't use nim, so I couldn't point you to the justification. But as I understand it is so an individual can choose his style preferences. myVariable or my_variable.
Exploring Rust (from C#)
71–80 of 132 posts
Re: Exploring Rust (from C#)
#72Earlier 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…
Sure, it's a misfeature, IMO, but it's certainly not a reason to write off the language. No matter what language you use, if you have two variables named myVariable and my_variable in the same scope, you've created a huge land mine in your code, and your linter should complain. Eventually somebody's going to come along and mix the two up. The fact that nim blows up differently than every other language just makes it…
Yup, having myVariable and my_variable is asking for trouble in any language, and what bothers me about Nim is not at all that it makes that harder.
What bothers me about Nim is that (1) it makes it easier for you to call the same variable myVariable in some places and my_variable in others because that won't make compilation fail; (2) once that happens it becomes harder to find references to that variable, because the usual searching tools will miss some of them (and you will not necessarily get any indication that you've missed any); and (3) there are -- hopefully rare, I concede -- cases where what in another language would be obviously and innocuously different identifiers collide. nOpenFiles versus no_pen_files. use_rsync versus user_sync.
And what does this buy you? What is the advantage it confers? That you have the flexibility to call the same thing myVariable in some parts of your code and my_variable in others. But that's a terrible idea and making it possible is not a feature.
Re: Exploring Rust (from C#)
#73Earlier 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…
Sure, it's a misfeature, IMO, but it's certainly not a reason to write off the language. No matter what language you use, if you have two variables named myVariable and my_variable in the same scope, you've created a huge land mine in your code, and your linter should complain. Eventually somebody's going to come along and mix the two up. The fact that nim blows up differently than every other language just makes it…
> if you have two variables named myVariable and my_variable in the same scope
But that's not the situation in the example. user_sort and use_RSort are perfectly fine identifiers that no reasonable person would expect to be interpreted as the same.
Re: Exploring Rust (from C#)
#74Earlier quoted context omitted.
I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). 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 backgro…
I have done my share of critics regarding Go team decisions, but one thing they got right is that Go is indeed a systems programming language. My understanding being that a systems programming language is one that can be used to bootstrap itself and build a full OS stack with the exception of some Assembly for interfacing with the underlying hardware. As of Go 1.6, the language certainly fulfils this description. If…
You cannot use Go in kernel programming at all without a monumental amount of work. You'd need your own implementation of the language. Go originally did have a runtime that did not require systemcalls and could run on bare hardware, however, this was removed very early on as not being worth the effort.
Re: Exploring Rust (from C#)
#75Earlier quoted context omitted.
Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.
Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with firs…
FWIW I really like "new C++" a lot and am quite hopeful for the ISOCPP stuff as well as C++ Concepts :)
Re: Exploring Rust (from C#)
#76Earlier quoted context omitted.
Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of to…
> But I don't think it's any harder than c++ For the time being it surely is. With C++ I just download XCode or NDK/Android Studio/Visual Studio. I don't need to bother with FFI on iOS and Windows. On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language. The IDEs show visual representation of data structures when debugging and two way editing between C++ and the re…
> Need to compile that toolchain myself and write my own wrappers to OS APIs.
Nah: https://users.rust-lang.org/t/multirust-0-8-with-cross-std-i...
Before this feature the cross libs existed, just that there was no UI for downloading and installing them.
Re: Exploring Rust (from C#)
#77Earlier quoted context omitted.
Thanks - kicked off a resize, that may not have been the best idea. That'll teach me for hanging on to mainframe-era blogging technology :-)
Mainframe-era blog tech, eh? http://www.coboloncogs.org/INDEX.HTM
It's funny until you run into a group of people actually using COBOL to run their website.
Re: Exploring Rust (from C#)
#78Does anybody know how good the Rust integration with Windows is? The language looks very good but can you interop with Win32, COM and .NET? Is there a debugger? Without those its usability is a little limited.
Re: Exploring Rust (from C#)
#79I like the author's attempt to explain Rust's borrow checker to a new audience by inventing a variant of C#. Lifetimes are certainly one of Rust's most unique features, and the existence of analogies to express unfamiliar concepts in terms of familiar ones is very valuable.
What I like about the concept is that as soon as you explain it, the first response you see is "Wait, that doesn't already happen in other languages?"
The idea just makes sense, it's "right".
Re: Exploring Rust (from C#)
#80Earlier quoted context omitted.
Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.
Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with firs…
> Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++.
No, there aren't. Empirically, modern C++ projects are not memory safe. Maybe when you qualify it with this:
> At least when using it alone or in small teams that value safety.
But I suspect the reason it looks that way is actually this: Projects that are developed alone or with small teams tend to be less important projects that people don't try to attack and/or find memory safety problems in. The lack of people actively looking for memory safety problems makes it look like C++ projects are safe, but in reality they aren't. If solo/small team projects in C++ had anywhere near as many people looking for holes as big ones like browser engines, then they'd fall over too.
I don't have any hard statistics for this, but given the consistent memory safety track record of C++ projects I think I'm more likely to be right here than wrong. I've written small projects in C++ and I don't think they're memory safe, even though I don't know of any areas where they aren't. I just know what the statistics are.