8 ms·

I like this a lot, it's always tempting to think that we can create a perfect language that would be the best in all situations but we can't. Rust is great for

I like this a lot, it's always tempting to think that we can create a perfect language that would be the best in all situations but we can't. Rust is great for projects where its values are valued: - Speed - Memory Safety - Concurrency Go is great for projects where its values are valued: - productivity (from being able to immediately understand a new code base due to the small and simple language to the toolchain it provides). - concurrency Likewise, Ruby and Python are great choices for some projects.

Scarbutt 11y ago
Productivity in Go is an illusion but I see the appeal of it for big enterprise teams composed of disposable programmers.
- lossolo 11y ago
  I am more productive in Go and C++ than in Rust. But for sure i am more productive in Rust than in C.
  - deleted 11y ago
    [deleted]
  - petra 11y ago
    What about memory safety? are c++ smart pointers equivalent to rust in safety ?
    - hobofan 11y ago
      Yes, but they are only checkable at runtime in C++.
      - kibwen 11y ago
        Only assuming that you never use references (or raw pointers), which depending on your needs may be unavoidable.
  - kaoD 11y ago
    What's your mileage in Rust compared to C++? I found as soon as I got in the borrow-checker mindset I spent less and less time thinking about ownership and lifetimes to the point where I don't care anymore. I spend more time thinking about my program and its architecture (which I'd spend in any language) than thinking about Rust itself. What would you say are exactly the pain points of productivity for you when using Rust? My biggest gripes with Rust are macros (they're so useful but sooo hard at the same time compared to Lispy languages, where you don't have to fight the macro system as much due to their simpler syntax), compile times (which I hope will get better) and the fact that even at 1.x the the language and std still don't feel mature enough.
- vardump 11y ago
  So please tell us what is a productive language? At least any argument why Go is not productive, why its productivity is an illusion.
  - pjmlp 11y ago
    > At least any argument why Go is not productive, why its productivity is an illusion. - generic code only via go generate and interface {} - verbose error handling - the way dependencies are handled - no language support for functional paradigms - nil pointer semantics in interfaces - very thin type system Go would be a great language in the mid-90's, nowadays given the features adopted in the mainstream it feels too little. For me, the positive thing is that it may lure developers that would use C to use Go instead, and in the process discover that their use case is perfectly doable with a memory safe language.
    - vardump 11y ago
      I've done one successful small/medium size TCP server project in Golang. Primarily programming in C++. - Generics were absolutely no issue. - Golang error handling may be verbose, but it also ensures errors locally visible and are handled where they occur. Just need to ensure all return values are handled. I much prefer it to C++, where you can never tell from local context what might throw and what won't. Generally I found it to be very productive compared to at least C++ and Java. Two aspects of Golang were a huge productivity boost for the project in question: struct automatic (de)serialization to JSON, XML, etc. was very nice. Goroutines and channels simplified the code.
- kajecounterhack 11y ago
  I see the appeal of it for big enterprise teams composed of disposable programmers Can you explain? Why are go programmers "disposable?" Is it because the code is understandable (especially following our style guide / enforcing gofmt, godoc, etc)? I do find our go code to be that way, but I don't think that's a bad thing. Productivity in Go is an illusion I feel productive in Go. Can you explain this statement? I like dealing with a simpler toolchain as the op mentioned.
  - glennsl 11y ago
    I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.
    - catnaroek 11y ago
      > It is easy to pick up, understand and use. But it is also very error prone These two sentences are badly in conflict. How can you say you “understand” something if you find yourself repeatedly making mistakes when you use it?
      - glennsl 11y ago
        Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
        catnaroek 11y ago
        > Which one do you think is easier to understand? For a toolmaker, the hammer. For a user, the nailgun. Also, there's a qualitative difference between physical tools and programming languages. The design of a physical tool can only lessen the likelihood of an accident and/or the seriousness of its consequences, but never entirely rule them out - that's why they're called “accidents”. On the other hand, programming languages can be designed to treat logical errors as invalid code. A program that doesn't compile is completely guaranteed not to corrupt your data, reveal your passwords to hackers, etc.
Pyxl101 11y ago
> it's always tempting to think that we can create a perfect language that would be the best in all situations but we can't Why can't we design a language that would be the best in all situations? I see no reason necessarily to believe that's true, though I recognize that it has not yet been done. It may be impossible to create a car that is also an excellent submarine and a great airplane, but software is not subject to the same kind of physical limitations. I see no reason in principle why a perfect language could not be malleable enough to accommodate all situations optimally. I realize that my writing here is not a convincing assertion that such a language can exist. I recognize that. I'm just saying that there doesn't seem to be strong evidence that it can't exist or that we should give up trying to design it. A person who wishes to argue that the perfect language can't exist should perhaps give an example of two different problems that cannot be solved well by any single known language, and that can be solved much better by two programs in two different languages. I would like to dissect that example and see if we can indeed find such examples of sets of problems that cannot be solved well by one language. If we cannot find such problem sets, then that may suggest that we can indeed "unify" programming under one perfect language, by tweaking its syntax and semantics appropriately.
- kibwen 11y ago
  My go-to example is shell scripting. In a shell language, you really, really don't want to be forced to quote strings, and you typically also don't want to have to explicitly parenthesize command invocations. Take a typical shell command: rm -rf foobar You may not think about it much, but these are all just strings. Go ahead and type this into your shell, it will have the same effect: "rm" "-rf" "foobar" Now imagine how utterly annoying it would be to use your shell if you were forced to quote every string you ever typed. Even worse, here's how the above would look in Python-esque syntax: call(["rm", "-rf", "foobar"]) Sysadmins would riot in the streets. Most languages that are explicitly designed for scripting offer this feature: TCL and Perl both allow unquoted strings (Perl with `use strict` places some limits on them), and I believe Ruby has some way of enabling this as well with `method_missing`. But it's important to note that this behavior is almost never what you want for programming in most other domains, which is why most other languages (particularly non-dynamic ones) don't even offer anything resembling this feature. And of course, you can have a single language with both! You could have it controlled by a flag or something. Super great. But this is just the tip of the iceberg. When you import a namespace in your language, are all its identifiers automatically brought into your local scope, or must you import them one-by-one? For fast-and-loose tasks you want the former, for long-term maintainability you want the latter. But we could have a switch for this too. Still great. Now, when you `x = new Blah()`, is that Blah on the stack or the heap? This has enormous implications for both semantics and performance, and if you truly want an all-purpose language then heuristics like escape analysis won't save you, you need to be able to control this. On and on we go, until your language has a million little switches that may interact with each other in surprising ways, because different programming tasks actually do have different needs, and although your language may ultimately be capable of fulfilling all these tasks, in practice it will be considered a dozen different languages trying to coexist in the same compiler (with no consensus on where to draw the lines that demarcate each). Meanwhile, people who want to Get Things Done will opt not to wrestle with your Swiss-army language and will instead favor more limited languages that fulfill the needs of their specific tasks, because the vast majority of people are not writing client-side code in the morning and device drivers in the afternoon. Now, there does exist a scenario where One Language To Rule Them All can dominate: when the market for programming languages is very small. If the market is small, then demand for domain-specific languages is less. Or rather, the value of differentiation is less, because your differentiated language will have a small share of a small market, and will be unable to thrive. But in a large market, even a small share is enough to subsist on. In reality Go and Rust likely have 1/1000th the number of programmers as Java and C++, but even 1/1000th of tens of millions is more than enough to support large and thriving communities. So ultimately it's not that it's impossible to make a language that's great for all tasks (though it would still be difficult), it's that there's not enough demand for one, and if you believe that the cohort of programmers is growing then demand for one will only continue to decrease.
BuckRogers 11y ago
> I like this a lot, it's always tempting to think that we can create a perfect language that would be the best in all situations but we can't. We may one day, but we should be uncompromising on a good, no nonsense. That varies for everyone but I think a lot of people including myself feel something Pythonic would be that syntax. Implementations can work around syntaxes, but it's important that the programmer comes first rather than the machine. JIT'd and compiled Python would fit this need well. We already have both but it could be improved upon.

Scarbutt 11y ago

Productivity in Go is an illusion but I see the appeal of it for big enterprise teams composed of disposable programmers.

lossolo 11y ago
I am more productive in Go and C++ than in Rust. But for sure i am more productive in Rust than in C.
- deleted 11y ago
  [deleted]
- petra 11y ago
  What about memory safety? are c++ smart pointers equivalent to rust in safety ?
  - hobofan 11y ago
    Yes, but they are only checkable at runtime in C++.
    - kibwen 11y ago
      Only assuming that you never use references (or raw pointers), which depending on your needs may be unavoidable.
- kaoD 11y ago
  What's your mileage in Rust compared to C++? I found as soon as I got in the borrow-checker mindset I spent less and less time thinking about ownership and lifetimes to the point where I don't care anymore. I spend more time thinking about my program and its architecture (which I'd spend in any language) than thinking about Rust itself. What would you say are exactly the pain points of productivity for you when using Rust? My biggest gripes with Rust are macros (they're so useful but sooo hard at the same time compared to Lispy languages, where you don't have to fight the macro system as much due to their simpler syntax), compile times (which I hope will get better) and the fact that even at 1.x the the language and std still don't feel mature enough.
vardump 11y ago
So please tell us what is a productive language? At least any argument why Go is not productive, why its productivity is an illusion.
- pjmlp 11y ago
  > At least any argument why Go is not productive, why its productivity is an illusion. - generic code only via go generate and interface {} - verbose error handling - the way dependencies are handled - no language support for functional paradigms - nil pointer semantics in interfaces - very thin type system Go would be a great language in the mid-90's, nowadays given the features adopted in the mainstream it feels too little. For me, the positive thing is that it may lure developers that would use C to use Go instead, and in the process discover that their use case is perfectly doable with a memory safe language.
  - vardump 11y ago
    I've done one successful small/medium size TCP server project in Golang. Primarily programming in C++. - Generics were absolutely no issue. - Golang error handling may be verbose, but it also ensures errors locally visible and are handled where they occur. Just need to ensure all return values are handled. I much prefer it to C++, where you can never tell from local context what might throw and what won't. Generally I found it to be very productive compared to at least C++ and Java. Two aspects of Golang were a huge productivity boost for the project in question: struct automatic (de)serialization to JSON, XML, etc. was very nice. Goroutines and channels simplified the code.
kajecounterhack 11y ago
I see the appeal of it for big enterprise teams composed of disposable programmers Can you explain? Why are go programmers "disposable?" Is it because the code is understandable (especially following our style guide / enforcing gofmt, godoc, etc)? I do find our go code to be that way, but I don't think that's a bad thing. Productivity in Go is an illusion I feel productive in Go. Can you explain this statement? I like dealing with a simpler toolchain as the op mentioned.
- glennsl 11y ago
  I'm not the parent, but my impression is that Go is productive more in the sense of quantity than quality. It is easy to pick up, understand and use. But it is also very error prone, because its type system is poorly suited for proper error handling, nulls and generic code. It's certainly better than C and most dynamic languages, but that's not setting the bar very high. I really see no reason to pick up Go these days unless you're a fan of 80s retro hits. If you want most of the goodness of Rust combined with the easiness of Go, look to Kotlin and Swift.
  - catnaroek 11y ago
    > It is easy to pick up, understand and use. But it is also very error prone These two sentences are badly in conflict. How can you say you “understand” something if you find yourself repeatedly making mistakes when you use it?
    - glennsl 11y ago
      Compare a hammer and nails to a nailgun with various safety mechanisms. Which one do you think is easier to understand, and which is more prone to sore fingers?
      - catnaroek 11y ago
        > Which one do you think is easier to understand? For a toolmaker, the hammer. For a user, the nailgun. Also, there's a qualitative difference between physical tools and programming languages. The design of a physical tool can only lessen the likelihood of an accident and/or the seriousness of its consequences, but never entirely rule them out - that's why they're called “accidents”. On the other hand, programming languages can be designed to treat logical errors as invalid code. A program that doesn't compile is completely guaranteed not to corrupt your data, reveal your passwords to hackers, etc.

Pyxl101 11y ago

> it's always tempting to think that we can create a perfect language that would be the best in all situations but we can't Why can't we design a language that would be the best in all situations? I see no reason necessarily to believe that's true, though I recognize that it has not yet been done. It may be impossible to create a car that is also an excellent submarine and a great airplane, but software is not subject to the same kind of physical limitations. I see no reason in principle why a perfect language could not be malleable enough to accommodate all situations optimally. I realize that my writing here is not a convincing assertion that such a language can exist. I recognize that. I'm just saying that there doesn't seem to be strong evidence that it can't exist or that we should give up trying to design it. A person who wishes to argue that the perfect language can't exist should perhaps give an example of two different problems that cannot be solved well by any single known language, and that can be solved much better by two programs in two different languages. I would like to dissect that example and see if we can indeed find such examples of sets of problems that cannot be solved well by one language. If we cannot find such problem sets, then that may suggest that we can indeed "unify" programming under one perfect language, by tweaking its syntax and semantics appropriately.

kibwen 11y ago
My go-to example is shell scripting. In a shell language, you really, really don't want to be forced to quote strings, and you typically also don't want to have to explicitly parenthesize command invocations. Take a typical shell command: rm -rf foobar You may not think about it much, but these are all just strings. Go ahead and type this into your shell, it will have the same effect: "rm" "-rf" "foobar" Now imagine how utterly annoying it would be to use your shell if you were forced to quote every string you ever typed. Even worse, here's how the above would look in Python-esque syntax: call(["rm", "-rf", "foobar"]) Sysadmins would riot in the streets. Most languages that are explicitly designed for scripting offer this feature: TCL and Perl both allow unquoted strings (Perl with `use strict` places some limits on them), and I believe Ruby has some way of enabling this as well with `method_missing`. But it's important to note that this behavior is almost never what you want for programming in most other domains, which is why most other languages (particularly non-dynamic ones) don't even offer anything resembling this feature. And of course, you can have a single language with both! You could have it controlled by a flag or something. Super great. But this is just the tip of the iceberg. When you import a namespace in your language, are all its identifiers automatically brought into your local scope, or must you import them one-by-one? For fast-and-loose tasks you want the former, for long-term maintainability you want the latter. But we could have a switch for this too. Still great. Now, when you `x = new Blah()`, is that Blah on the stack or the heap? This has enormous implications for both semantics and performance, and if you truly want an all-purpose language then heuristics like escape analysis won't save you, you need to be able to control this. On and on we go, until your language has a million little switches that may interact with each other in surprising ways, because different programming tasks actually do have different needs, and although your language may ultimately be capable of fulfilling all these tasks, in practice it will be considered a dozen different languages trying to coexist in the same compiler (with no consensus on where to draw the lines that demarcate each). Meanwhile, people who want to Get Things Done will opt not to wrestle with your Swiss-army language and will instead favor more limited languages that fulfill the needs of their specific tasks, because the vast majority of people are not writing client-side code in the morning and device drivers in the afternoon. Now, there does exist a scenario where One Language To Rule Them All can dominate: when the market for programming languages is very small. If the market is small, then demand for domain-specific languages is less. Or rather, the value of differentiation is less, because your differentiated language will have a small share of a small market, and will be unable to thrive. But in a large market, even a small share is enough to subsist on. In reality Go and Rust likely have 1/1000th the number of programmers as Java and C++, but even 1/1000th of tens of millions is more than enough to support large and thriving communities. So ultimately it's not that it's impossible to make a language that's great for all tasks (though it would still be difficult), it's that there's not enough demand for one, and if you believe that the cohort of programmers is growing then demand for one will only continue to decrease.

BuckRogers 11y ago

> I like this a lot, it's always tempting to think that we can create a perfect language that would be the best in all situations but we can't. We may one day, but we should be uncompromising on a good, no nonsense. That varies for everyone but I think a lot of people including myself feel something Pythonic would be that syntax. Implementations can work around syntaxes, but it's important that the programmer comes first rather than the machine. JIT'd and compiled Python would fit this need well. We already have both but it could be improved upon.