4 ms·

> Realistically, this is a programmer problem that no language can solve. > The solution is to train new [language X] programmers There is high demand for sof

by Veedrac 11y ago

> Realistically, this is a programmer problem that no language can solve. > The solution is to train new [language X] programmers There is high demand for software that blocks "procrastination" websites, because people struggle to focus when the whole internet's around. I know someone who's hidden their computer charger in order to stay focused. I've read a surprising number of blogs about aiding writer's block with minimalist text editors. I even know someone who needs to offload finances to another party lest they spent it too quickly themselves. You can tell people they just need training, but if the whole standard library screams "abstraction!", people are going to abstract. A language like Go is the minimalist text editor of the programming world. Sure, some people will scream they need their MS Word macros and floating panes (and it's even more true in CS), but these tools are an effective treatment of the symptom nonetheless. > Generics aren't exactly optional in Rust. Sure, but this doesn't change the trade-off. One should use Rust where the problems it solves best broadly match with the problems you're dealing with. And, IMHO, Rust is an exceptionally high complexity language for small projects.

pcwalton 11y ago
> You can tell people they just need training, but if the whole standard library screams "abstraction!", people are going to abstract. A language like Go is the minimalist text editor of the programming world. Should goroutines and channels be removed from Go then, because new programmers abuse them? I think the right way to look at programming language features is to look at the cost-benefit tradeoff. Generics, to me, are clearly on one side of the line. > And, IMHO, Rust is an exceptionally high complexity language for small projects. I don't think the complexity of Rust is that high, and "small projects" versus "large projects" is the wrong way to look at the value of abstraction anyway. Ruby on Rails is overwhelmingly used for small projects precisely because the abstraction/metaprogramming features of Ruby help small projects so much.
- Veedrac 11y ago
  > I think the right way to look at programming language features is to look at the cost-benefit tradeoff. Generics, to me, are clearly on one side of the line. The right way is to look at the cost-benefit tradeoff in context. There is no fixed line. Go has goroutines and channels because the designers judge that for the area they're aiming at, the benefit outweighs the cost. Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. (You could argue this is just another Blub paradox, but IMHO that would only make sense if the designers weren't proficient in languages including generics, like Java.)
  - pcwalton 11y ago
    > Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. You can find some person who enjoys anything. But I think having basic OCaml-style generics has essentially zero downsides and so many upsides that it's essentially an open and shut judgment call for every statically typed language.
  - jasode 11y ago
    >, but the fact is that some people in enjoy the simplicity that comes from Go not having them. The Golang team was not extolling the lack of generics in Go as a point of pride. They have admitted that it is a useful feature but they haven't decided yet how to add it to the language. (Maybe they never will.) As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. If you don't have generics as a 1st-class language feature, you've now forced complexity into the users' code with empty interface{} and copy & paste code. Or, you create new complexity by writing a code gen tool to simulate generics. The complexity is now in the code-to-write-code-tool & the build process. Certainly, there are some languages that don't need generics: proprietary 4GL such as SAP ABAP, procedural-SQL such as Microsoft Transact-SQL and Oracle PL/SQL, and shell scripting languages such as bash. However, with Go positioning itself as a "general" programming language, the lack of generics is more a consequence of Google's priorities and timeline of development rather than a pinnacle of design. Programmers have wanted to write algorithms that work with multiple types for decades before Go was invented and leaving it out as a language feature actually doesn't make things simpler if "simplicity" is looked at holistically.
    - Veedrac 11y ago
      > The Golang team was not extolling the lack of generics in Go as a point of pride. Indeed, they're extolling the simplicity one gets. To quote their FAQ: > Why does Go not have generic types? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. If they can find a way to add it that doesn't take away the simplicity they enjoy, all the better. > As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. That's if you require generic objects. There are reasonable ways to write code that largely avoids them (namely, by specializing your code on specific, standard types for the given problem). Whether this is reasonable for your circumstance depends on your circumstance and the way you like to solve problems.
- Animats 11y ago
  Go's "channels" do a lot more sharing than the Go sales materials claim. If you send a slice across a channel, you're now sharing unlocked data across a concurrency boundary. Go needs a borrow checker and a more Rust-like ownership model. Then you could safely use channels a lot without risk of somebody breaking an implicit assumption about concurrency safety.

by Veedrac 11y ago

pcwalton 11y ago

> You can tell people they just need training, but if the whole standard library screams "abstraction!", people are going to abstract. A language like Go is the minimalist text editor of the programming world. Should goroutines and channels be removed from Go then, because new programmers abuse them? I think the right way to look at programming language features is to look at the cost-benefit tradeoff. Generics, to me, are clearly on one side of the line. > And, IMHO, Rust is an exceptionally high complexity language for small projects. I don't think the complexity of Rust is that high, and "small projects" versus "large projects" is the wrong way to look at the value of abstraction anyway. Ruby on Rails is overwhelmingly used for small projects precisely because the abstraction/metaprogramming features of Ruby help small projects so much.

Veedrac 11y ago
> I think the right way to look at programming language features is to look at the cost-benefit tradeoff. Generics, to me, are clearly on one side of the line. The right way is to look at the cost-benefit tradeoff in context. There is no fixed line. Go has goroutines and channels because the designers judge that for the area they're aiming at, the benefit outweighs the cost. Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. (You could argue this is just another Blub paradox, but IMHO that would only make sense if the designers weren't proficient in languages including generics, like Java.)
- pcwalton 11y ago
  > Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. You can find some person who enjoys anything. But I think having basic OCaml-style generics has essentially zero downsides and so many upsides that it's essentially an open and shut judgment call for every statically typed language.
- jasode 11y ago
  >, but the fact is that some people in enjoy the simplicity that comes from Go not having them. The Golang team was not extolling the lack of generics in Go as a point of pride. They have admitted that it is a useful feature but they haven't decided yet how to add it to the language. (Maybe they never will.) As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. If you don't have generics as a 1st-class language feature, you've now forced complexity into the users' code with empty interface{} and copy & paste code. Or, you create new complexity by writing a code gen tool to simulate generics. The complexity is now in the code-to-write-code-tool & the build process. Certainly, there are some languages that don't need generics: proprietary 4GL such as SAP ABAP, procedural-SQL such as Microsoft Transact-SQL and Oracle PL/SQL, and shell scripting languages such as bash. However, with Go positioning itself as a "general" programming language, the lack of generics is more a consequence of Google's priorities and timeline of development rather than a pinnacle of design. Programmers have wanted to write algorithms that work with multiple types for decades before Go was invented and leaving it out as a language feature actually doesn't make things simpler if "simplicity" is looked at holistically.
  - Veedrac 11y ago
    > The Golang team was not extolling the lack of generics in Go as a point of pride. Indeed, they're extolling the simplicity one gets. To quote their FAQ: > Why does Go not have generic types? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. If they can find a way to add it that doesn't take away the simplicity they enjoy, all the better. > As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. That's if you require generic objects. There are reasonable ways to write code that largely avoids them (namely, by specializing your code on specific, standard types for the given problem). Whether this is reasonable for your circumstance depends on your circumstance and the way you like to solve problems.
Animats 11y ago
Go's "channels" do a lot more sharing than the Go sales materials claim. If you send a slice across a channel, you're now sharing unlocked data across a concurrency boundary. Go needs a borrow checker and a more Rust-like ownership model. Then you could safely use channels a lot without risk of somebody breaking an implicit assumption about concurrency safety.