4 ms·

>I'd very much like a more expressive and better designed than Go language, without the ceremony and straight-jacket of Rust. The problem is this mentality is

>I'd very much like a more expressive and better designed than Go language, without the ceremony and straight-jacket of Rust. The problem is this mentality is one that produces unmaintainable software in the long run. In the case of Go, the simplicity of the language can be frustrating when it comes to expressing one's ideas in "clever" ways; but the code you write may be easily grokked by a junior developer that started with Go last week. On the other hand, things like metaprogramming allow you to build a castle of abstractions which you yourself will have trouble navigating after six months without touching the codebase, and will be a pain of legacy code to any other engineer. Sure, you don't have to use all of it at first, or ever, but that's what I mean "in the long run", either you cave in or someone else in your team does. It's hard to say Go is poorly designed, because it does what it was meant to do extraordinarily well, even if there are a few things that could be even further simplified and yes, things like generics (where the complexity tradeoff is not that high due to its ubiquitous nature) that could be added (and this discussion seems to be back on the table according to Russ Cox). As for Rust, without all the ceremony you cannot summon the demons that grant you perfect memory safety without paying for GC as well as absence of data races. Nim simply cannot provide this despite all the complexity it comes with, and really, if you're okay with that much complexity you might as well just stick with C++ and the gargantuan momentum behind it. The committee is making strides towards making the language more palatable so the appeal for Nim diminishes with each new release.

coldtea 10y ago
>The problem is this mentality is one that produces unmaintainable software in the long run. What mentality? Wanting more expressive power than Go? Then Haskell for one, or even OcamL and Ada, must produce some very unmaintainable code... >In the case of Go, the simplicity of the language can be frustrating when it comes to expressing one's ideas in "clever" ways; but the code you write may be easily grokked by a junior developer that started with Go last week. Only at the micro level (directly checking some lines of code). Grokking what 10 lines do easily doesn't mean you'll more easily grok the overall design, especially if lack of expression has you writing 1000 lines (and copy pasting e.g. for "generic" code) what could take 100 in a more expressive language (and still be perfectly readable). In fact, the main, sure fire, correlation they found for number of bugs in studies of coding, is first and foremost lines of code (regardless of language). >It's hard to say Go is poorly designed, because it does what it was meant to do extraordinarily well It also violates the law of least surprise and orthogonality of concepts several times (e.g. special casing a generic "make", etc). >As for Rust, without all the ceremony you cannot summon the demons that grant you perfect memory safety without paying for GC as well as absence of data races. Sure, but as I don't care for GC pauses or perfect memory safety, I don't have much of a use case for it, hence wanting a middle ground between Go and Rust.
- burntsushi 10y ago
  > but as I don't care for GC pauses or perfect memory safety I personally don't need to care about either of these things to find Rust a nice programming language to use for general purpose stuff. Its type system and tooling are quite pleasant.

coldtea 10y ago

>The problem is this mentality is one that produces unmaintainable software in the long run. What mentality? Wanting more expressive power than Go? Then Haskell for one, or even OcamL and Ada, must produce some very unmaintainable code... >In the case of Go, the simplicity of the language can be frustrating when it comes to expressing one's ideas in "clever" ways; but the code you write may be easily grokked by a junior developer that started with Go last week. Only at the micro level (directly checking some lines of code). Grokking what 10 lines do easily doesn't mean you'll more easily grok the overall design, especially if lack of expression has you writing 1000 lines (and copy pasting e.g. for "generic" code) what could take 100 in a more expressive language (and still be perfectly readable). In fact, the main, sure fire, correlation they found for number of bugs in studies of coding, is first and foremost lines of code (regardless of language). >It's hard to say Go is poorly designed, because it does what it was meant to do extraordinarily well It also violates the law of least surprise and orthogonality of concepts several times (e.g. special casing a generic "make", etc). >As for Rust, without all the ceremony you cannot summon the demons that grant you perfect memory safety without paying for GC as well as absence of data races. Sure, but as I don't care for GC pauses or perfect memory safety, I don't have much of a use case for it, hence wanting a middle ground between Go and Rust.

burntsushi 10y ago
> but as I don't care for GC pauses or perfect memory safety I personally don't need to care about either of these things to find Rust a nice programming language to use for general purpose stuff. Its type system and tooling are quite pleasant.