6 ms·

> I believe they have now relaxed this opinion Or is it that scientific computing is starting to realize that it can benefit from a systems programming languag

> I believe they have now relaxed this opinion Or is it that scientific computing is starting to realize that it can benefit from a systems programming language? Scripting langages are great for exploratory work, but if you want to put to work into production, scripting starts to really show its limitations. There is a reason systems languages exist. There is good reason why they both exist. They are different tools for different jobs.

coldtea 3y ago
>Or is it that scientific computing is starting to realize that it can benefit from a systems programming language? Can't be it, since a huge percentage of scientific computing is done with a scripting language. A systems programming language is still good for the backend libraries of scientific computing - but Go has zero share of that.
- randomdata 3y ago
  A huge percentage of scientific computing is scripting in nature. It would be silly to use anything other than a scripting language. But not all. Whether or not it is Go that gets the job, a systems language of some kind would be beneficial in those circumstances.
  - galaxyLogic 3y ago
    There are 2 conflicting goals: 1) Having a language in which it is easy to express and try out ideas and 2) Producing fast and safe programs. A scripting language would seem to be good for the exploratory scientific research, because of that. Whereas when you need to create a performant library that can do heavy crunching with reproducible results on any platform you need the other. The questions is: Do you know what you want to implement, or is that still an open question?
    - randomdata 3y ago
      No doubt it starts as an open question and slowly moves towards knowing. Which isn't really much of a conflict. You can prove out your thoughts in a scripting language, and after the dust has settled you can move the workload to a systems language. Different jobs, different tools. I guess if you're one of those weird religious types that insist there is only one true God (read: programming language) you might feel conflict, but nobody else cares.
      - galaxyLogic 3y ago
        > Different jobs, different tools And possibly different programmers. Say your a (non-computer-) scientist. It is not (typically) part of your job to learn Rust or Haskell. You might want to learn Rust if you are so inclined but many scientists are not.
        randomdata 3y ago
        I'm sure there are exceptions, but generally speaking, do scientists ever really end up working on systems? Anecdotally, I work with a lot of scientists and they only write scripts. When systems are needed, they hand it off to the development team. Anyone can fumble through scripting, but there is a lot more to think about when building systems, and that's probably not something most scientists want to put effort into – for the same reasons they probably don't want to learn Rust. Realistically, learning Rust is the easiest part of becoming a systems programmer. But there is little incentive to learn any system language if your workload is always scripting in nature. You are going to, rightfully, reach for a scripting language.
    - coldtea 3y ago
      >There are 2 conflicting goals: 1) Having a language in which it is easy to express and try out ideas and 2) Producing fast and safe programs. Why are they "conflicting"? Common Lisp could do both quite well.
      - galaxyLogic 3y ago
        Because different languages give different focus to different features. I'm not saying there can't be a language that supports multiple goals well, but it's a bit like" Jack of All Trades".
  - aragilar 3y ago
    But Go lacks a good FFI story (see CGo discussions), so Go has no hope here.
    - randomdata 3y ago
      What are you referring to? The only active, related discussion I am aware of is about the high call overhead imposed by the gc compiler. Of course, other Go compilers have different calling conventions. tinygo, for example, can call C functions from Go about as fast as C can call C functions. So that isn't really a Go issue, just a specific compiler implementation issue. And as you know (it's in the link!), the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler. To equate gc and Go as being one and the same would be quite faulty. So obviously you are not talking about that one. What else are people discussing?
      - coldtea 3y ago
        >So obviously you are not talking about that one. Obviously? Not of the above rings obvious to me. A "specific compiler implementation issue" when said compiler is the compiler that 99% of Go users use, can just as well be called a Go issue. Whether "the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler" is basically irrelevant in praxtice, since people using/interested in Go predominantly mean and use a specific compiler (unlike with C++ where they might use one of several available compilers equally likely). >To equate gc and Go as being one and the same would be quite faulty. No, it would be the most pragmatic thing to do. De jure and de facto and all that.
        randomdata 3y ago
        I appreciate your dedication to reminding us that your original comment was posted without any research or thought, but it remains that the Go project itself, along with other third-parties, provide different FFI solutions so that you can pick the one that best suits your circumstances. There is no one-size-fits-all solution. 99% of Go users don't need an FFI story at all. They can choose a compiler on different merits. If you have an FFI story to consider, then it is logical that you will need to evaluate your choices on different attributes and very well might find that the compiler 99% of users with different problems won't match your own. gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing. What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for?
Guvante 3y ago
Except what does Go get for ditching the REPL? It already has a substantial runtime (the usual pain of an REPL)
- randomdata 3y ago
  What would it gain? REPLs make perfect sense for scripting problems, but when you would you ever use it for systems problems?
  - dekhn 3y ago
    often when I am developing systems code or RPC client code, I sit in a REPL and make repeated ad-hoc calls to various functions, building up various bits of state (I started using python long before Jupyter). I find this much more intuitive than writing code, compiling it, executing it, going back to the editor, changing the code, re-running it with something that loads a bunch of data, just so I can answer a question about the runtime behavior of the system I'm working with.
    - randomdata 3y ago
      There is certainly something to be said about being able to answer questions about another system by poking at it, but that is a scripting task. You would be better served by a scripting language. And, as it happens, most scripting languages come with REPLs. That is a solved problem that was solved long before Go was ever imagined. Just because you are building a particular systems program does not mean everything you do has to be a systems problem. And, really, if you don't exactly know what you're building, it is probably too soon to consider any of it a systems problem.
  - Guvante 3y ago
    You say systems problems like Go is for embedded work. Half the things I have seen replaced Python scripts. Seeing what your internal state is after taking X action is exactly what REPLs are good at...
    - 3y ago

coldtea 3y ago

>Or is it that scientific computing is starting to realize that it can benefit from a systems programming language? Can't be it, since a huge percentage of scientific computing is done with a scripting language. A systems programming language is still good for the backend libraries of scientific computing - but Go has zero share of that.

randomdata 3y ago
A huge percentage of scientific computing is scripting in nature. It would be silly to use anything other than a scripting language. But not all. Whether or not it is Go that gets the job, a systems language of some kind would be beneficial in those circumstances.
- galaxyLogic 3y ago
  There are 2 conflicting goals: 1) Having a language in which it is easy to express and try out ideas and 2) Producing fast and safe programs. A scripting language would seem to be good for the exploratory scientific research, because of that. Whereas when you need to create a performant library that can do heavy crunching with reproducible results on any platform you need the other. The questions is: Do you know what you want to implement, or is that still an open question?
  - randomdata 3y ago
    No doubt it starts as an open question and slowly moves towards knowing. Which isn't really much of a conflict. You can prove out your thoughts in a scripting language, and after the dust has settled you can move the workload to a systems language. Different jobs, different tools. I guess if you're one of those weird religious types that insist there is only one true God (read: programming language) you might feel conflict, but nobody else cares.
    - galaxyLogic 3y ago
      > Different jobs, different tools And possibly different programmers. Say your a (non-computer-) scientist. It is not (typically) part of your job to learn Rust or Haskell. You might want to learn Rust if you are so inclined but many scientists are not.
      - randomdata 3y ago
        I'm sure there are exceptions, but generally speaking, do scientists ever really end up working on systems? Anecdotally, I work with a lot of scientists and they only write scripts. When systems are needed, they hand it off to the development team. Anyone can fumble through scripting, but there is a lot more to think about when building systems, and that's probably not something most scientists want to put effort into – for the same reasons they probably don't want to learn Rust. Realistically, learning Rust is the easiest part of becoming a systems programmer. But there is little incentive to learn any system language if your workload is always scripting in nature. You are going to, rightfully, reach for a scripting language.
  - coldtea 3y ago
    >There are 2 conflicting goals: 1) Having a language in which it is easy to express and try out ideas and 2) Producing fast and safe programs. Why are they "conflicting"? Common Lisp could do both quite well.
    - galaxyLogic 3y ago
      Because different languages give different focus to different features. I'm not saying there can't be a language that supports multiple goals well, but it's a bit like" Jack of All Trades".
- aragilar 3y ago
  But Go lacks a good FFI story (see CGo discussions), so Go has no hope here.
  - randomdata 3y ago
    What are you referring to? The only active, related discussion I am aware of is about the high call overhead imposed by the gc compiler. Of course, other Go compilers have different calling conventions. tinygo, for example, can call C functions from Go about as fast as C can call C functions. So that isn't really a Go issue, just a specific compiler implementation issue. And as you know (it's in the link!), the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler. To equate gc and Go as being one and the same would be quite faulty. So obviously you are not talking about that one. What else are people discussing?
    - coldtea 3y ago
      >So obviously you are not talking about that one. Obviously? Not of the above rings obvious to me. A "specific compiler implementation issue" when said compiler is the compiler that 99% of Go users use, can just as well be called a Go issue. Whether "the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler" is basically irrelevant in praxtice, since people using/interested in Go predominantly mean and use a specific compiler (unlike with C++ where they might use one of several available compilers equally likely). >To equate gc and Go as being one and the same would be quite faulty. No, it would be the most pragmatic thing to do. De jure and de facto and all that.
      - randomdata 3y ago
        I appreciate your dedication to reminding us that your original comment was posted without any research or thought, but it remains that the Go project itself, along with other third-parties, provide different FFI solutions so that you can pick the one that best suits your circumstances. There is no one-size-fits-all solution. 99% of Go users don't need an FFI story at all. They can choose a compiler on different merits. If you have an FFI story to consider, then it is logical that you will need to evaluate your choices on different attributes and very well might find that the compiler 99% of users with different problems won't match your own. gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing. What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for?

Guvante 3y ago

Except what does Go get for ditching the REPL? It already has a substantial runtime (the usual pain of an REPL)

randomdata 3y ago
What would it gain? REPLs make perfect sense for scripting problems, but when you would you ever use it for systems problems?
- dekhn 3y ago
  often when I am developing systems code or RPC client code, I sit in a REPL and make repeated ad-hoc calls to various functions, building up various bits of state (I started using python long before Jupyter). I find this much more intuitive than writing code, compiling it, executing it, going back to the editor, changing the code, re-running it with something that loads a bunch of data, just so I can answer a question about the runtime behavior of the system I'm working with.
  - randomdata 3y ago
    There is certainly something to be said about being able to answer questions about another system by poking at it, but that is a scripting task. You would be better served by a scripting language. And, as it happens, most scripting languages come with REPLs. That is a solved problem that was solved long before Go was ever imagined. Just because you are building a particular systems program does not mean everything you do has to be a systems problem. And, really, if you don't exactly know what you're building, it is probably too soon to consider any of it a systems problem.
- Guvante 3y ago
  You say systems problems like Go is for embedded work. Half the things I have seen replaced Python scripts. Seeing what your internal state is after taking X action is exactly what REPLs are good at...
  - 3y ago