4 ms·

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 no

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?

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?