GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Thorwegian ❄️ (thor@berserker.town)'s status on Sunday, 15-Oct-2023 21:16:02 JST Thorwegian ❄️ Thorwegian ❄️

    inventing a programming language and realising you made mistakes must be a pain. can't fix them without breaking old code.

    In conversation Sunday, 15-Oct-2023 21:16:02 JST from berserker.town permalink
    • Embed this notice
      翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 15-Oct-2023 21:16:00 JST 翠星石 翠星石
      in reply to
      @thor Why would you make another programming language when GNU C exists?

      At most one would want to implement more GNU C extensions really.


      If one made the mistake of designing an inferior language anyway, the mistake should just be fixed and the breaking change noted, so mistake is gone and doesn't keep haunting you - developers can fix their broken code just fine no matter the seething.
      In conversation Sunday, 15-Oct-2023 21:16:00 JST permalink
    • Embed this notice
      翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 15-Oct-2023 21:30:25 JST 翠星石 翠星石
      in reply to
      • Moffin'tosh
      @moffintosh That's an incredible amount of complexity and attack surface, resulting it being impossible to write a non-trivial, secure program in that language.

      I don't really get the allure of static linking 1000 libraries, all full of vulnerabilities mainly due to the complexity of the language.

      Objects were a mistake and are incredibly slow (the CPU intel made with hardware accelerated OOP was very slow) - you either want a field of x bytes, a pointer or a struct, although synthetic sugar around the former are nice.
      In conversation Sunday, 15-Oct-2023 21:30:25 JST permalink
    • Embed this notice
      Moffin'tosh (moffintosh@berserker.town)'s status on Sunday, 15-Oct-2023 21:30:27 JST Moffin'tosh Moffin'tosh
      in reply to
      • 翠星石

      @Suiseiseki @thor RAII + package manager + immutability by default + objects + sum values > C

      In conversation Sunday, 15-Oct-2023 21:30:27 JST permalink
    • Embed this notice
      翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 15-Oct-2023 22:08:36 JST 翠星石 翠星石
      in reply to
      • Moffin'tosh
      @moffintosh >if manual resource management is better, while is in fact worse.
      There's always the option to only use stack memory in C and the compiler does manage that for you automatically.

      There's also dynamic memory manager libraries, but why would you want that?

      Yes, proprietary software developers are unable to write secure programs, as they always write bloated messes that are impossible to secure, who would have though?

      If chrome was written in rust, it'd have more bugs, as rust requires more lines to do most things than in sepples and don't forget that more code == more bugs - maybe less memory bugs, but more of other kinds of bugs with the same security consequences.

      >assume that somehow you'll be able to correctly reimplement the functionality you need
      I don't need to, based GNU hackers have already implemented everything I need in GNU libraries and I just need to call into it.

      Those libraries are well debugged and have an error rate far below the usual - sure mistakes are sometimes made, but the bug soon is fixed and then it's a matter of updating the library in the package manager and the issue is fixed, all thanks to dynamic linking.

      When there's a bug in a rust library, you don't get the bugfix in any software until the package maintainer updates the statically linked version - which will sure take a while with say 200 packages than depend on a vulnerable library (sure rust has dynamic linking, but it doesn't seem to be used often).
      In conversation Sunday, 15-Oct-2023 22:08:36 JST permalink
    • Embed this notice
      Moffin'tosh (moffintosh@berserker.town)'s status on Sunday, 15-Oct-2023 22:08:37 JST Moffin'tosh Moffin'tosh
      in reply to
      • 翠星石

      @Suiseiseki

      That's an incredible amount of complexity and attack surface, resulting it being impossible to write a non-trivial, secure program in that language.

      As if manual resource management is better, while is in fact worse.
      https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues
      https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues
      https://developer.okta.com/blog/2022/03/18/programming-security-and-why-rust#why-does-it-matter

      I don't really get the allure of static linking 1000 libraries, all full of vulnerabilities mainly due to the complexity of the language.

      You assume that somehow you'll be able to correctly reimplement the functionality you need better than projects which dedicate their all to produce sound code. Prove it.
      Also, why don't you also reimplement function calls while you're at it?

      Objects were a mistake and are incredibly slow (the CPU intel made with hardware accelerated OOP was very slow)

      That ain't what all objects are. That's only a kind of object, ie a reference object with dynamic dispatch

      In conversation Sunday, 15-Oct-2023 22:08:37 JST permalink

      Attachments




      1. Domain not in remote thumbnail source whitelist: developer.okta.com
        Why Safe Programming Matters and Why a Language Like Rust Matters
        from @oktadev
        Why safe programming matters and why I would choose Rust for that. We will also talk about Fast and safe programming with Rust.

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.