Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Best programming language or theory to learn before learning Rust?
89 points by philonoist on July 4, 2018 | hide | past | favorite | 66 comments


Honestly, I might just jump in and learn Rust.

I think it's a good place to start with memory management issues because you have to deal with it but good practice is enforced. C/C++ is the obvious alternative for that level of programming, but it's less constrained, which is better in some ways but bad in others. If you're wanting to learn Rust eventually, you might as well start there.

If you're wanting to not start with the low-level memory management stuff, and want an introduction to programming per se, there's lots of options.

One thing to think about is OCaml. It's a nice language, similar to Rust in some regards, and in fact Rust was originally written at least partially in OCaml, and for awhile was kind of discussed as a derivative of OCaml in some places. You'll get a mixed imperative-functional kind of introduction without going to quite as low of a level.

Another approach is to to just learn a language. In that case I'd probably recommend Python (probably Python 3) or javascript, because there will be a ton of resources and the skills will directly transfer. If you're looking for something that's maybe more niche but "clean" you could try Julia or Nim. Julia's very numerics focused and is getting used in that area, but doesn't get used out of that, at least so far. Nim is very very niche but a good language, similar to Python but faster and cleaner and some ways. Another thing to think about is Scala, which might transfer to Rust in some ways better than the others (except OCaml).

Honestly, though, I might just start with Rust. It will be heavy going at first, but I think learning the memory stuff is very very useful later. It depends, though. I think you have lots of good options. What's most important is to just dive into something that's interesting to you and start creating stuff, regardless of how small it is. A lot of concepts will transfer across languages.


C/C++ is the obvious alternative for that level of programming, but it's less constrained, which is better in some ways but bad in others.

C++ is an archaeological dig of a language, which has about 4 major strata. It can be an entirely different language project to project, depending on how you use it. However, I suspect that a particular C++ style using smart pointers and RAII can be a good preparation for Rust. This is especially true if you can contrast that C++ style with some other woolier style of C programming.

If you want to be very knowledgeable, 1) write a compiler that produces machine code and 2) do some concurrency.

What's most important is to just dive into something that's interesting to you and start creating stuff, regardless of how small it is. A lot of concepts will transfer across languages.

The best advice by far.


> C++ is an archaeological dig of a language, which has about 4 major strata. It can be an entirely different language project to project, depending on how you use it.

This should be the canonical way to describe it. Brilliant.

This is THE reason that I don't recommend C++ as a stepping stone language. If you need it use it, no hate, but it can make using online resources a mishmash of guesswork until you grok the history of the strata.


Ugh. I was there for all those strata. I feel old now...


I have what I have been told is 'expert' level knowledge in bash - how do I translate that knowledge into another language?


Start learning another programming language. Maybe two or three. They aren't like spoken languages: there are only a few words, and syntax is explicit.

Programming languages will feel a bit foreign since there are different paradigms involved, but you have a solid perspective to start with.

Since you know bash, you know the environment your programs will run in. Start by learning simple IO with stdin, stdout, and stderr. The rest is basically just different methods to organize your code.


Try a dynamically typed language like Ruby, Python or Lua. It's closest to Bash, but different enough to let you learn the power of a true programming language.

Then try a statically compiled language like F#, C#, OCaml, or Kotlin, depending on what kind of platform you like.

Then try a lower level language like C, Ada or Rust.

There are of course completely different paths you could also take, like tossing Prolog or Haskell in there somewhere, but the above path will cover the basics of what's most widely used in industry, ie. functional, imperative and OO paradigms, curly brace syntax vs indentation based syntax, the common control flow abstractions, statement oriented vs expression oriented languages, and statically and dynamically typed languages.


Hmm might be good to think about this as what career path you'd like. If you're IT for example and want to move into ops or something, maybe you can start looking into writing things for chef or puppet.


Study C then some assembly, meanwhile learning basics of computer engineering, have a solid understanding of discrete math.


You don't really "get told" you're an expert at something-- if you're waiting for someone's certification that you're an expert, then you're probably not an expert.

I don't mean to diminish what I'm sure is your extremely proficient grasp of bash; rather I mean to diminish the way you presented it. If you're an expert, you know it without being told.


I think he's just being modest and not claiming that he's expert, just that he's considered to be one. You're reading way too much into that single sentence.


On the contrary; I've been told I'm expert level at things I don't consider myself an expert in. I always chalked it up to the fact that "the more you know, the more you realise you don't know"


As with natural languages, if you want to learn language X, go learn language X and don't try to learn Y first. So if you want to learn Rust, learn Rust.

In my experience, particular theory as in CS papers isn't needed for learning Rust. Understanding the runtime stack, RAII from C++ and malloc/free from C helps, but if you haven't already programmed in C and C++, it doesn't make sense to learn them in order to learn Rust. Any introductionary lecture on how the runtime stack works combined with the abstact idea of pointers to heap should be enough (no need to know how heap allocation works in detail).


I can't find it right now, but I've read a study that showed that teaching Python and then another language yields better understanding then just jumping into the harder language.

I was able to find the article "What About a Simple Language? Analyzing the Difficulties in Learning to Program" by Mannila, et al., which found that first time programmers found it easier to write bug-free programs in Python than Java and subsequently had a lot less trouble with the details of Java after learning Python, as they did not have to use the mental bandwidth to learn the most basic concepts of programming while also learning static typing and the incantations required to use Java.


As the very first language Python may be a good choice compared to Rust in the sense that one can learn to _program_ with a smaller risk of such up-front frustration as to give up altogether.

However, after getting to the point of feeling “I can do this programming thing”, I don't think Python provides any specific help for learning Rust more efficiently than learning a given thing in Rust directly.


I think it's sometimes difficult for those that already know how to program to look back and realise what it feels like to not now anything about programming. When you're starting out you're really learning three things at once:

General problem solving, the vernacular and methodology of programming (what's a variable, a function, control structures, how is a program run, what are expressions and statements, etc.), and finally the actual language itself.

The first two are universal across languages, but the third is very different depending on what you pick. A language like Python makes that part much simpler than a language like Rust. There's fewer hoops to jump through, less to keep track of, and you can dive in applying your newfound knowledge of the first two topics.


Unless the target language is functional language. Actually, prior experience in imperative languages makes it harder for you to move into functional programming language, as you have to unlearn some things.


I wonder if the same isn't true going the opposite direction, too - learning functional, then moving to imperative. But it's much less common to do it in that order, so we may not see it happen enough to notice it as a pattern.


That's an interesting choice of analogy; there's some evidence that's not necessarily the best approach: https://en.wikipedia.org/wiki/Propaedeutic_value_of_Esperant...


No, there isn't, at least not in that article. If you actually read the studies referenced, you'll notice that none of them actually support the claim that learning Esperanto first is better than just starting with your actual target language directly. Learning Esperanto can speed up learning another language with shared vocabulary, but not so much that it offsets the initial time investment of learning Esperanto.

Given how often it seems to be used to perpetuate dubious claims about Esperanto's almost-magical benefits, I'll need to find some time to completely rewrite that Wikipedia article. For now I'll just link to a review of one of the studies I wrote up a while ago: https://news.ycombinator.com/item?id=14848019


I agree with hsivonen that knowing about "the runtime stack, RAII from C++ and malloc/free from C helps". Maybe learning common problems with pointers and what they are will be good to do. After that you are good to learn Rust.


Idk having learned Python for 4 months it helped when I transitioned to JavaScript. A lot of things I knew how to do in Python I tried in JS and they seemed to work. It certainly helps to learn similar languages, and in my opinion it never hurts to know more programming languages. :)


While everything you said is true, imagine your final goal was to learn Javascript: going through Python wouldn't help significantly. I feel that was the point of parent. Certainly, learning your first language (or first language in a certain paradigm) is a whole different matter than picking up a bunch of other similar-looking ones.



No, not at all. I didn't have the foggiest idea what a linear/affine type was when I started learning Rust, and it didn't hinder me at all.

(Rust doesn't even have linear types, btw)


Rust doesn't have linear types? You'll have to elaborate on that because Jim Blandy at least would say you are wrong.


Rust has affine types, not linear types.


To clarify, with affine types you can guarantee that a value is used at most once, while linear types enforce that a value is used exactly once. Rust has the must-use directive that can be used to approximate linear types but it has severe limitations.


Do you know C or other languages with manual memory management? Rust requires an understanding of memory management at a level lower than what languages like Java, Python etc. expose. The complex parts of Rust (borrows checker, lifetimes etc.) are ingenious solutions to problems which simply does not exist in a safe garbage-collected language. And most Rust tutorials assume an understanding of the difference between stack and heap allocation and so on.

You can learn all that from Rust, but it is possible you will have a better understanding of the design decisions if you have first experienced writing a C program and having it crash due to some memory management issue.


Yes. I have a confident understanding of C. I, however, don't have knowledge of RAII and concepts specific to C++ like many have pointed out here.

Thank you.


If you know C, I think you should just go ahead and dive into Rust.


May I ask why you are interest in Rust so much that you are willing to invest time learning another language first before jumping to Rust? Is it the hype?

I would say start straight with Rust. Maybe you will find that it is not what you wanted/expected, and decide that another language will work better for you.

If you do like it and think it’s what you were looking for, you can always go back and read theory, other languages.

Despite its hype, Rust is no silver bullet(lots of unsafe calls in all libraries, mem leaks are still possible, etc..), so give it a go first and see if it’s indeed your cup of tea.


Languages are never prerequisites for other languages.

Go ahead and start learning all of the languages you are interested in. At the same time.

There isn't that much information to remember. Each language has simple grammar and only a dozen or two words.

The subtle differences between languages give context to each other.


I'd just get started with Rust. There are many great tutorials and references out there, and it's not nearly as hard or scary as some of its critics would have you think.


Yeah, I have no idea why you'd serially learn something first. Sounds like procrastination really. As if OP is too scared of failing that they keep putting it off.

If knowing something is going to help you with Rust, then it will help you even more in parallel when you've gained some entry-level experience with Rust.


Their ebook[1] is amazing and the compiler is really helpful giving tips, pointing to errors, and explaining everything as much as it can. It's a pleasure to use it.

[1] https://doc.rust-lang.org/book/second-edition/index.html


C++, but you're better off just starting with rust. C++ is a bottomless, dark pit.

The primary reason to learn it first is to focus on manual memory management. You could also just delve into C, but I still recommend just beginning with rust and skipping the cruft.


C++ is a bottomless, dark pit.

It's an archaeological dig of a language, representing something like 4 major strata. Archaeological digs have pits. The way to learn C++ is to limit scope and learn a particular style of C++.


I like to guide newbies I'm training in C++ to only ever use stack allocated objects and pass everything by ref for as long as possible. I think avoidance of utilizing the heap is a great idea while you're still learning and... Eh, I'm getting less sold on the performance benefits of direct heap allocation instead of using various framework (Yay Qt) or STL structures that wrap around heap allocations vs. the trade off in maintenance. (Performance definitely improves but it isn't by as much as you might think and the cost is non-negligible)


Eh, I'm getting less sold on the performance benefits of direct heap allocation

What's your application for high performance?


There isn't one, if I was working in an embedded environment I might be much more enthusiastic about heap allocation, but since I tend to work on systems that value maintenance above eek out every cycle they can... cutting direct heap allocation out has greatly improved our dev speed.

FYI, I still do utilize heap allocated objects via STL & framework objects, I just leave all heap memory management to wheels I don't invent in house.


It's not bottomless, you just cant see the bottom from the surface.


You will never see it completely, because it is full of undefined behavior, and is constantly being excavated to make room for more features.


I'd think about what your goals are.

I'm not aware of a Rust from First Principles book or whether Rust is based on an underlying denotational or formal semantics.

However a good bet is mathematics. And you'd be best served by the typed lambda calculus, predicate calculus, and type theory. If there's one thing I've lamented it was missing out on learning early on in my career it was how to structure computer programs as mathematical objects. I've spent much of my life using the wrong metaphors.


I have to disagree a bit. The point is that rust already feels like being thrown into the deep end of the pool, and all the lambda calc is as deep if not deeper.

My 2 cents: start shallow. The hard part of learning the right stuff from a language is picking a project that let's you run into those aha moments. I like to cut my teeth on a basic Sudoku solver and maybe a small web service for the younger languages. I picked two languages that are relatively simple to pick up, let you get to the meat quickly, and are popular and familiar.

If you don't get pointers yet, learn C. Something with arrays of arrays can be good here.

If you want a taste of some functional idioms without feeling drowned by them, learn Python. Use list comprehensions and filter and reduce a lot to warm up with them.

You can get exposed to a lot of paradigms in Python without committing to anything. Classes/oop, first class functions etc.

C++ is harder than those two because the learning resources are less consistent. Too many idioms have changed over and the last decade.

I think jumping straight into rust after that won't be quite so intimidating. Rust itself has a lot of new things to think about but some are unique enough that there's no good warmup language.


> The point is that rust already feels like being thrown into the deep end of the pool, and all the lambda calc is as deep if not deeper.

I don't think you need an undergraduate degree to understand the un-typed lambda calculus. You can build an intuition for it with syntactic substitution at first. For such a big idea it's really quite simple in practice. That makes it quite beautiful.

Moving to the typed lambda calculus is the next step and builds upon the prior knowledge.

The reason I think it's useful is that it allows you to reason about abstractions -- even complicated ones -- in a manner that reduces the cognitive burden on us. It's also not tied to any single programming language: they can all be modeled with mathematics. Proofs are programs and programs are proofs.

I do agree that a hefty does of practical application helps to solidify theoretical understanding. I see them as informing one another.


Haskell is the obvious answer. Rust is the bastard child of Haskell and C (my two loves).

If one needs cyclic data structures in Rust, the existing theory of functional data structures is a great model for how to solve such problems. Persistent and reference-count-friendly data structures are brothers from different mothers. Haskell enforces pure functionality. Then one can relax and use Rust, and its arcane features will actually come as a relief.


Depends on what you already know. If you've never programmed before, learn python first.


LC3 assembly. It won't seem related at first, but:

- working in ASM forces you to really learn the memory model, even moreso than C

- LC3 is a lot simpler than any real assembly so you'll learn it faster

- LC3 was made for students of programming and has documentation that assumes you're not too familiar with CS already

http://en.wikipedia.org/wiki/LC-3

http://lc3help.com


If you haven't programmed at all, starting with Rust may be tough. It's probably easier to start with Python or Javascript to learn programming.


Standard ML in the U Washington 3 language course is very much like the beginning of the rustbook yet without concerning yourself with any memory management.

I don't recall which part of the course best covered ideas around scopes and their contents that will come up when you start thinking about memory in rust.. but it definitely wouldn't hurt to do all 3 languages.


I assume you are talking about [1]. Fun Fact! Dan Grossman who teaches that specific course below, did a bunch of work on Cyclone [2] that was a major inspiration along with ML, for Rust.

[1] https://courses.cs.washington.edu/courses/cse341/17au/

[2] https://cyclone.thelanguage.org/wiki/Papers/


Just jump into Rust heads on. There's no better alternative if you want to learn Rust.

If you just want low level acces to hardware it might be easier and more useful to learn C/C++. Easier concepts to grasp, more readable syntax and 1000x more avaible resources to learn or libraries to use.


Extend existing systems that you already know (at any level, user, programmer) with Rust. But extend them in the smallest possible ways, and then iterate. You will hit a wall, but you will have a concrete position to work from. Nginx, SQLite, Redis, Postgres, etc.

Don't worry about the borrow checker, liberally apply .clone() every time it complains. Don't try and golf your initial designs. Lots of vec, .clone() and structs that own their contents.


Learn Zig (https://github.com/ziglang/zig). Aims to be lightweight alternative to Rust, similar to how C is lightweight alternative to C++. Both Zig and Rust use LLVM backend and borrow some concepts from the LLVM IR.


Zig is nice. It's the type of programming language I'd write if I didn't want to do anything novel and just wanted to make something a little better than what's out there currently. It's not the future, but it's better than the present.


Thanks for the pointer. I’m interested as well in learning rust.

Unfortunate name though.


Lol why?


I'd guess because of its "decaying" connotations.

I'm personally not a fan of the bang! operator for macros, and the ' lifetime symbol choice. Might seem minor but they just leap out at me for some reason as irritating syntax choices.


“Pointer”

Pun unintended?


I am not skilled enough to make a recommendation but I wanted to say it all depends on your end goal and background. Rust like C and C++ is a general purposr language. I can imagine someone writing not just system apps but webapps and webasm in it(probably done already)


Why not python or Go?

Rust is like Bitcoin, everybody talk about it, but no one really use it.


I think Rust is a great first language to pick up. Pick a domain you are passionate about and start writing code for problems in the domain in Rust.


A bit of C might prime you for understanding Rust's solutions to the the problems old system programming languages have.


If you're new to programming, learning Elm first might be easier.


Rust is overrated. Take a look at D and Chapel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: