Hacker News Reader

Comment by codr7 | Hacker News Reader

It said Rust and/or C though, and I imagine learning Rust is pretty easy compared to C from what I've seen.

Rust syntax is strange but understandable to my C/C++/nim/python/elixir experience. I successfully managed to port a few test projects to it several months ago.

Didn't mind the experience at all except for a few niggles which actually are nothing to do with the language itself and more just some of the community attitudes. Some of the evangelists are... less optimal.

people who are very good at C or C++ will be able to learn Rust pretty quickly yes. People who LIKE C probably won't like Rust though. Its more like C++.

For what it's worth, I used to be big on C, and grew to very dislike C++ (because it's simple insane). Rust is my language of choice for years now.

IMO, Rust shares the same inner-simplicity that C has, but combined with ability to build and use bulletproof higher-level abstractions. The same way I roughly knew what machine instructions (roughly) my C code produces, I know what machine instructions my Rust code produces.

Well yes, because LLVM generates the machine instructions

Rust definitely does not share the simplicity of C.

It is the equivalent of C++, not C. You can write code which you cannot guess the machine code, as soon as you use any of the abstractions, just like C++.

Rust’s standard library is about on par with C’s, though.

Rust standard library is dramatically more useful than C’s. C doesn’t offer any kind of collections in its libraries. Every C project just grows its own differently broken hash maps and linked lists.

Compared to C++, Rust's libraries are severely anemic, especially in the areas where C++ is strong at such as collections, algorithms, and metaprogramming constructs such as type traits. Rust's standard library is better than C in certain areas–you identified one, which is dictionaries. (Linked lists are hard to provide a useful, performant API for; it's often better to roll your own–especially in C–than rely on a library to do it for you.) But even without including C's POSIX libraries, Rust seems to be missing things like random number generation. I general, yes, I would probably say that I would prefer Rust's standard library over C's, but it's not huge in any sense and much closer to C's than C++'s. In any case, I came into Rust thinking it would be like C++, and ergonomically it certainly is. But its standard library is nothing like C++'s and this caused me disconcertion until I began treating it like C's, and being happy whenever it provided me anything beyond that rather than disappointed whenever it was missing something I found useful.

Arguably not. Rust has a lot of things that C doesn't, like classes, lifetimes, and the borrow checker, which can be jarring to deal with for programmers used to other languages.

And, unlike most other languages I've seen, you can't just sit down and write a "bad" Rust program and then refine your abilities; the compiler won't let you do the "bad" things, so you have to get everything write from the word go.

Rust does not have classes.

In the wild, the meaning of class ranges from whatever it means in the bowels of theoretical OOP, to a struct that has thing.method() invocation syntax. I'd wager about 99% of people don't get more academic about what classes are beyond the latter definition since it's the only way in their language to create a group of state and then associate some methods with it, which is exactly what Rust has.

I think in the general case, you are absolutely correct.

In a sub-thread comparing language features of two languages to each other to compare their overall complexity, I think it pays to be precise.

From what I understand Rust makes many things explicit that are implicit in other languages. You always have to deal with lifetimes one way or the other.

Which is why I think it would be easier to learn, you get immediate feedback.

> Rust has a lot of things that C doesn't, like classes, lifetimes, and the borrow checker, which can be jarring to deal with for programmers used to other languages.

If you are a competent C programmer - the kind that "doesn't make" memory errors, you have to be manually keeping track of lifetimes and borrows.

Rust takes that mental effort and offloads it to the compiler.

Lifetimes and the borrow checker will likely be jarring for people coming from languages where you don't need to worry about memory allocation and ownership, but if you are coming from C or C++, you will likely find the borrow checker a relief (I did).

> the compiler won't let you do the "bad" things, so you have to get everything write from the word go.

And it's wonderful! Finding and fixing problems at compile time is the fastest and cheapest way to do it, and is also a productive way to refine your abilities.

I've just been recently learning some Rust coming from a heavy C background. The dynamic trait objects mimic what I do in C with vtable pointers and glue functions, and then sometimes I look at it over and over to make sure the casts are right and I haven't forgotten a free or anything. The borrow checker and lifetimes mimic what I do in C with pointer constness and function documentation, and then often I get very nervous and look something up again and maybe add extra intermediary comments on the data flow within a function if I'm not absolutely sure I remembered what the lifetime behavior contract was for a caller or particular callee, and of course I have to do this with all the structs too. The Drop trait mimics what I do in C with either straight-line fallthrough-chained exit labels as interior-exit goto targets or carefully included cleanups before a lesser amount of interior returns, and then I sometimes have to convert between the two for readability, and in the former case I have to carefully use a temporary variable if I also needed to return a non-constant at the end of all that. Compound-value ownership movement mimics what I do in C with either structure assignment or memcpy, and if the latter, hope that I got the pointer types and type size right because memcpy won't check, and in either case hope that I was able to prove that the original structure wasn't going to be incorrectly reused and maybe memset it to zero just in case that makes something crash rather than cause memory corruption.

I expect I'll run into more friction once I get to any point where I want to make more dynamically interlinked data structures, though that might also push my designs into directions that use fewer pointers and more indexes or other indirect references to start with (I'm not sure of that yet)—and I really like the idea that if I can pare some of it down to a working “core” data structure semantic that involves pointer juggling, I can put carefully constructed hard-packed blocks of the pointer juggling in their own unsafe zone and then not be able to accidentally break the invariants outside of that.

Which, again, is almost exactly the same thing I'd tend to do in C with inline wrapper functions and visibility stuff, and making sure I compute all the intermediary results in one phase and putting all the hard mutations in a second, unfailable (except possibly for hard crashes due to null pointers or such) phase so that if something goes wrong the data doesn't wind up crashing down to a persistent broken state from mid-flight!

Heck, I've even done the newtype pattern (single-element structs for safe reinterpretation/bounding of an underlying type) in C before!

I've described the way I write C as “as though I were hand-cranking the front end of a strict, low-level Haskell or Caml compiler in my head”. Rust is the closest I've seen thus far to moving a big chunk of that part of me into the digital part of the compiler. So I'm guessing my taste wasn't exactly uncommon.

Rust doesn't have classes. It has structures (struct) and interfaces (trait).

Reply on news.ycombinator.com