13 ms·

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted b

Rust and Go seemed to initially want to target C programmers [1], but ended up capturing users from higher level languages – even Python and such – who wanted better performance and more control, because they had so many affordances. Hare clearly isn't like that: it's _actually_ aimed at (FOSS) C programmers, almost stubbornly so, and isn't going to appeal to many others. But for those people I can see C-with-tagged-unions being an improvement, and there's value in finding the minimal diff that makes a language better. [1] Remember when Go called itself a "systems programming language"? Neither community seems to use this phrase any more, though.

celeritascelery 4y ago
Rust still considers itself a “systems programming language” . They are moving Rust into the Linux kernel and android drivers. It doesn’t get any more “systems programming” then that. But you are correct about go, it doesn’t give the programmer enough control to be used at that level.
- 0des 4y ago
  - capableweb 4y ago
    I have no fists in this fight, but wanted some clarification. Are you saying the reason Rust is now being integrated into the Kernel instead of Golang is because of the success of evangelists, not because of the merit of the language itself? I'm not involved in Kernel development myself, but if I was, I'd see your statement as a big hit in the face that we don't know what we're doing, if they (Kernel developers) are being sold to use Rust because of marketing, not because of the value of the language.
    - 0des 4y ago
      Its not existing kernel devs that suddenly switched to rust. It is the incoming cohort.
      - capableweb 4y ago
        For someone to start using a new language in the Kernel, some of the existing "guard" has to approve it, meaning they've investigated if it's fit or not. Or can anyone willy-nilly contribute to the Kernel without anyone approving changes going into the main branch?
        0des 4y ago
        The existing guard doesnt have to prove anything, theyre on the way out. C is a tough language and not a lot of people have the patience for it, and even less people are being forced to learn it like the rest of us in school. As this segment of the community ages out, we arent going to see more code written in C, so we have the new group with Rust, recreating all of the same issues in effigy of C, but with better string handling. It's not like it is terrible code, but as Nikola Tesla used to say "it is what it is, and it aint what it aint". You see how parties completely unrelated to the fight got Linus ousted? That was not based on technical merit, it was due to the changing tide regarding outcomes when people are offended/mistreated. Rust has significant overlap with the community that gave way to this, don't think it is 100% open arms and welcomes, because that is not the case. Every day we stray further from God.
        Alekhine 4y ago
        Damn right I don't have the patience for C. Writing anything in C properly takes a long time, and even then bugs are usually found after. Compare and contrast Rust, where the code I write will usually just work. I don't need to be extra careful with it because the compiler is strict. You can say that this is indicative of some flaw in my character or whatever, but, uh, I don't care.
        mplanchard 4y ago
        Miguel Ojeda is doing the lion’s share of the work here, and he is a kernel maintainer: https://ojeda.dev/ https://ojeda.dev/ The person you’re replying to is either deeply misinformed or trolling
    - jlokier 4y ago
      I must admit, I am still surprised to see Rust gaining acceptance when the reasons Linus gave in 2010 for rejecting C++ in the kernel appear to apply to Rust equally well. I can't think of any of the pragmatic points which he raised which doesn't apply to Rust. For example, the arguments against namespaces and function overloading, high context dependency, easy of understanding and in favour of C's simplicity in general. My guess (it's just a guess) is that his position has shifted over time to consider a higher-abstraction, higher-complexity language, as development methods and the complexity and professionalising of the kernel have changed since then.
  - antonvs 4y ago
    My understanding is that Go has several features that make it unsuitable as a Linux kernel language, e.g. automatic garbage collection, its concurrency model, and possibly the nature of its runtime dependency (which is related to the previous two items.)
    - 0des 4y ago
      Garbage collection is not mandatory, and the concurrency model is often hailed as one of Gos best features.
      - ddevault 4y ago
        I like Go and I use it often. I also work on kernels. Go is not suitable for writing kernels.
        0des 4y ago
        Im choosing to imagine that you typed this with one hand behind your back with some fingers crossed Drew.
      - tialaramex 4y ago
        A best feature it may well be, but it requires infrastructure and the OS kernel provides that infrastructure it doesn't depend on it. Rust for Linux relies on the fact that Rust is deliberately structured in layers so that the bottom layer doesn't need that infrastructure, this was needed to make embedded Rust practical, but it's also important for Linux. Actually, Linux needs even more than Rust had initially, but that's driven further improvements to Rust itself. You could add a layer to do all this lifting (that's what e.g. a Java OS does) but that's not going to fly in Linux, which is one reason why Go for Linux isn't a thing whereas Rust for Linux is.
      - forgotpwd16 4y ago
        >Garbage collection is not mandatory What does that mean? Isn't GC a fundamental part of Go?
- lawl 4y ago
  > But you are correct about go, it doesn’t give the programmer enough control to be used at that level. What I like about go is that I can go full unsafe.Pointer if i want to, and do whatever I want. The other thing I really like, is that they did such a good job discouraging it that i frequently hear people complain about go having pointers but not even letting you have fun with them. The problem isn't that go doesn't give you enough control, the problem is that it's garbage collected. And you'd need to work around the GC. It's doable and people have done it though. Good idea? Maybe not. Still waiting for someone to make "go but with ownership and borrow checker"
  - mumblemumble 4y ago
    I think that being garbage collected is exactly the control problem in question. I'm no a systems programmer unless you count hobby microcontroller projects, but my understanding is that, when a systems programmer is talking about control, they tend to be talking first and foremost about keeping tight limits on memory usage. Pointers and suchlike just happen to be key tools that help you do that.
    - pjmlp 4y ago
      One doesn't prevent the other, https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/en/solutions/innovative-security-...
  - deleted 4y ago
    [deleted]
  - ansible 4y ago
    > Still waiting for someone to make "go but with ownership and borrow checker" That would have interested me more a few years ago, but I'm deeply invested in Rust these days. Is that all you'd change about Go? One of the reasons I moved was the error handling and lack of generics. Go has fixed the latter, but I can't stand not having Result<> and Option<> these days. The '?' is awesome too.
    - 4y ago
usefulcat 4y ago
> there's value in finding the minimal diff that makes a language better. OTOH, if the differences are minimal, then the benefits are likely to be correspondingly minimal. And either way, the compiler/interpreter for a relatively new language will by definition be much less battle-tested. Practically speaking, I think if a new language is going to compete with C, it needs to offer more than a few incremental improvements.
pjmlp 4y ago
Mostly because writing compilers, linkers, GC implementations, GPU debuggers, OS emulation layers, distributed orchestration systems, unikernels, isn't considered systems programming by the crowd that is allowed to judge it.
avgcorrection 4y ago
No. Rust always wanted to appeal to C++ programmers moreso than C programmers.

celeritascelery 4y ago

Rust still considers itself a “systems programming language” . They are moving Rust into the Linux kernel and android drivers. It doesn’t get any more “systems programming” then that. But you are correct about go, it doesn’t give the programmer enough control to be used at that level.

0des 4y ago
- capableweb 4y ago
  I have no fists in this fight, but wanted some clarification. Are you saying the reason Rust is now being integrated into the Kernel instead of Golang is because of the success of evangelists, not because of the merit of the language itself? I'm not involved in Kernel development myself, but if I was, I'd see your statement as a big hit in the face that we don't know what we're doing, if they (Kernel developers) are being sold to use Rust because of marketing, not because of the value of the language.
  - 0des 4y ago
    Its not existing kernel devs that suddenly switched to rust. It is the incoming cohort.
    - capableweb 4y ago
      For someone to start using a new language in the Kernel, some of the existing "guard" has to approve it, meaning they've investigated if it's fit or not. Or can anyone willy-nilly contribute to the Kernel without anyone approving changes going into the main branch?
      - 0des 4y ago
        The existing guard doesnt have to prove anything, theyre on the way out. C is a tough language and not a lot of people have the patience for it, and even less people are being forced to learn it like the rest of us in school. As this segment of the community ages out, we arent going to see more code written in C, so we have the new group with Rust, recreating all of the same issues in effigy of C, but with better string handling. It's not like it is terrible code, but as Nikola Tesla used to say "it is what it is, and it aint what it aint". You see how parties completely unrelated to the fight got Linus ousted? That was not based on technical merit, it was due to the changing tide regarding outcomes when people are offended/mistreated. Rust has significant overlap with the community that gave way to this, don't think it is 100% open arms and welcomes, because that is not the case. Every day we stray further from God.
        Alekhine 4y ago
        Damn right I don't have the patience for C. Writing anything in C properly takes a long time, and even then bugs are usually found after. Compare and contrast Rust, where the code I write will usually just work. I don't need to be extra careful with it because the compiler is strict. You can say that this is indicative of some flaw in my character or whatever, but, uh, I don't care.
      - mplanchard 4y ago
        Miguel Ojeda is doing the lion’s share of the work here, and he is a kernel maintainer: https://ojeda.dev/ https://ojeda.dev/ The person you’re replying to is either deeply misinformed or trolling
  - jlokier 4y ago
    I must admit, I am still surprised to see Rust gaining acceptance when the reasons Linus gave in 2010 for rejecting C++ in the kernel appear to apply to Rust equally well. I can't think of any of the pragmatic points which he raised which doesn't apply to Rust. For example, the arguments against namespaces and function overloading, high context dependency, easy of understanding and in favour of C's simplicity in general. My guess (it's just a guess) is that his position has shifted over time to consider a higher-abstraction, higher-complexity language, as development methods and the complexity and professionalising of the kernel have changed since then.
- antonvs 4y ago
  My understanding is that Go has several features that make it unsuitable as a Linux kernel language, e.g. automatic garbage collection, its concurrency model, and possibly the nature of its runtime dependency (which is related to the previous two items.)
  - 0des 4y ago
    Garbage collection is not mandatory, and the concurrency model is often hailed as one of Gos best features.
    - ddevault 4y ago
      I like Go and I use it often. I also work on kernels. Go is not suitable for writing kernels.
      - 0des 4y ago
        Im choosing to imagine that you typed this with one hand behind your back with some fingers crossed Drew.
    - tialaramex 4y ago
      A best feature it may well be, but it requires infrastructure and the OS kernel provides that infrastructure it doesn't depend on it. Rust for Linux relies on the fact that Rust is deliberately structured in layers so that the bottom layer doesn't need that infrastructure, this was needed to make embedded Rust practical, but it's also important for Linux. Actually, Linux needs even more than Rust had initially, but that's driven further improvements to Rust itself. You could add a layer to do all this lifting (that's what e.g. a Java OS does) but that's not going to fly in Linux, which is one reason why Go for Linux isn't a thing whereas Rust for Linux is.
    - forgotpwd16 4y ago
      >Garbage collection is not mandatory What does that mean? Isn't GC a fundamental part of Go?
lawl 4y ago
> But you are correct about go, it doesn’t give the programmer enough control to be used at that level. What I like about go is that I can go full unsafe.Pointer if i want to, and do whatever I want. The other thing I really like, is that they did such a good job discouraging it that i frequently hear people complain about go having pointers but not even letting you have fun with them. The problem isn't that go doesn't give you enough control, the problem is that it's garbage collected. And you'd need to work around the GC. It's doable and people have done it though. Good idea? Maybe not. Still waiting for someone to make "go but with ownership and borrow checker"
- mumblemumble 4y ago
  I think that being garbage collected is exactly the control problem in question. I'm no a systems programmer unless you count hobby microcontroller projects, but my understanding is that, when a systems programmer is talking about control, they tend to be talking first and foremost about keeping tight limits on memory usage. Pointers and suchlike just happen to be key tools that help you do that.
  - pjmlp 4y ago
    One doesn't prevent the other, https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/en/solutions/innovative-security-...
- deleted 4y ago
  [deleted]
- ansible 4y ago
  > Still waiting for someone to make "go but with ownership and borrow checker" That would have interested me more a few years ago, but I'm deeply invested in Rust these days. Is that all you'd change about Go? One of the reasons I moved was the error handling and lack of generics. Go has fixed the latter, but I can't stand not having Result<> and Option<> these days. The '?' is awesome too.
  - 4y ago

usefulcat 4y ago

> there's value in finding the minimal diff that makes a language better. OTOH, if the differences are minimal, then the benefits are likely to be correspondingly minimal. And either way, the compiler/interpreter for a relatively new language will by definition be much less battle-tested. Practically speaking, I think if a new language is going to compete with C, it needs to offer more than a few incremental improvements.

pjmlp 4y ago

Mostly because writing compilers, linkers, GC implementations, GPU debuggers, OS emulation layers, distributed orchestration systems, unikernels, isn't considered systems programming by the crowd that is allowed to judge it.

avgcorrection 4y ago

No. Rust always wanted to appeal to C++ programmers moreso than C programmers.