9 ms·

>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 functiona

>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.

gcp 10y ago
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.
- rubber_duck 10y ago
  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.
  - gcp 10y ago
    Is it common for code that fits those requirements to require C++ or Rust, though? Particularly in terms of performance?
    - rubber_duck 10y ago
      Depends on the industry, from my experience in gamedev - yes.
- shadowmint 10y ago
  ? 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.
  - gcp 10y ago
    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.)
    - braveo 10y ago
      > 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).
the_af 10y ago
> 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.
- rubber_duck 10y ago
  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.
  - cillian64 10y ago
    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.
    - rubber_duck 10y ago
      >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.
    - tonyedgecombe 10y ago
      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++.
ique 10y ago
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?
- rubber_duck 10y ago
  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.
bpicolo 10y ago
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.
- pka 10y ago
  You can do that perfectly fine even in a pure language like Haskell.
  - omaranto 10y ago
    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.
    - pka 10y ago
      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 :)
crdoconnor 10y ago
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.
- rubber_duck 10y ago
  This makes me hopeful about Rust as well.
- kazagistar 10y ago
  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.
- flukus 10y ago
  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.
vertex-four 10y ago
> 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.
- rubber_duck 10y ago
  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.
  - pcwalton 10y ago
    > 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.
    - AstralStorm 10y ago
the_duke 10y ago
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.
- geodel 10y ago
  > 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.
  - somestag 10y ago
    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.
lmm 10y ago
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.
omouse 10y ago
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).
- Bartweiss 10y ago
  > 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.
sidlls 10y ago
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.).

gcp 10y ago

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.

rubber_duck 10y ago
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.
- gcp 10y ago
  Is it common for code that fits those requirements to require C++ or Rust, though? Particularly in terms of performance?
  - rubber_duck 10y ago
    Depends on the industry, from my experience in gamedev - yes.
shadowmint 10y ago
? 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.
- gcp 10y ago
  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.)
  - braveo 10y ago
    > 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).

the_af 10y ago

> 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.

rubber_duck 10y ago
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.
- cillian64 10y ago
  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.
  - rubber_duck 10y ago
    >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.
  - tonyedgecombe 10y ago
    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++.

ique 10y ago

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?

rubber_duck 10y ago
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.

bpicolo 10y ago

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.

pka 10y ago
You can do that perfectly fine even in a pure language like Haskell.
- omaranto 10y ago
  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.
  - pka 10y ago
    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 :)

crdoconnor 10y ago

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.

rubber_duck 10y ago
This makes me hopeful about Rust as well.
kazagistar 10y ago
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.
flukus 10y ago
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.

vertex-four 10y ago

> 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.

rubber_duck 10y ago
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.
- pcwalton 10y ago
  > 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.
  - AstralStorm 10y ago

the_duke 10y ago

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.

geodel 10y ago
> 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.
- somestag 10y ago
  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.

lmm 10y ago

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.

omouse 10y ago

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).

Bartweiss 10y ago
> 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.

sidlls 10y ago

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.).