Hacker News Reader

Comment by adwhit | Hacker News Reader

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust."

Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. I would urge the author to persevere. In the meantime, the community is very helpful and I'm sure you'll get lots of useful advice on the back of this post.

View on HN

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve.

The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like the article) require the entry API. Multiple mutable pointers into a buffer require either using a typed Vec or Vec#split_off. Cyclic data structures require an Arena or Rc<Refcell<>>. String casting issues sometimes require .map(|x| &x). Global state requires lazy_static. Nice error handling requires error_chain. When you run into problems with "Send" you need a Mutex. The list goes on...

It's like pure lazy functional programming in Haskell in that unlike other languages you can't just pick it up based on previous knowledge and patterns. You need an entirely new toolbox of pure algorithms and data structures, or in this case borrow-safe algorithms and data structures.

> Agreed. Rust is different from other languages in that it is HARD to learn.

Don't you think C/C++ are hard to learn too? C++ has a vast surface area and I think it's unlikely that most people who use it understand much of it. When I code in C, I feel like I have to be paranoid because it's so easy to forget a path that doesn't recover allocated resources. But if I'm not paranoid, I just leak the resources and don't care about it (ever, or until many months or weeks later when the problem's discovered). So the easiness is illusory IMO. It seems to me that all of those other resource leaks are just leaking too slowly for us to discover yet.

> Each project involved tons of compiler fighting that I now know how to avoid or solve.

As frustrating as it is, it's easier than struggling with heisenbugs. Those can easily eat up days trying to reproduce issues.

I think it's easier to get started with C++ because it contains simpler languages. You don't have to start with template metaprogramming, you can be productive with a small subset of C++.

C++ is hard, but C is about the simplest language in modern use.

The issues and solutions you list sound super valuable. Do you know if there is a write up about those issues somewhere or did you just learn through blood and sweat?

Learning Rust With Entirely Too Many Linked Lists (http://cglab.ca/~abeinges/blah/too-many-lists/book/) is the best resource I've found for learning how to create data structures in Rust. It goes over a lot of the pain points of interacting with cyclic data structures.

Thank you for this pointer!

  > Cyclic data structures require an Arena or Rc<Refcell<>>.

Is there a way of creating a cyclic data structure that doesn't involve these types?

I ask because I used the latter recently, after struggling to create lifetimes that were acceptable to the compiler. I only found it when I searched for 'cyclic data structures rust' on Google.

It would have been much nicer if the compiler could have noticed that I was trying to create a cyclic data structure and then have informed me on the different ways of doing so. Perhaps a misunderstanding on my behalf, but the error messages that I previously received felt like they were sending me on a wild goose chase.

I still don't think writing Rust code is hard, but there are definitely improvements which could be made to the compiler error messages.

You could use id/vec indices, instead of directly pointing to your e.g. sucessors: "struct Node { successors: Vec<usize> }". This has the obvious disadvantage that deleting nodes is quite hard though.

> This has the obvious disadvantage that deleting nodes is quite hard though

It's hard because now you're in charge of building a malloc(3) implementation. Depending how important this data structure is you might need to worry about 1. about fragmentation 2. free space managment 3. adjacency and cache effects

So you've traded on hard problem for another hard problem. Not something I'd call a win.

Just use petgraph. It manages all of this for you.

I work on databases and I ran into similar problems implementing index data structures. While I understand petgraph solves some/all of these problems completely - it would be great if the barrier to writing trees / graphs from scratch in Rust would be lower than it is currently.

Same problem. Working on an OLAP database toolkit (tried to in Rust)... writing typical database data structures is excruciating painful in Rust.

Trees, indexes (including bitmaps), buffer allocators and even just keeping state in streaming cursors (Volcano model). Are all pain in the ass in to implement.

In fact implementing a Cursor trait for like 10 different Cursor (SrcView, Join, Project, Compute, ...) became painful because each cursor struct has it's own complex lifetime params and those lifetimes were trying to leak into the main Cursor trait.

Right now I can't do that without resolving to runtime using RefCell. In my case the plans could be entirely materialized at compile time, so not really a win.

The situation won't get better until there's some kind of abstraction over lifetimes (HKT?).

Sure, I wouldn't recommend that solution if you have to delete single nodes a lot. But it is quite convenient if you don't need to do that.

Are these strategies for solving borrow checker issues documented anywhere? Sounds like a case for which a best-practice reference would be golden.

I wrote http://manishearth.github.io/blog/2015/05/27/wrapper-types-i... which explains the primitives that can be composed together to do things like this.

> Agreed. Rust is different from other languages in that it is HARD to learn

But do you learn to code in a different paradigm where you don't struggle by iterating on a compilable and runnable piece of code, but rather struggle on iterating on a non-compilable piece of code and "once it compiles, it works"?

Definitely and I'd say the struggle is only there for the first couple of weeks.

This will get shorter as tooling gets better this year.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular.

This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you.

Hybrid functional languages got adopted in the meantime (F#/Scala/Clojure come to mind) and a lot of FP was adopted by OO languages - it wasn't pure or fancy but it solved problems in an accessible way. Most people still don't use Haskell.

I'm hoping Rust doesn't go down this path as I want a replacement for C++ badly. But saying "you need to spend a few months to get intimately acquainted with the language" is just not going to work in practice if you're hoping about breaking in to the mainstream.

I'm hoping Rust doesn't go down this path as I want a replacement for C++ badly.

So that's opposed to C++'s "It takes a few years to get acquainted to the language enough that people would want your stuff in production code"?

Nobody hires junior C++ programmers.

The problem with writing C++ is not so much the language as it is the problem domain - writing C++ as "C with some syntax sugar" is possible and a popular method by people who don't care about C++ complexity. And it gets you to results fast. Having something work right away and deal with the edge cases when you encounter them is preferable in a lot of scenarios - especially while learning, but also as a principle of iterative development, a lot of the time as you're iterating on code stuff fundamentally changes (requirements change, your interpretation changes, etc.) all that formalization up front ends up being an impediment - as much as it makes some people uncomfortable.

Is it common for code that fits those requirements to require C++ or Rust, though? Particularly in terms of performance?

Depends on the industry, from my experience in gamedev - yes.

? What's your point.

The parent post specific said it wanted a replacement for C++; the amount of time and effort it takes to get code right in C++ is a problem.

Rust also has a long learning curve, and its hard to quickly be productive in.

I don't think there's anything wrong with idly wishing there was some kind of middle ground where you could gradually or partially opt-in to the borrow checker with a nice modern language like rust to get started, and then gradually eliminate your GC parts or whatever.

Many game engines use a high level language with a GC like C# or (shudder) python or blueprint which are baked by C++ for the performance critical parts.

You write application logic in the scripting language, and anything that's too complex you fall back to C++ for.

If rust could somehow self host itself as a high level language like that, it would be superb.

My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust.

It may stop Rust from getting widespread adoption, but I see no problem with that. C++ isn't "widely used" either by most meanings. Rust may still largely replace C++ even without magically having a less steep learning curve. (Which it, IMHO, actually has anyway.)

> My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust.

As someone who learned C++ first and later Rust, no it isn't. Rust's learning curve is a hell of a lot higher than C++'s.

This reminds me of when Java was trying to compete with C++, you would have all these Java people making claims that HotSpot was going to take over the world and make Java faster than C/C++. Only it never happened outside of a few specific cases because these people were "fanboys" in every sense of the word.

You like Rust, there's nothing wrong with that. You think it's better than C++, that's your belief and I'll defend your right to believe it.

But stop comparing it to C++. Just about every language over the past 20 years has users do the same thing and __C++ IS STILL KING__.

You can push rust without being unfair to C++ (NO WAY is C++ harder to learn than Rust).

> (NO WAY is C++ harder to learn than Rust)

Depends on what you mean. Writing good, safe, C++? Quite hard. Debatably harder than Rust, but it's debatable, not an absolute statement.

The difference is that C and C++ let you write things like doubly linked lists in day 1 of learning them, whereas Rust won't. But a good doubly linked list is tricky to get right anyway.

I learned C++ first too, and I think I have a handle on "safe" C++ practices, but it's mostly a nebulous set of conventions that shift in the particulars based on the codebase. OTOH in Rust I'm immensely productive even in random codebases.

Most of the cognitive overhead of Rust exists in C++ too, since you still need to reason about how your data is shared, just that C++ spreads the cost out over the learning curve, whereas in Rust you have to deal with it up front.

NO WAY is C++ harder to learn than Rust

I've been programming C++ for 16 years, it's the main language at my day job, and I won't even begin to think I understand templates. But you'll see codebases that use it regularly. Const correctness? rvalue vs lvalue? ODR? SFINAE? RVO? exception safe code? template argument deduction? Then you have C++11, C++14, C++17...

Despite this, I still regularly write code that has memory, string, concurrency and bounds bugs. So does everyone else in the industry, including smarter people with more experience.

It's possible that the parts of Rust I'm not familiar with (e.g. unsafe code, macro system) turn out to be similar sinkholes, but so far, that doesn't seem to be the case.

> Rust's learning curve is a hell of a lot higher than C++'s

I had the exact opposite experience, i.e. Rust allows me to not worry about memory safety and allows me to think on a much closer level of abstraction to my problem domain than C++.

using != learning.

If you just want to write code that runs but that will suddenly break without warning an unknowable time into the future, then C++ has a lower learning curve. If you want to code defensively and write software that isn't going to eat your laundry, then the learning curve for C++ surpasses Rust in steepness, because of the sheer number of things you have to learn not to do.

No student in any language learns by writing production ready code.

Anyone who thinks this is what it means to learn a language is attacking a strawman.

No strawman here. It's incorrect to believe that the process of learning a language has necessarily ended by the time that someone has begun putting code into production.

> No student in any language learns by writing production ready code.

OTOH, many students of programming languages learn by pushing their code (EDIT: ready or not) into production. Oh boy do they learn.

Worked for me when learning Go.

I think that says more about your idea of production ready code than it does the issue under discussion.

I didn't know a many useful "Goisms" at the time, but it was certainly code that didn't need drastic refactoring. I just picked up the language basics in a day, and 3 days later I was effectively writing code that I might certainly write better today, but it was functional, extensible and fault-tolerant.

> You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you.

In order to just use Haskell you don't need to meditate about category theory at all.

Some things do require months -- or even years -- of studying. Like, for example, C++, Java or whatever was your first programming language. There is absolutely no getting around that.

Yes but going from one to the other is relatively straightforward and possible in small steps of progression - Rust forces you to deal with a lot of things up front which is why people complain. eg. if you're a C++ developer you'll pick up Java very fast, it will take a while to be super productive but you can start working really fast.

That's because a lot of things (let's not debate exactly how many here) translate well between C++ and Java. But my point wasn't about going between relatively similar languages; it was about learning something radically different for the first time, like it was when you learned your first programming language.

But that's not going to work in practice - there are many skilled C++ devs and C++ has many ingrained legacy issues which another systems programming language could solve - but the bridge between that language and C++ must exist for this to happen. Like in the post, OP is a competent programmer - he can solve his problem in C++ - why would he invest months in to Rust to do the same thing ? If your answer is safety then OK that will matter to some but a lot of people don't care enough about it to pay the cost of switching.

Safety and correctness are big deals. I get that for many people they aren't a high priority. Such is life.

If someone thinks they won't gain anything by going from C++ to Rust, then no effort to learn it will be worth it. Obviously the Rust devs think there is a benefit.

C++ and Java are a bad example as they are unusually similar. Consider moving between C++, Python, and Javascript: on that scale, Rust doesn't seem so far out.

>Consider moving between C++, Python, and Javascript

I think those will be trivial in that direction, harder in other - but that's not even relevant. I think if Rust aims to occupy C++ domain then it needs to be very easy to get C++ developers on board - and from what I've seen so far it's not quite the case. I'm not sure what can be done about it tho - maybe emphasize unsafe is not a dirty word but a valid approach when doing low level data structure stuff like OP ? Create an unsafe version -> refactor to safe as you're sure it does what you expect and you learn more about borrow checker instead of having to absorb it all at once.

I doubt moving from Java to C++ would be that trivial, Java is a comparatively safe language without many of the issues that will trip you up in C++.

From personal experience, it's not that bad. C++ is "Java plus you need to worry about these other things", and it pays off in power and speed. They're not so similar in safety/scope terms, but the structure and design have enough in common that you get plenty of spare brainpower to worry about managing C++.

It was, for instance, a way more natural transition than "Java and C++ to OCaml". Less educational, but as usual that trades against easy.

In particular, the lack of pointers in Java would probably annoy the article author as much as Rust does.

Personally (not the author) I am more annoyed by the gutted single inheritance no traits type system.

You have numeric pointers into arrays, they're called indices.

> or whatever was your first programming language.

People who complain about how difficult rust is to learn certainly aren't learning rust as their first programming language.

That's my point. I think people complaining that Rust (or Haskell, or whichever paradigm shift) "takes too long to learn" have forgotten what it was to learn their first language. It took them long, because some things take long. Learning something different takes time, but it's easy to forget this once you have a couple of languages under your belt.

> I think people complaining that Rust (or Haskell, or whichever paradigm shift) "takes too long to learn" have forgotten what it was to learn their first language

Because they are required to be productive fast. A professional usually doesn't learn a new language just for the sake of it. If the language doesn't yield instant benefits then most people aren't going to bother learning it.

If a steep learning curve is expected for rust then the language will never be popular around the people who could potentially make use of it, i.e. C or C++ developers.

C++ has a pretty steep learning curve, yet people use it.

Many things in tech are tradeoffs. Sometimes the additional tools a language brings to the table are worth the learning curve, sometimes they aren't. There are people in the industry for which FP (or Rust, or whatever) is worth it. For you it isn't. That's life.

> C++ has a pretty steep learning curve, yet people use it.

C++ has 30+ years of libraries, so does C. To even think you can compare Rust and C/C++ on that matter is not realistic.

I think that OP's point is that Haskell or Rust introduce enough of a different paradigm that it is worth thinking about them anew, rather than trying to map your old programming language knowledge to Rust or Haskell directly.

Then why even bother learning a new language if you have to deliver something fast and you know one already?

I think the problems with Haskell are quite different than the ones with Rust.

Haskell suffers more from being a research playground, bad documentation for both the language and it's libraries, confronting you with many unusual concepts (type theory, monads, laziness,...) and, as a pretty old language, a lot of legacy cruft that makes a lot of things awkward (string handling is the prime example).

Rust wants to be a widely used language and while it has some aspects that are not trivial and quite often make it verbose and awkward, in reality it's not really that different from, let's say C++, apart from the borrow checker and lack of classes.

I don't think much will change about Haskell, but I have hope for Rust that it will steadily improve.

> Rust wants to be a widely used language

I am sure they want that. But so many responses of Rust enthusiasts to any article/blog less than flattering get very aggressive. May be Steve Jobs got away with 'You're holding it wrong' but I doubt incoming users for Rust will be this kind.

The aggressiveness is unfortunate (and counterproductive), but comes from the understandable perspective that too much bad press could kill the language before it even gets off the ground.

The Rust thesis is: "You should care about all these things you don't currently care about, and Rust helps (makes) you care about them." In order to enjoy Rust, you need to thoroughly buy in to that idea. Any significant deviation from that thesis defeats the very purpose of the language.

But of course most people aren't going to buy in, because it's an idea predicated on making their lives harder (in the short term) than it currently is. Rustaceans believe the long term benefits are massive, but new users cannot possibly believe that except by taking it on faith. This creates a conflict. The Rustaceans need everyone to give the language faith over an extended period of time, and anyone giving up their faith after a short trial not only drops out of the ecosystem themselves, but possibly damages the faith of others. That's a huge problem, because Rustaceans are hoping their language will one day take over a significant portion of the systems/embedded development space. That can't happen if people sour on the language so quickly. So when Rustaceans see someone slam their language with giving it an "honest try," they get upset because the damage done is palpable.

Of course, that's the wrong strategy, as it just drives people further away from the language. The right approach is to be inhumanly kind and accepting so that the frustrations are counterbalanced by support. The good news is that the Rust community at large seems to be quite nice; it's just the angry ones that show up in blog comments.

Honestly, Hacker News is too general to base your opinion of the "Rust community" on, try #rust-beginners on irc.mozilla.org or users.rust-lang.org and I think you'll find one of the most welcoming communities on the internet.

When the blub programmers look up the ladder, they see a bunch of type theory, monads, and laziness. They don't see the use for these features as they think in blub.

If you tried to teach basic arithmetic in elementary school by means of axiomatic set theory, you'd put entire generations of people off of math. It is not a virtue to require people to take the hardest path to a concept in the name of purity, and it is certainly not a virtue to be condescending in the failure of others to do so.

Take as an example call/cc. If I tried to explain that to a--as you put it--blub programmer, I would probably get glazed eyes in response. If I instead tried to explain it via means of a yield operator (à la Python), I would much more likely get someone who could think of use cases where they would want to use it in their own code. The limitations are not in the blub programmer, it's in the teacher for assuming that blub programmers are incapable of learning hard concepts.

The type system in Haskell and other ML family languages is incredibly powerful, but it takes a long time for most to intuitively grasp functors, monads, monad transformers,...

It's a huge entry barrier.

Exactly what I rail against in Rust. What do you see when you toss a coin friendo?

The clincher for me with respect to rust is that I see a steady stream of useful software being developed in it.

I never really saw that in Haskell and I've heard people talking about it for at least 15 years. That indicates that something is missing.

There is some pretty damn useful software written in haskell. For example, I started using Pandoc long before I knew it was written in Haskell, and for me, it still dwarfs the utility of any specific tool made in Rust. That said, Haskell had a lot longer to get there, so Rust is still moving a lot faster on that front.

It's been the same with lisp for 40/50 years. A lot of evangelists but not a lot of people doing useful things with it. Rails did more for FP than lisp evangelists ever did.

This makes me hopeful about Rust as well.

F# and Scala are halfway to Haskell - maybe 3/4 of the way even - compared to the languages that were popular at the time (and the more experienced people get the more Haskelly their code tends to become). Hell, those popular languages are about 1/3 of the way to Haskell now. Any serious language these days has lambdas, map/reduce/filter, and type inference; most have list comprehensions and pattern-matching.

You're right that there needs to be a path up to there though. The reason Scala really worked for me is that it let me make my way up to a very Haskell-like style while remaining productive every step of the way.

All the "hard" things a user learns in Rust have to be learned in C++, too. It's just some things are learned in a different way in Rust (e.g. fighting with the borrow checker) than they would be in C++ (e.g. proper use of const(expr), references, moves, etc.).

To get any programming done, you have to learn certain things, you can't complain that it takes weeks to learn a new programming language and months to assimilate it's model of thinking.

But saying "you need to spend a few months to get intimately acquainted with the language" is just not going to work in practice if you're hoping about breaking in to the mainstream.

You mean it's okay for everyone to struggle to work with JavaScript for years and years trying to come up with an OO system and a module system and trying to just bundle the files for the browser, but it's not okay to spend months on getting intimately acquainted with the language?

Who cares if Rust becomes mainstream, we only need the best open source code to use it (like Firefox and the other C/C++ libs that are thinking of porting over). We don't need it to be mainstream, we just need it to be possible to learn it within a reasonable timeframe (less than a year).

> You mean it's okay for everyone to struggle to work with JavaScript for years and years trying to come up with an OO system and a module system and trying to just bundle the files for the browser, but it's not okay to spend months on getting intimately acquainted with the language?

You're saying that like those things are a contrast, not two incarnations of the same issue. Safe-and-usable is the holy grail for exactly this reason - right now we have usable-but-unsafe. Javascript isn't a few months to get acquainted: it's a few days to get passable results and a lifetime to get good ones.

So there's a huge need for a better mainstream tool, because the alternative is letting the existing ones endure. That doesn't have to be Rust - there's plenty of space for languages that are hard, but good for key applications like safe browsers. But it has to be something - lecturing people doesn't actually reduce reliance on easy-to-learn, hard-to-secure options.

> You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you.

Luckily, Rust's community is much more pragmatic - but their goals are still to create something substantially different from existing languages because existing languages are not enough to guarantee what Rust guarantees.

Yea that's what I see as an issue as well, I was hoping it wouldn't be but the deeper I go in to Rust the more it shows up. On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense, this would let you avoid "pushing square pegs in to round holes" solutions when the borrow checker doesn't capture your problem nicely, and it would be trivial for C++ devs to get on board.

On the other hand this defeats the goal of the language - being as safe as possible - because their domain is very sensitive to memory safety issues (browser) - promoting an ecosystem of unsafe libraries wrapped in safe facades would be against their goals.

So I guess right now, because of it's design decisions, Rust isn't simply an upgrade to C++ which I want but more of a language that took different trade-offs to solve specific problems. It remains to be seen if it's worth taking those trade-offs to be rid of C++ legacy garbage.

> On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense

I have pushed this several times in the past, but there's always been a lot of resistance to the idea. Though I've always phrased it as "let's allow the safety checks to be turned off", which isn't necessarily the best phrasing...

I wonder if it'd be better to just push to make unsafe easier to use: add sugar for ptr::offset, add a -> operator, relax the restrictions on casts, and so on. When I do OpenGL programming in Rust I drop into unsafe quite regularly, and it feels just like C, except for some annoying papercuts. It'd be nice to get rid of those papercuts.

Or better extend the language to allow making code partially safe in many ways. This would make the wrappers much better.

Make it easy to reason about useful kinds of partial safety. Make it easier to define properties of external systems that Rust does not control.

Can you elaborate this into a concrete proposal?

There might be an easy solution, they could provide more flexibility on using safety features, kind of like Perl did it, i.e. let anyone disable/enable a particular strict feature for a particular scope, for example "no borrowcheck;" or something. This will make it easier and more flexible for everyone, newcomers will be able to gradually learn more about the language and still get things done in the meantime, and power users will understand where satisfying the compiler is not worth it and will be more productive as a result without worrying about overly broad unsafe.

They have that with the "unsafe" blocks but like I said promoting it as something you should use when things don't fit borrow-checker goes against their primary goal of making things safe. I guess there are two camps, one that wants compile time safety guarantees - those people made Rust, and the other wants a C++ replacement with modern tooling and no legacy garbage - those are looking at Rust and getting discouraged by safety trade offs they are paying but not really caring for - and every Rust tutorial I've seen focuses on hammering this aspect instead of going "OK here is the equivalent of this C++ code with unsafe code - you now get a sane build system, package manager, modules, fancy syntax. Now if you want here's how to make it safe."

You're almost certainly not looking for Rust if you don't want your language to prevent a vast variety of bugs, and instead want something that allows and encourages you to design systems which make it easy to shoot yourself in the foot (which all C++ codebases I've ever seen have grown). I don't think language developers are interested in making such a language in general, as it's not interesting - you'd just be rehashing ideas from multiple decades ago with new syntax, and not making anything particularly easier to do.

>and not making anything particularly easier to do

Have you used C++ in the real world ? Dealt with it's insane build systems, build times, obscure semantics, etc. ? Not to mention there's nothing close to a sane package manager.

There's plenty of value of just rehashing the lessons learned in last 20 years of language design to a systems language.

    I don't think language developers are interested in making
    such a language in general...

https://inductive.no/jai/

I'd argue go came from a desire to have a language that was completely uninteresting in terms of 'interesting ideas', and really just exists to Get Stuff Done.

I think more people are interested in that sort of thing than you imagine. Clearly.

Jai is designed on a bunch of false assumptions, which makes it hard to get excited about.

Or more precisely, the designer of Jai uses C++ as "C with classes" and then goes from that, which isn't fair. He also misrepresented a few things in regards to Rust, which he doesn't even know, but comments on etc. etc.

As I understand it, you can't disable just borrow checker somewhere where you don't need it.

It's subtle. Unsafe Rust is a superset of safe Rust; that is, all valid safe Rust code is valid unsafe Rust code.

  fn foo() {
      unsafe {
          let x = &5; // this is still going to get borrow checked
      }
  }

Since it's a superset, it gives you access to new tools, that don't interact with the borrow checker, rather than "turning the borrow checker off".

  fn foo() {
      unsafe {
          let x = *const 5; // this is not going to get borrow checked
      }
  }

(*const is not valid syntax: the way to not-borrow something is to coerce/cast it to an unsafe pointer within the statement, so that the borrow ends at the ;, e.g. give x an explicit raw pointer type in the first example.)

gah, i always mess this up, haha

So you're saying it's perfectly feasible to become an expert C++ programmer over a weekend, but it's completely impossible to learn Haskell?

OP says he's a C# programmer and doing the solution in C++ was straightforward and he had the time to test it + look for C++ patterns.

First weeks in Haskell as an average joe programmer you'll spend getting your brain wrapped around lazy eval being the default.

I'm a big fan of hybrid functionals. I think being able to fall back to somewhat imperative code makes sense on occasion. Some things are better expressed in either paradigm, and that's OK.

You can do that perfectly fine even in a pure language like Haskell.

Or maybe Haskell is also a hybrid? I know about the type theoretic accounting tricks used to stay pure, but when I really need unboxed mutable arrays and several tight loops, I just use the ST monad and write code that is psychologically completely imperative. And it compiles to pretty fast executables too, especially using the LLVM backend.

Yeah, that's what I meant.

You can't tell from the type signature alone if a pure function uses ST though, so I'd say that counts as pure :)

Exactly. The fact that rust is easier than most low level languages made the high level language crowd forget than bare metal programming IS HARD. Try to do a big project in C++ or C and you'll see that making something that is production worthy takes months.

Besides, as a Python trainer I can make you productive in it in a few days. But it will still take a lot of time for you to be good at it. The only difference with rust is that the first "reward stimuli" comes later down the road because you need to be better at it than at Python to make use of it.

> It takes months of steady investment (and yes, frustration), but the payoffs are spectacular.

In my experience, most developers can't or won't put in this sort of investment. Which leads me to wonder what fields/niches will Rust land in?

This might change if, as other commenters have stated, it is taught as a first or second language, but that doesn't seem likely anytime soon...

Rust's niche seems very clear: C++ programmers that need better tools. This is an audience that should be willing to make a time investment, and understands the trade-off, for the most part.

I disagree to some extent, for a couple of reasons.

First, C++ programmers in aggregate have to consider more than the choice of language for their projects. Odds are they work for somebody else, on a team, an established project, whatever. In these cases "C++ programmers need better tools" doesn't mean "toss the bath out with the water." Rust isn't necessarily a good move in established products, in other words.

Second, Rust would do better, in my opinion, to target folks who are new to systems programming and, for whatever (mostly invalid, in my opinion) reasons, are intimidated by C or C++. Rust is very powerful and in many ways I like it much better than C++. I think Rust offers a great way for these people to have a gentle introduction to the world of systems programming. I say "gentle" because a good portion of the "pain" of learning is front-loaded into getting a build, rather than back-loaded into futzing about with gdb (although that would be something these folks will miss out on--who doesn't like a good session with gdb with a satisfying bug squash at the end?). Get them while they're young, as they say.

I don't disagree - my statement was also directed to people new to this field.

The overhead for existing C++ teams is learning the language, and (potentially AFAIK) interfacing with C++ code that has no good C style API. But Rust seems to tackle even the latter quite well. I don't think you'll get around the learning curve for a new language.

> it is taught as a first or second language

This is interesting. Many universities teach Java, C, C++ or Python as a first language. The headache that many first year students suffer from these basic (relatively speaking) languages is readily apparent. Rust is very strict, and it requires an entirely different mindset to use. I wonder how this would fare with students who have a clean slate.

> I wonder how this would fare with students who have a clean slate.

I suspect that the % of students who have difficulties won't be much different, overall. There may be a different distribution of when they run into trouble.

The interesting question is whether the group of students who have problems with other first programming languages is different from the group that have problems with Rust-as-a-first-language...

Yeah, I've seen a number of posts like this for go as well. I wonder if it may be useful to start programming in these languages with a more experienced buddy to ask questions if and do some coffee reviews, to reduce time spent banging one's head on the keyboard, and get better acquainted with the language's idioms.

I never wrote a single line of rust, but when a language is hard to learn, the compiler error messages are probably just bad in terms of comprehensibility and offer the user no direct solution.

    when a language is hard to learn, the compiler error 
    messages are probably just bad in terms of 
    comprehensibility and offer the user no direct solution.

I don't want to sound snarky but Rust really does have amazing error messages, and they literally do offer direct solutions/suggestions using literal examples and raw samples of your source code.

It even offers the `rustc --explain EXXXX` (where XXXX is an error code) that give an in terminal deep dive + examples on why this is an error/how it is failing.

    I never wrote a single line of rust

So what do you think, why is it so hard to learn rust, if it is not about the compiler messages?

Reply on news.ycombinator.com