11 ms·

Could you let me know what language doesn't have at least 100 common mistakes across a broad range of developers with varying skill level?

ninetyninenine 1y ago
Did you know there exists languages that don't have run time errors? Languages that you can never crash outside of an OOM. That means you can't find a language with no mistakes. But across all languages there are languages with astronomically more gotchas and mistakes then others. Golang is one of these languages that is astronomical. I mean just compare it to the language with zero runtime errors.
- 9rx 1y ago
  > Did you know there exists languages that don't have run time errors? Probably not. All those languages failed.
  - tmountain 1y ago
    Elm.
    - deleted 1y ago
      [deleted]
    - Philpax 1y ago
      It "succeeded" in that it delivers on its promise and some people still use it, but it is largely dead now due to the lack of development and the community's inability to push the language itself forward. There are forks that address that, but Elm itself seems unlikely to Lazarus any time soon. It's definitely proof that software can be written in such a regime, though, and I hope we see something similarly dogmatic some day.
      - tmountain 1y ago
        Gleam has potential to fill the niche and has an active and growing community.
        Philpax 1y ago
        Gleam / Lustre are fantastic, and I hope to use them in anger at some point, but it's my understanding that they don't aim to be as "total" as Elm (quotation marks because I don't think Elm was total in the formal sense). That is, while Lustre is very much following in Elm's footsteps, both it and the language have not been designed around avoiding runtime failure at all costs. (Which makes sense, given the Erlang/BEAM heritage.)
    - 9rx 1y ago
      Failed language. And for that reason few know it exists.
      - ninetyninenine 1y ago
        It depends on what you consider failure. If you feel popularity is the main metric then golang is successful. Outside of that metric golang is pretty bad. The proof is in the pudding. Here’s a quote from rob pike the creator of golang: “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” Basically in a nutshell he’s saying they dumbed down golang so it’s useable by beginners. Golang is a step backwards. A failure in language development but a success in popularity. You dumb down a language to a point where the language is so dumbed down it hits the largest demographic. You are part of that demographic. It’s similar to the demographic that voted for trump because he’s not fakeish like all the other candidates.
        grepexdev 1y ago
        I understand what you are saying here but I think you've missed the point of what Pike was getting at. I think Pike is acknowledging the practical realities of engineering at scale, and intentionally designed Go with simplicity in mind, which leads to more maintainable code and faster onboarding for new devs. I'll also add that outside of the popularity metric, Go is not all bad. Fast compile times, readability, excellent standard library and toolchain, backward compatibility, to name a few things.
        ninetyninenine 1y ago
        >I think Pike is acknowledging the practical realities of engineering at scale, and intentionally designed Go with simplicity in mind, which leads to more maintainable code and faster onboarding for new devs. Doubt it. Read what he wrote. He's literally referring to people without much experience in programming. The stuff you said is literally NOT what he said. >I'll also add that outside of the popularity metric, Go is not all bad. Fast compile times, readability, excellent standard library and toolchain, backward compatibility, to name a few things. I agree with readability and fast compile times.
- Thaxll 1y ago
  There is no such language, even Rust has many footguns.
  - deleted 1y ago
    [deleted]
  - 9rx 1y ago
    There is such languages, but they actually failed, so you've probably never heard of them.
  - teivah 1y ago
    That's why Manning will consider a 100 Rust Mistakes edition.
- grepexdev 1y ago
  I don't think Go is particularly esoteric to where these "gotchas" are a big problem. In fact, I would argue that the gotchas are an intentional part of Go's design philosophy. I think it is strange to work in Go when coming from another language because of this, which leads people to think Go sucks.
  - 9rx 1y ago
    That may be part of why they think Go sucks, but it is mostly because Go doesn't have many features to paper over poor design decisions. "Advanced" languages let you throw any old gobbledygook at them, and when you finally realize you screwed up, you can just monkey patch (or whatever feature of the day the language has) your way out of it and call it a day. Go is far less forgiving. You have to get the design right or pain will ensue. And pain does ensue for those who try it after being accustomed to having leeway in haphazard design, and thus they conclude Go sucks instead of acknowledging that their design sucks. I mean, Go does suck. Maybe a language should be accommodating to bad designs. But still, those shouting "Go sucks" from the rooftops never seem to be willing to bring introspection into where they might have failed. It's always someone else's fault. (Something not limited to the case of Go, of course)
    - ninetyninenine 1y ago
      Go sucks not because it's accomodating to poor designs. It sucks because it is in itself poorly designed and that leaks over to the design of entire applications. Why have functions return err, nil? Why even allow for a runtime error here? It's a really simple fix. You don't even have to make the language complex to support this. Instead the entire program is littered with holes and if statements you have to check in order to prevent a actual crash
      - deleted 1y ago
        [deleted]
      - 9rx 1y ago
        > Why even allow for a runtime error here? Why not? It doesn't make any difference in practice. Without a complete type system you must write tests to ensure that error conditions (to stay with your example, although this also applies broadly) do what you need of them. If you somehow introduced a runtime error there, your tests would be unable to not notice. Whether your compiler cries or your test suite cries when you screw up is not a meaningful difference. > You don't even have to make the language complex to support this. A complete type system is insanely complex to implement and even harder to write against. Without a complete type system, all you can have is silly half-measures. Maybe the error becomes an optional/result type with forced unwrapping, for example, but you still haven't asserted in the types what needs to happen with the error. So you still need to write the same tests that you had to write anyway. So, other than moving where you discover the problem – from your tests to the compiler – nothing has changed. The half-measures are a cute party trick, I'll give you that, but makes no real difference when actual engineering is taking place. They might, however, give a false sense of security. They might even convince you that you don't need to write tests (you do). Maybe those make for desirable traits?
- onionisafruit 1y ago
  Most of the mistakes in this book and general mistakes you make when programming aren't about crashes or other runtime errors. They are about writing code that is overly complex or otherwise difficult to maintain.
- ljm 1y ago
  This guy writes Malbolge and has zero runtime errors because he can't compile it.
  - ninetyninenine 1y ago
    Whatever the hell that is. And no. Zero runtime errors and compiles to run.
- Yasuraka 1y ago
  Did you know that this book is about mistakes that humans make?
  - ninetyninenine 1y ago
    But the comment is about languages that prevent mistakes that humans make.

ninetyninenine 1y ago

Did you know there exists languages that don't have run time errors? Languages that you can never crash outside of an OOM. That means you can't find a language with no mistakes. But across all languages there are languages with astronomically more gotchas and mistakes then others. Golang is one of these languages that is astronomical. I mean just compare it to the language with zero runtime errors.

9rx 1y ago
> Did you know there exists languages that don't have run time errors? Probably not. All those languages failed.
- tmountain 1y ago
  Elm.
  - deleted 1y ago
    [deleted]
  - Philpax 1y ago
    It "succeeded" in that it delivers on its promise and some people still use it, but it is largely dead now due to the lack of development and the community's inability to push the language itself forward. There are forks that address that, but Elm itself seems unlikely to Lazarus any time soon. It's definitely proof that software can be written in such a regime, though, and I hope we see something similarly dogmatic some day.
    - tmountain 1y ago
      Gleam has potential to fill the niche and has an active and growing community.
      - Philpax 1y ago
        Gleam / Lustre are fantastic, and I hope to use them in anger at some point, but it's my understanding that they don't aim to be as "total" as Elm (quotation marks because I don't think Elm was total in the formal sense). That is, while Lustre is very much following in Elm's footsteps, both it and the language have not been designed around avoiding runtime failure at all costs. (Which makes sense, given the Erlang/BEAM heritage.)
  - 9rx 1y ago
    Failed language. And for that reason few know it exists.
    - ninetyninenine 1y ago
      It depends on what you consider failure. If you feel popularity is the main metric then golang is successful. Outside of that metric golang is pretty bad. The proof is in the pudding. Here’s a quote from rob pike the creator of golang: “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.” Basically in a nutshell he’s saying they dumbed down golang so it’s useable by beginners. Golang is a step backwards. A failure in language development but a success in popularity. You dumb down a language to a point where the language is so dumbed down it hits the largest demographic. You are part of that demographic. It’s similar to the demographic that voted for trump because he’s not fakeish like all the other candidates.
      - grepexdev 1y ago
        I understand what you are saying here but I think you've missed the point of what Pike was getting at. I think Pike is acknowledging the practical realities of engineering at scale, and intentionally designed Go with simplicity in mind, which leads to more maintainable code and faster onboarding for new devs. I'll also add that outside of the popularity metric, Go is not all bad. Fast compile times, readability, excellent standard library and toolchain, backward compatibility, to name a few things.
        ninetyninenine 1y ago
        >I think Pike is acknowledging the practical realities of engineering at scale, and intentionally designed Go with simplicity in mind, which leads to more maintainable code and faster onboarding for new devs. Doubt it. Read what he wrote. He's literally referring to people without much experience in programming. The stuff you said is literally NOT what he said. >I'll also add that outside of the popularity metric, Go is not all bad. Fast compile times, readability, excellent standard library and toolchain, backward compatibility, to name a few things. I agree with readability and fast compile times.
Thaxll 1y ago
There is no such language, even Rust has many footguns.
- deleted 1y ago
  [deleted]
- 9rx 1y ago
  There is such languages, but they actually failed, so you've probably never heard of them.
- teivah 1y ago
  That's why Manning will consider a 100 Rust Mistakes edition.
grepexdev 1y ago
I don't think Go is particularly esoteric to where these "gotchas" are a big problem. In fact, I would argue that the gotchas are an intentional part of Go's design philosophy. I think it is strange to work in Go when coming from another language because of this, which leads people to think Go sucks.
- 9rx 1y ago
  That may be part of why they think Go sucks, but it is mostly because Go doesn't have many features to paper over poor design decisions. "Advanced" languages let you throw any old gobbledygook at them, and when you finally realize you screwed up, you can just monkey patch (or whatever feature of the day the language has) your way out of it and call it a day. Go is far less forgiving. You have to get the design right or pain will ensue. And pain does ensue for those who try it after being accustomed to having leeway in haphazard design, and thus they conclude Go sucks instead of acknowledging that their design sucks. I mean, Go does suck. Maybe a language should be accommodating to bad designs. But still, those shouting "Go sucks" from the rooftops never seem to be willing to bring introspection into where they might have failed. It's always someone else's fault. (Something not limited to the case of Go, of course)
  - ninetyninenine 1y ago
    Go sucks not because it's accomodating to poor designs. It sucks because it is in itself poorly designed and that leaks over to the design of entire applications. Why have functions return err, nil? Why even allow for a runtime error here? It's a really simple fix. You don't even have to make the language complex to support this. Instead the entire program is littered with holes and if statements you have to check in order to prevent a actual crash
    - deleted 1y ago
      [deleted]
    - 9rx 1y ago
      > Why even allow for a runtime error here? Why not? It doesn't make any difference in practice. Without a complete type system you must write tests to ensure that error conditions (to stay with your example, although this also applies broadly) do what you need of them. If you somehow introduced a runtime error there, your tests would be unable to not notice. Whether your compiler cries or your test suite cries when you screw up is not a meaningful difference. > You don't even have to make the language complex to support this. A complete type system is insanely complex to implement and even harder to write against. Without a complete type system, all you can have is silly half-measures. Maybe the error becomes an optional/result type with forced unwrapping, for example, but you still haven't asserted in the types what needs to happen with the error. So you still need to write the same tests that you had to write anyway. So, other than moving where you discover the problem – from your tests to the compiler – nothing has changed. The half-measures are a cute party trick, I'll give you that, but makes no real difference when actual engineering is taking place. They might, however, give a false sense of security. They might even convince you that you don't need to write tests (you do). Maybe those make for desirable traits?
onionisafruit 1y ago
Most of the mistakes in this book and general mistakes you make when programming aren't about crashes or other runtime errors. They are about writing code that is overly complex or otherwise difficult to maintain.
ljm 1y ago
This guy writes Malbolge and has zero runtime errors because he can't compile it.
- ninetyninenine 1y ago
  Whatever the hell that is. And no. Zero runtime errors and compiles to run.
Yasuraka 1y ago
Did you know that this book is about mistakes that humans make?
- ninetyninenine 1y ago
  But the comment is about languages that prevent mistakes that humans make.