Yes Rust is significantly harder than go. It's diametrically opposite if there was a circle of complexity.

I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.

The ownership model makes sense to me but if I had to grok manual memory management and rust abstractions on top of it at the same time I think I would be unable to contribute even trivial stuff for a month.

Oh and coming from a dynamic language background at that ?

Not saying can't be done just saying time till contributing is probably weeks-months.

With go it's probably days.

> I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.

In my personal experience you do this by writing your programs in such a way as not to require complex ownership. I had an easy time writing web services where the only cross-request shared state was a database handle. I had a hard time when I had to write a websocket document sync serverwhere I needed per-document global state shared between all the handlers, and I eventually gave up and moved to a model where a language with an easier concurrency story called rust code.

This. Implementing an http endpoint is pretty straightforward. Newcomers may struggle with copy vs reference semantics (and that just takes time), but otherwise it's not too different from other statically typed http work. You define your input/output structs, you grab a database connection, you perform a query, and return it. No lifetimes. No Arcs or Mutexes or Rc or RefCell.

We generally consider our rust backend as two parts: application code and library code. We intend for our application code to be approachable by full stack developers and not require deep rust expertise to use. Our library code can be a bit more complicated, and there we see a bigger ramp up and frankly some self selection among our team and that's fine.

> I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.

I started by reading the Rust Book. It explains most of the low-level concepts. It took me about a week of mostly just learning and experimenting, and another ~3 weeks until I had an MVP of my system. But from there it was just another 2 months until I had a full system written and in production, which it would probably have taken in another language anyway (as the project involved a lot of trial and error reversing a (simple but) only partially documented format).

Perhaps it helps that I came from JavaScript where a lot of the abstractions are similar.

Curious what modern schools teach in Computer Science programs. I went to Salisbury State University 17 years ago, and we had classes on assembly language, system programming and operating systems where we used C, algorithms classes with assignments in C++, computer graphics, which of course also C++. My professional experience working in industry was primarily in Java, but also some C, Python, Ruby. Learning Rust was not without a challenge, but having a lot of programming in C/C++ in school more than 10 years ago helped a lot. My assumption that all software engineers who have university degree should have some experience in system programming.

At my university the language used for teaching was predominantly Java, with Python or C# used in some papers.

There was an optional operating systems paper which had you writing some assembly to run on an in-house RISC system [1], but a small % of CS+SE students took that paper.

I think they’re trending towards using Python for most papers now. Not unreasonable for a paper on data mining or web development, but there’s definitely something being lost where students don’t /need/ to understand how the computer’s working in order to get a passing grade, so there’s no real incentive to dig deeper for the average student.

[1] https://wramp.wand.nz/

The University I work for teaches Java in Programming I (the mandatory introductory language) for Computer Scientists, and teaches them some C in Programming II and then a functional language, typically Haskell, and potentially some Rust, Typescript, whatever by the third year as some of the students will be pursuing Theory. The Electronics students learn C at the beginning meanwhile. Students elsewhere in the university learn mostly Python and R.

>I honestly have no clue how someone without low level experience (eg. never did systems level programming) even approaches Rust.

Far easier than the way anyone without low level experience (which meant almost everybody starting out) approached learning C and C+, back when Java, C#, Python, Perl etc were not yet a thing, and you got either got directly into C/C++ or started with PASCAL and BASIC if you were lucky. Oh, and no IDES, internet, stack overflow, or forums either...

I mean I wouldn't recommend anyone do that either. Doubt you'll find many C++ roles taking people without experience either.

Go is garbage collected. It is significantly easier to write than Rust --- it's not just easier to learn, but easier for experts to write, because it's doing a bunch of work for the developer that Rust doesn't.

On the other hand, if you need manual memory management (for performance reasons, or because you're doing something bare-metal), you'll be fighting Go's garbage collector, and Rust has conveniences for manual memory management that Go doesn't.

Go is quite arguably a worse language though, including certain fundamental cornerstones of modern web development. Ever tried to see what fields a JSON payload contains in an "idiomatic" way before casting it to a type in Go? It's all interface{} (now Any) and reflection. If we're talking about developers new to a language, I'd argue that Rust's type system is easier to grok than the cases you may need to account for in Go.

I'm not interested in the language war. It's just the case that Rust is both more difficult to learn --- especially if you've never worked in an unmanaged runtime before --- and more difficult to write. Which language is "better" is undecidable.

Harder than C++? Harder to use than C?

Above is a question, not a snark. I like learning languages and haven’t dabbled in Rust so am curious.

C++ vs. Rust is a tricky question. C++ is easier to write in, but it's harder to get programs working in it. Rust is harder to write, but it's much more likely that your first execution is going to do something useful. But they're of comparable complexity.

Second this. Rust also follows some habits of C++ like verbose syntax and accidental complexity. There was an article recently where a Rust port of a C++ application ended up being comparable in lines of code.

There's a sense in which people are saying it's easier to learn other languages than Rust because it's easier to get to code that compiles so you can start building new features.

There's a different sense that I feel is being overlooked by those people in that the problems you run into with Rust are frequently actual flaws or bugs in your code, and the compiler shouldn't be thought of an adversary blocking your way to feature development but a teacher showing you the things you're overlooking. So once you put in the upfront cost of learning how to write Rust that compiles, you get code that's much more maintainable, correct, and easy to refactor.

So for someone that likes learning languages, I'd say choosing to learn Rust is a great choice and will teach you things you can take with you to other languages.

I'm sure this is true for some people, but I found in Go their "Don't Be Clever" just drove me nuts. There's a thin layer where it's fine, and then once you get beyond that your options are Be Clever (Nope, Go tells you not to even try) or Give Up, I gave up.

Whereas in Rust I was able to keep going. Sometimes, when I dug down I reached something truly enlightening like the implementation of core::mem::drop -- pub fn drop<T>(_x: T) { }

[ Yes I said implementation, that's not a typo, that's the actual implementation. ]

Sometimes, it's all fucking turtles, e.g. Aria's famous "Pre-pooping your pants" essay and her "Tower of Weakenings". There's bad news, but if you don't like that we also have more and different bad news.

And sometimes it was a voyage of discovery, but it was an interesting voyage, I learned much and I felt invigorated and encouraged. For example why C++ std::vector's reserve is not Rust's Vec::reserve but Vec::reserve_exact or why Rust's functions each have unique unnameable types, or how MaybeUninit actually works.

I have no trouble believing that there are programmers who enjoy writing Rust more than they enjoy Go, and many of those programmers are probably faster when they're not being irritated by the language they're working in. But I simply don't buy arguments that Rust is easier to pick up, or even as easy. Go is a garbage collected, managed runtime. Rust is in some ways harder to write than C++.

The very last thing I'm here to do is to advocate for Go over Rust, or vice versa. But there are some basic facts about the languages we should be able to recognize, without falling into a bottomless pit of language war. Rust is more complicated than Go, and it's that way for a reason: you can readily use Rust in problem domains that don't admit Go.

It does feel like it ought to be true - like you said, there's a garbage collector, surely it'd be easier?

But alas, Go's quest to avoid being clever often means that when the simplest thing would be too clever that must be avoided. If you are implementing Go this is presumably a great convenience, but I'm not implementing Go, I was just trying to write software.

Rust and Go agree that 1 == 1 and 5.26 == 5.26 and "New York" == "New York", but then Go wimps out. Rust has no problem if we should like to use this equality operator on arrays of integers, or slices of booleans, or for that matter HashMaps of HashSets of Vecs of Strings, but that's all too Clever for Go, so in Go we must use extra functions like reflect.DeepEqual.

Rust and Go both agree there's fundamentally only one loop. But, they disagree on what that fundamental loop is. Rust's fundamental loop is named "loop". It just loops, forever, it's a loop. Go's idea of a fundamental loop is a variation on C's for loop it uh, well it has two statements, plus a boolean expression, the expression is tested before each iteration and the first statement happens once, but the other statement happens after each subsequent iteration. That... doesn't seem simpler. I'm not sure what their excuse was here, is an infinite loop too Clever ?

There are a few more like this. Unsafe Rust is definitely way more complicated, but one of the less obvious benefits of that keyword is that it tells beginners what they don't need to know about. Ah, this is marked unsafe, I'm a beginner, no need to explore that yet.

Probably you can argue that the need to teach 'lifetimes undoes all this benefit and that's still safe Rust. It's a position I don't have hard data to refute, just my personal experience, for whatever that's worth.

If you're just looking for field names (keys), what's wrong with map[string]interface{}?

Maybe I'm missing some key context, but I've never reached for reflection in the scenario you've described.