6 ms·

I like Go, but I feel that it only addresses one of the urgent problems in computer programming, concurrency. Another very important problem IMO is correctness

I like Go, but I feel that it only addresses one of the urgent problems in computer programming, concurrency. Another very important problem IMO is correctness and I find Go lacking in that area; the onus is squarely on the shoulder of the programmer. Languages like ML, Haskell, or Rust offer facilities to make correct code easier to write (or incorrect code harder to write, depends on your view point).

bsg75 13y ago
> facilities to make correct code easier to write I have read a bit about this for Haskell. What in Rust facilitates the same, that is absent from Go (or C, C++) ?
- samnardoni 13y ago
  Type parameterisation, lifetimes, mutability qualifiers. Algebraic data types can be used to avoid null pointers via an Option/Maybe type.
- masklinn 13y ago
  Non-nullable pointers, a type system which is not full of holes, inability to cast. C and C++ obviously add (remove?) such things as complete lack of memory safety, unchecked out-of-bounds accesses or lifetime management. And Go's inability to assert any immutability is also a strike against correctness (at least C++ has consts, though they're complex beasts)
  - PommeDeTerre 13y ago
    One thing to consider about C++, though, is that it's powerful enough to already allow you to duplicate or very closely approximate the functionality you listed. This is the essence of what some people call "Modern C++". C++ functionality like references and smart pointers make pointer nullability and memory safety irrelevant, or at least much, much less of an issue than in C or older C++ code. RAII significantly helps with lifetime management of all sorts of resources, from memory to database connections to files. There are various collection libraries for C++ that make out-of-bounds accesses a non-issue, at a very minimal cost. Likewise, it's quite easy in almost all cases to avoid using unsafe casts and other behavior that may cause problems, when taking a more modern approach to C++. With a small amount of discipline, C++ of today can be much different than C++ of the 1980s or 1990s. Many of the pitfalls of that era can be avoided with remarkably little effort, especially when using C++11 and modern implementations. Yet it still easily gives you access to very powerful functionality for those rare cases when it is needed. This is much harder to do in many other, more modern languages.
    - steveklabnik 13y ago
      There's no question that you _can_ write safe code in C++, but it's very, very hard. > With a small amount of discipline, I would just like to point out that when dynamic language advocates suggest that 'with a small amount of discipline, you can write reasonably safe dynamic code' and you laugh them off with comments about how static typing saves you from errors at compile time. The same is true with languages like Rust or Haskell; you don't need the discipline, the compiler catches such things for you.
      - PommeDeTerre 13y ago
        The discipline involved with writing safe C++ code is somewhat different from the discipline involved with writing safe code in some dynamic language. In C++, it's mostly just a matter of understanding the language features you're using, and then avoiding ones that can be harmful in some cases, often in favor of much safer alternative approaches. The C++ compiler will still catch many other types of problems at compile time that wouldn't necessarily be noticed (assuming they even are noticed by the developer(s)) until runtime when using a dynamic language. The safety net offered by the C++ compiler may not be cast as wide as that of Rust or Haskell, but it's still there, and it does catch many common issues. And I think it's wrong to say that Rust and Haskell don't require discipline; they do. It's still easy to write inefficient or unmaintainable code in those languages, for example. You still need to know what you're doing, and how to use the functionality that they offer, in order to avoid problems like that. Now, the discipline needed when using a dynamic language not only includes the discipline needed when using C++ (that is, "don't do stupid stuff"), but it also includes not making trivial mistakes like typos, or missing some changes when refactoring, and so on. Much, much more discipline is needed when writing code in dynamic languages. That is the kind of discipline that can be automated away to a very large extent, however. Personally, I do think it's silly and wasteful to willingly take on responsibility for ensuring that sort of discipline for anything but the smallest scripts. So, yes, I will speak out against it and those who suggest it's acceptable, especially in larger systems.
        pcwalton 13y ago
- freyrs3 13y ago
  Region-based memory management in Rust makes it possible to deal with shared memory without having to deal with life-cycle maintenance that you deal with in C. C++ has some similar concepts but like most things in C++ they are horribly complicated and rely on large template libraries.
PommeDeTerre 13y ago
Rust appears very promising, but having followed it for some time now, it's still severely lacking in terms of stability. I'm talking about the stability of the language feature set and the amount of change it's undergoing, rather than the quality of the implementation or anything of that sort. While it's good to see the language evolving and improving, this type of churn also means it isn't very practical to use. For example, some experimental Rust code I wrote a mere 6 to 8 months ago is now basically unusable with recent versions of Rust due to language functionality changes, syntax changes, and library changes. I keep hoping that it'll start to stabilize, even just on a feature set and standard library that may not be perfect, but will at least be usable for longer than a few months. Yet this doesn't seem to be happening. This lack of stability will start to significantly hurt its adoption at some point. Go has taken a better approach, in my opinion. It isn't perfect, and it's lacking some important functionality, but at least there's a version that's usable, well-supported, and usable well into the future, even if the language does continue to evolve in incompatible ways.
- steveklabnik 13y ago
  > Yet this doesn't seem to be happening. Rust is starting to settle down, and once it has settled, it will be very stable. In particular, the 0.6 release was a huge breaking one, and 0.7 was less so. As it approaches 1.0, things should calm down quite a bit.
  - happy_dino 13y ago
    I just fear this "it must stop breaking things after 1.0" attitude some people have. That's exactly what the death of a promising language looks like. Those people should just go elsewhere, there are enough worse-is-better languages to pick from without dragging down yet another one.
    - PommeDeTerre 13y ago
      I'm not sure that you're interpreting such a stance correctly. Any further 1.x releases should clearly try to avoid incompatibility as much as possible. Anyone seriously using a programming language does require a relatively high degree of stability with respect to language changes, library changes, and so forth. But that in no way means that there can't be work done on a 2.x release that does introduce incompatibilities in an effort to improve the language and any standard libraries it may offer. This situation is much more about controlling change, rather than preventing it outright.

bsg75 13y ago

> facilities to make correct code easier to write I have read a bit about this for Haskell. What in Rust facilitates the same, that is absent from Go (or C, C++) ?

samnardoni 13y ago
Type parameterisation, lifetimes, mutability qualifiers. Algebraic data types can be used to avoid null pointers via an Option/Maybe type.
masklinn 13y ago
Non-nullable pointers, a type system which is not full of holes, inability to cast. C and C++ obviously add (remove?) such things as complete lack of memory safety, unchecked out-of-bounds accesses or lifetime management. And Go's inability to assert any immutability is also a strike against correctness (at least C++ has consts, though they're complex beasts)
- PommeDeTerre 13y ago
  One thing to consider about C++, though, is that it's powerful enough to already allow you to duplicate or very closely approximate the functionality you listed. This is the essence of what some people call "Modern C++". C++ functionality like references and smart pointers make pointer nullability and memory safety irrelevant, or at least much, much less of an issue than in C or older C++ code. RAII significantly helps with lifetime management of all sorts of resources, from memory to database connections to files. There are various collection libraries for C++ that make out-of-bounds accesses a non-issue, at a very minimal cost. Likewise, it's quite easy in almost all cases to avoid using unsafe casts and other behavior that may cause problems, when taking a more modern approach to C++. With a small amount of discipline, C++ of today can be much different than C++ of the 1980s or 1990s. Many of the pitfalls of that era can be avoided with remarkably little effort, especially when using C++11 and modern implementations. Yet it still easily gives you access to very powerful functionality for those rare cases when it is needed. This is much harder to do in many other, more modern languages.
  - steveklabnik 13y ago
    There's no question that you _can_ write safe code in C++, but it's very, very hard. > With a small amount of discipline, I would just like to point out that when dynamic language advocates suggest that 'with a small amount of discipline, you can write reasonably safe dynamic code' and you laugh them off with comments about how static typing saves you from errors at compile time. The same is true with languages like Rust or Haskell; you don't need the discipline, the compiler catches such things for you.
    - PommeDeTerre 13y ago
      The discipline involved with writing safe C++ code is somewhat different from the discipline involved with writing safe code in some dynamic language. In C++, it's mostly just a matter of understanding the language features you're using, and then avoiding ones that can be harmful in some cases, often in favor of much safer alternative approaches. The C++ compiler will still catch many other types of problems at compile time that wouldn't necessarily be noticed (assuming they even are noticed by the developer(s)) until runtime when using a dynamic language. The safety net offered by the C++ compiler may not be cast as wide as that of Rust or Haskell, but it's still there, and it does catch many common issues. And I think it's wrong to say that Rust and Haskell don't require discipline; they do. It's still easy to write inefficient or unmaintainable code in those languages, for example. You still need to know what you're doing, and how to use the functionality that they offer, in order to avoid problems like that. Now, the discipline needed when using a dynamic language not only includes the discipline needed when using C++ (that is, "don't do stupid stuff"), but it also includes not making trivial mistakes like typos, or missing some changes when refactoring, and so on. Much, much more discipline is needed when writing code in dynamic languages. That is the kind of discipline that can be automated away to a very large extent, however. Personally, I do think it's silly and wasteful to willingly take on responsibility for ensuring that sort of discipline for anything but the smallest scripts. So, yes, I will speak out against it and those who suggest it's acceptable, especially in larger systems.
      - pcwalton 13y ago
freyrs3 13y ago
Region-based memory management in Rust makes it possible to deal with shared memory without having to deal with life-cycle maintenance that you deal with in C. C++ has some similar concepts but like most things in C++ they are horribly complicated and rely on large template libraries.

PommeDeTerre 13y ago

Rust appears very promising, but having followed it for some time now, it's still severely lacking in terms of stability. I'm talking about the stability of the language feature set and the amount of change it's undergoing, rather than the quality of the implementation or anything of that sort. While it's good to see the language evolving and improving, this type of churn also means it isn't very practical to use. For example, some experimental Rust code I wrote a mere 6 to 8 months ago is now basically unusable with recent versions of Rust due to language functionality changes, syntax changes, and library changes. I keep hoping that it'll start to stabilize, even just on a feature set and standard library that may not be perfect, but will at least be usable for longer than a few months. Yet this doesn't seem to be happening. This lack of stability will start to significantly hurt its adoption at some point. Go has taken a better approach, in my opinion. It isn't perfect, and it's lacking some important functionality, but at least there's a version that's usable, well-supported, and usable well into the future, even if the language does continue to evolve in incompatible ways.

steveklabnik 13y ago
> Yet this doesn't seem to be happening. Rust is starting to settle down, and once it has settled, it will be very stable. In particular, the 0.6 release was a huge breaking one, and 0.7 was less so. As it approaches 1.0, things should calm down quite a bit.
- happy_dino 13y ago
  I just fear this "it must stop breaking things after 1.0" attitude some people have. That's exactly what the death of a promising language looks like. Those people should just go elsewhere, there are enough worse-is-better languages to pick from without dragging down yet another one.
  - PommeDeTerre 13y ago
    I'm not sure that you're interpreting such a stance correctly. Any further 1.x releases should clearly try to avoid incompatibility as much as possible. Anyone seriously using a programming language does require a relatively high degree of stability with respect to language changes, library changes, and so forth. But that in no way means that there can't be work done on a 2.x release that does introduce incompatibilities in an effort to improve the language and any standard libraries it may offer. This situation is much more about controlling change, rather than preventing it outright.