5 ms·

> The article seemed to describe a high speed native language with garbage collection. I guess that does seem similar to D, but D is much closer to any of the l

> The article seemed to describe a high speed native language with garbage collection. I guess that does seem similar to D, but D is much closer to any of the languages I listed with more than 15 years of development and a much smaller list of breaking changes. It also isn't anywhere near as popular as the three I mentioned. Well, when you compare languages, you usually do it by feature set. Both Nim and D are statically typed, garbage collected, imperative languages with first-class metaprogramming features. I'll also add that Nim has also about 9 years of development behind it. It's older than you think. > Why does Nim get the attention that D does not? I think Nim only gets attention around here because its new and not because it brings anything directly useful. As long as it is still "new" there is still so much potential. I see both Nim and D getting comparable attention. They both aren't mainstream languages, so coverage is mostly by enthusiasts and intermittent. People are interested because both are sufficiently different from mainstream languages, not because they suddenly plan to bet their careers on them. > As for garbage collection, I think you are overestimating its value. There are great resource management schemes in both Rust and C++, and they can each manage much more than just memory. I am only qualified to speak in detail on C++, but if you simply avoid the "new" operator and automatically allocate everything (some say stack allocate), which is the default, then everything is cleaned up for you automatically. This would be a long debate. Suffice it to say that for many people the benefit of avoiding GC is unclear. Both C++ and Rust manage shared ownership poorly (i.e. it being inefficient, leading to lots of syntactic noise, or both). Note also that I'm not saying that GC is always better, but that it's a differentiating feature. As for resource management, RAII in my experience is primarily the consequence of poor support for higher order functions or equivalent functionality in a language. (The type of resource management that RAII facilitates is usually better done through higher order functions or a sufficiently expressive macro [1] system.) > Further down the garbage collection route, if your app doesn't need performance then why not stick with Ruby, Javascript or Python, they are all well supported and provide tons of flexibility and libraries. You seem to be have some serious misunderstandings about garbage collection. No, GC is not per se a performance drain, and adding the two orders of magnitude overhead that a typical bytecode interpreter for a dynamically typed language induces is not even in the same ballpark for even poorly implemented GC. [1] And by macros I don't mean C/C++ preprocessor macros, but macros that are properly integrated in the language and its type system, such as in LISP, Nim, D, or Rust.

gpderetta 10y ago
>Both C++ and Rust manage shared ownership poorly Both C++ and rust encourage exclusive ownership. And that's a good thing. > RAII in my experience is primarily the consequence of poor support for higher order functions or equivalent functionality in a language. HOF tie resources to lexical scope; RAII ties them to object lifetimes, recursively. In turn lifetimes may be bound to a lexical scope, but often is not the case.
- rbehrends 10y ago
  > Both C++ and rust encourage exclusive ownership. And that's a good thing. It's not. It makes lots of important things unnecessarily hard and often leads to unnecessary copying [1]. It makes it hard to even do something like OCaml's List.filter and Array.filter properly. It gets in the way of doing functional data structures (ex: binary decision diagrams). Lots of common design patterns also require shared ownership. > HOF tie resources to lexical scope; RAII ties them to object lifetimes, recursively. In turn lifetimes may be bound to a lexical scope, but often is not the case. No, higher order functions don't per se tie resource management to lexical scope (though that's the easiest application). You can build an entire transactional model on top of higher order functions. Second, tying resource management to object lifetime is dangerous, as object lifetime can exceed the intended life of a resource (ex: closures, storing debugging information on the heap). Third, RAII is in practice little more powerful than lexical scoping. RAII works poorly for global variables (problems with initialization/destruction order) and thus is in practice limited to automatic and heap storage. Using heap storage leads to the aforementioned problems, where object lifetime can become unpredictable. [1] https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318
  - gpderetta 10y ago
    >It makes lots of important things unnecessarily hard and often leads to unnecessary copying [1] If you read the article referenced by that thread you'll see that a major issue with string copying is due to having a lot of bad interfaces taking raw C pointers so code at both side of the ibterface need to make copies exactly because the raw C pointer doesn't guarantee exclusive ownership. The remaining issues are due to a badly optimized string buider in Chrome and failure of pre-reserving vector memory which lead to many copies on resize. This last issue is fixed with move semantics in c++11. >It makes it hard to even do something like OCaml's List.filter and Array.filter Std::remove_if works genrically on any range. Boost (and the range TR) provides iterator views when you need lazy evaluation. > You can build an entire transactional model on top of higher order functions. I'm sure you can, in the end you can implement anything manually. With RAII propagation of lifetimes is done automatically by the compiler. >Using heap storage leads to the aforementioned problems, where object lifetime can become unpredictable. Only if you use shared ownership. Otherwise is completely predictable.

gpderetta 10y ago

>Both C++ and Rust manage shared ownership poorly Both C++ and rust encourage exclusive ownership. And that's a good thing. > RAII in my experience is primarily the consequence of poor support for higher order functions or equivalent functionality in a language. HOF tie resources to lexical scope; RAII ties them to object lifetimes, recursively. In turn lifetimes may be bound to a lexical scope, but often is not the case.

rbehrends 10y ago
> Both C++ and rust encourage exclusive ownership. And that's a good thing. It's not. It makes lots of important things unnecessarily hard and often leads to unnecessary copying [1]. It makes it hard to even do something like OCaml's List.filter and Array.filter properly. It gets in the way of doing functional data structures (ex: binary decision diagrams). Lots of common design patterns also require shared ownership. > HOF tie resources to lexical scope; RAII ties them to object lifetimes, recursively. In turn lifetimes may be bound to a lexical scope, but often is not the case. No, higher order functions don't per se tie resource management to lexical scope (though that's the easiest application). You can build an entire transactional model on top of higher order functions. Second, tying resource management to object lifetime is dangerous, as object lifetime can exceed the intended life of a resource (ex: closures, storing debugging information on the heap). Third, RAII is in practice little more powerful than lexical scoping. RAII works poorly for global variables (problems with initialization/destruction order) and thus is in practice limited to automatic and heap storage. Using heap storage leads to the aforementioned problems, where object lifetime can become unpredictable. [1] https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318
- gpderetta 10y ago
  >It makes lots of important things unnecessarily hard and often leads to unnecessary copying [1] If you read the article referenced by that thread you'll see that a major issue with string copying is due to having a lot of bad interfaces taking raw C pointers so code at both side of the ibterface need to make copies exactly because the raw C pointer doesn't guarantee exclusive ownership. The remaining issues are due to a badly optimized string buider in Chrome and failure of pre-reserving vector memory which lead to many copies on resize. This last issue is fixed with move semantics in c++11. >It makes it hard to even do something like OCaml's List.filter and Array.filter Std::remove_if works genrically on any range. Boost (and the range TR) provides iterator views when you need lazy evaluation. > You can build an entire transactional model on top of higher order functions. I'm sure you can, in the end you can implement anything manually. With RAII propagation of lifetimes is done automatically by the compiler. >Using heap storage leads to the aforementioned problems, where object lifetime can become unpredictable. Only if you use shared ownership. Otherwise is completely predictable.