From: no.email@nospam.invalid   
      
   Hans Bezemer  writes:   
   > If you think you will revive Forth by jumping on that Rust bandwagon,   
   > I think you're wrong.   
      
   Probably true, Forth users want something different than what Rust aims   
   to supply.   
      
   > First and foremost, because I think Rust is the wrong idea. It's been   
   > tried before - Ada, Pascal, Java - in some sense: BASIC.   
      
   BASIC's heyday was before my time, but it was very popular in a certain   
   crowd.  Java was extremely successful in industry and I think it was at   
   the top of TIOBE for a while (it is #4 now).  #1 is currently Python   
   which can be seen as a successor to BASIC.  Pascal was intentionally   
   limited (it was intended as an instructional language) and yet it had   
   its own era of popularity because of Turbo Pascal and the P-system.   
      
   Ada was overcomplicated, but I think it also didn't gain traction   
   because the early Ada compilers were slow and expensive.  If GNAT had   
   been available from the beginning, Ada would have gotten more use, imho.   
      
   > Good programmers exist because they are good programmers. Bad programs   
   > exist because of bad programmers.   
      
   The best programmers I know have released code with memory errors, so at   
   a certain point you have to stop blaming the human for being less   
   accurate than a machine.   
      
      
   > "Ada will not meet its major objective... for it is so complicated   
   > that it defies the unambiguous definition that is essential for these   
   > purposes.   
      
   It's not particularly more complicated than C++ as far as I can tell,   
   and C++ is currently #3 on TIOBE.   
      
   > "...for it is so complicated...". That is the very definition of Rust.   
      
   > All the time you're spending getting your code to compile, you're not   
   > creating programs.   
      
   Would you say the same of time you spend fixing bugs that you find   
   during testing?   
      
   > I'd say that's the reverse of productivity. The higher the   
   > abstraction, the more difficult it is to understand - let alone to   
   > teach.   
      
   Picking the right level of abstraction to handle a problem is an   
   important skill in programming just like it is in math.  We spend a lot   
   of time studying abstractions in math because they are useful.  That   
   turns out to be true in programming as well.   
      
   > Lifetimes? Borrowing? Are you kidding me?   
      
   This is just the language handling and checking an abstraction that   
   people have been doing manually long before Rust.  If you look at the   
   CPython implementation, it does memory management by reference counting,   
   and it constantly uses the ideas of borrowed references internally.   
      
   I would say today though, most application programmers don't need Rust.   
   They will be more productive with garbage collected languages, at the   
   expense of some machine resources.  Rust is for when those resources   
   can't be spared.   
      
   > So, safety, yes. I like that very much. I ventured into that very   
   > early and I never regretted it. But apart from some basic checks it   
   > should stop at the point where I have to convince a compiler that I   
   > know what I'm doing.   
      
   I see it the other way.  If the compiler can find every error in my   
   program of type X, then simply fixing the program until the compiler   
   accepts it means I get a program that is free of that type of error.   
   That increases my confidence in the program.  The trade-off is that such   
   features can make the language and the compiler harder to use.  A big   
   part of research in languages is widening the classes of errors that the   
   compiler can check without the language becoming too difficult.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)