5 ms·

Those deps have to come from somewhere, right? Unless you're actually rolling your own everything, and with languages that don't have package managers what you

Those deps have to come from somewhere, right? Unless you're actually rolling your own everything, and with languages that don't have package managers what you end up doing is just adding submodules of various libraries and running their cmake configs, which is at least as insecure as NPM or Crates.io. Go is a bit unique a it has a really substantial stdlib, so you eliminate some of the necessary deps, but it's also trivial to rely on established packages like Tokio etc, vendor them into your codebase, and not have to worry about it in the future.

Mond_ 9mo ago
The tradeoff Go made is that certain code just cannot be written in it. Its STD exists because Go is a language built around a "good enough" philosophy, and it gets painful once you leave that path.
- deleted 9mo ago
  [deleted]
- deleted 9mo ago
  [deleted]
- ajross 9mo ago
  > The tradeoff Go made is that certain code just cannot be written in it. Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something. > it gets painful once you leave that path Still less painful than being zero-day'd by a supply chain attack.
  - jjav 9mo ago
    > > The tradeoff Go made is that certain code just cannot be written in it. > Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something. What code can you not write in C? Might be painful for some(many) cases, but there is nothing you can't write in C.
    - pjmlp 9mo ago
      SIMD code. And if you are going to point out compiler extensions, they are extensions exactly because ISO C cannot do it.
    - afiori 9mo ago
      not really in-topic but constant-time crypto primitives are considered hard for any compiled language with a lot of optimizations
    - ajross 9mo ago
      > What code can you not write in C? This falls under the "selling somthing" angle I mentioned. Yes yes yes, generality and abstraction are tradeoffs and higher level platforms lack primitives for things the lower levels can do. That is, at best, a ridiculous and specious way to interpret the upthread argument (again c.f. "selling something"). The actual point is that all real systems involve tradeoffs, and one of the core ones for a programming language is "what problems are best solved in this language?". That's not the same question as "what problems CAN be solved in this language", and trying to conflate the two tells me (again) that you're selling something. The applicability of C to problem areas it "can" solve has its own tradeoffs, obviously.
pjerem 9mo ago
> Go is a bit unique a it has a really substantial stdlib It’s not that unique though. I can say that Python and hell, even PHP have pretty complete but also well documented stdlib. Java is meh tier but C# is also pretty good in this aspect. It’s totally a choice for Rust not to have a real stdlib and actually I feel like that would maybe make Rust maybe the best language overall.
- himata4113 9mo ago
  java didn't have an http client (I guess it had a url 'stream') for the longest time and STILL doesn't have an http server.
  - lukaszkorecki 9mo ago
    It has one - it’s been a part of the JDK for a while https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html https://docs.oracle.com/en/java/javase/11/docs/api/jdk.https...
    - himata4113 9mo ago
      sun is typically not available anymore / deprecated even and not available in the JRE or it's early access, but fair point.
      - vips7L 9mo ago
        I get what you’re saying but this is actually a public api in HotSpot. It was provided in JEP 408: https://openjdk.org/jeps/408 https://openjdk.org/jeps/408
        himata4113 9mo ago
        so this is what it feels to be old... but to clarify, this was about a year ago where I struggled to find an auto completion for HttpServer and when I searched it up jdk HttpServer was simply not in the results so I made assumptions that were wrong.
ajross 9mo ago
> Those deps have to come from somewhere, right? Unless you're actually rolling your own everything The point is someone needs to curate those "deps". It's not about rolling your own, it's about pulling standard stuff from standard places where you have some hope that smart people have given thought to how to audit, test, package, integrate and maintain the "deps". NPM and Cargo and PyPI all have this disease (to be fair NPM has it much worse) where it's expected that this is all just the job of some magical Original Author and it's not anyone's business to try to decide for middleware what they want to rely on. And that way lies surprising bugs, version hell, and eventually supply chain attacks. The curation step is a critical piece of infrastructure: thing things like the Linux maintainer hierarchy, C++ Boost, Linux distro package systems, or in its original conception the Apache Foundation (though they've sort of lost the plot in recent years). You can pull from those sources, get lots of great software with attested (!) authorship, and be really quite certain (not 100%, but close) that something in the middle hasn't been sold to Chinese Intelligence. But the Darwinian soup of Dueling Language Platforms all think they can short circuit that process (because they're in a mad evangelical rush to get more users) and still ship good stuff. They can't.
- lesuorac 9mo ago
  I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Personally I like the idea of having a very small STD library so that it's focused (as well as if they need to do something then it has to be allowed by the language unlike say Go Generics or ELM). Personally I think there's just some willful blindness going on here. You should never have been blindly trusting a giant binary blob from the std library. Instead you should have been vendoring your dependencies and at that point it doesn't matter if its 100 crates totaling 100k LOC or a singular STD library totaling 100k LOC; its the same amount to review (if not less because the crates can only interact along `pub` boundaries). [1]: https://docs.rs/regex/latest/regex/ https://docs.rs/regex/latest/regex/ [2]: https://github.com/rust-lang/regex https://github.com/rust-lang/regex
GuB-42 9mo ago
It is more of a cultural thing. Package managers encourage lots of dependencies while programmers using language with no package managers will often pride themselves in having as few dependencies as possible. when you consider the complete graph, it has an exponential effect. It is also common in languages without package managers to rely on the distro to provide the package, which adds a level of scrutiny.
kcexn 9mo ago
Technically it's the same. But behaviorally it's not. When pulling in more dependencies is so easy, it's very hard to slow down and ask the question do we need all of this? Mucking around with cmake adds enough friction that everyone can take a beat for thoughtful decision-making.

Mond_ 9mo ago

The tradeoff Go made is that certain code just cannot be written in it. Its STD exists because Go is a language built around a "good enough" philosophy, and it gets painful once you leave that path.

deleted 9mo ago
[deleted]
deleted 9mo ago
[deleted]
ajross 9mo ago
> The tradeoff Go made is that certain code just cannot be written in it. Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something. > it gets painful once you leave that path Still less painful than being zero-day'd by a supply chain attack.
- jjav 9mo ago
  > > The tradeoff Go made is that certain code just cannot be written in it. > Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something. What code can you not write in C? Might be painful for some(many) cases, but there is nothing you can't write in C.
  - pjmlp 9mo ago
    SIMD code. And if you are going to point out compiler extensions, they are extensions exactly because ISO C cannot do it.
  - afiori 9mo ago
    not really in-topic but constant-time crypto primitives are considered hard for any compiled language with a lot of optimizations
  - ajross 9mo ago
    > What code can you not write in C? This falls under the "selling somthing" angle I mentioned. Yes yes yes, generality and abstraction are tradeoffs and higher level platforms lack primitives for things the lower levels can do. That is, at best, a ridiculous and specious way to interpret the upthread argument (again c.f. "selling something"). The actual point is that all real systems involve tradeoffs, and one of the core ones for a programming language is "what problems are best solved in this language?". That's not the same question as "what problems CAN be solved in this language", and trying to conflate the two tells me (again) that you're selling something. The applicability of C to problem areas it "can" solve has its own tradeoffs, obviously.

pjerem 9mo ago

> Go is a bit unique a it has a really substantial stdlib It’s not that unique though. I can say that Python and hell, even PHP have pretty complete but also well documented stdlib. Java is meh tier but C# is also pretty good in this aspect. It’s totally a choice for Rust not to have a real stdlib and actually I feel like that would maybe make Rust maybe the best language overall.

himata4113 9mo ago
java didn't have an http client (I guess it had a url 'stream') for the longest time and STILL doesn't have an http server.
- lukaszkorecki 9mo ago
  It has one - it’s been a part of the JDK for a while https://docs.oracle.com/en/java/javase/11/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html https://docs.oracle.com/en/java/javase/11/docs/api/jdk.https...
  - himata4113 9mo ago
    sun is typically not available anymore / deprecated even and not available in the JRE or it's early access, but fair point.
    - vips7L 9mo ago
      I get what you’re saying but this is actually a public api in HotSpot. It was provided in JEP 408: https://openjdk.org/jeps/408 https://openjdk.org/jeps/408
      - himata4113 9mo ago
        so this is what it feels to be old... but to clarify, this was about a year ago where I struggled to find an auto completion for HttpServer and when I searched it up jdk HttpServer was simply not in the results so I made assumptions that were wrong.

ajross 9mo ago

> Those deps have to come from somewhere, right? Unless you're actually rolling your own everything The point is someone needs to curate those "deps". It's not about rolling your own, it's about pulling standard stuff from standard places where you have some hope that smart people have given thought to how to audit, test, package, integrate and maintain the "deps". NPM and Cargo and PyPI all have this disease (to be fair NPM has it much worse) where it's expected that this is all just the job of some magical Original Author and it's not anyone's business to try to decide for middleware what they want to rely on. And that way lies surprising bugs, version hell, and eventually supply chain attacks. The curation step is a critical piece of infrastructure: thing things like the Linux maintainer hierarchy, C++ Boost, Linux distro package systems, or in its original conception the Apache Foundation (though they've sort of lost the plot in recent years). You can pull from those sources, get lots of great software with attested (!) authorship, and be really quite certain (not 100%, but close) that something in the middle hasn't been sold to Chinese Intelligence. But the Darwinian soup of Dueling Language Platforms all think they can short circuit that process (because they're in a mad evangelical rush to get more users) and still ship good stuff. They can't.

lesuorac 9mo ago
I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Personally I like the idea of having a very small STD library so that it's focused (as well as if they need to do something then it has to be allowed by the language unlike say Go Generics or ELM). Personally I think there's just some willful blindness going on here. You should never have been blindly trusting a giant binary blob from the std library. Instead you should have been vendoring your dependencies and at that point it doesn't matter if its 100 crates totaling 100k LOC or a singular STD library totaling 100k LOC; its the same amount to review (if not less because the crates can only interact along `pub` boundaries). [1]: https://docs.rs/regex/latest/regex/ https://docs.rs/regex/latest/regex/ [2]: https://github.com/rust-lang/regex https://github.com/rust-lang/regex

GuB-42 9mo ago

It is more of a cultural thing. Package managers encourage lots of dependencies while programmers using language with no package managers will often pride themselves in having as few dependencies as possible. when you consider the complete graph, it has an exponential effect. It is also common in languages without package managers to rely on the distro to provide the package, which adds a level of scrutiny.

kcexn 9mo ago

Technically it's the same. But behaviorally it's not. When pulling in more dependencies is so easy, it's very hard to slow down and ask the question do we need all of this? Mucking around with cmake adds enough friction that everyone can take a beat for thoughtful decision-making.