5 ms·
> The current software engineering paradigm has no meaningful answer to this The answer is to stop using garbage software written in garbage languages. Of cour
by wyager 4y ago
> The current software engineering paradigm has no meaningful answer to this
The answer is to stop using garbage software written in garbage languages. Of course the current environment is too high-time-preference for this to be economical in many industries.
We have lightweight-to-heavyweight formal systems which can almost completely or literally completely eliminate issues of the type seen with log4j, but due to the marginally higher up-front cost of using such systems, only firms with some combination of high stakes, low time preference, and foresight end up using them.
- throwaway23234 4y agoWhat counts as a garbage language? Java guys will tell you it's rust or go, go guys will tell you it's java or rust, rust guys will tell you it's java and go.
- recursive 4y ago> What counts as a garbage language? I assume it's one with GC.
- joebob42 4y agoWouldn't it be one without gc? Gc collects the garbage and disposes of it, whereas in other languages it just piles up :D
- wyager 4y agoI'm not any of those guys, and of those 3 rust is by far the least garbage. Garbagicity is a spectrum.
- shikoba 4y agoI was sure reading your first post that you will propose rust. Rust users never cease to amaze me.
- sebzim4500 4y agoTo be fair there was also a significant chance he would think Rust was garbage and only assembly (or if you are lucky, C) are acceptable languages.
- shikoba 4y agoYou still don't know how to spot them :). The borrow checker is a great invention, but for them it's the holy grail that will save us from bugs. Like in the past people thought that GC was the solution to every problems. Youngsters must learn, we have to be patient.
- wyager 4y agoI'm not a "rust user" any more than I'm a java user (less, in fact). Your heuristic is probably picking up on the fact that people who pay attention to things like this tend to have correlated opinions.
- EdwardDiego 4y agoJava person here. Yeah, Go looks a bit crufty, but they're gradually undoing the earlier opinionated choices that make me think that (Who needs generics? Who needs to tune the GC? Oh, our users do), but nah, we mainly hate on Scala when we have to maintain anything with Scala deps, just that damn ABI that's never compatible.
- ClumsyPilot 4y ago'software written in garbage languages' well, back to the mainframe it is then
- gnulinux 4y agoQuite the opposite, we have very safe languages now in 2022. Any software that's not written in Rust or Haskell has to explain the trade-off of being written in an unsafe language. Of course the industry will still use unsafe languages, but we lack the awareness that we're intentionally writing garbage software in garbage languages that should be treated as radioactive material in any context where safety matters. If you pick a language without understanding this point, you're part of the problem. If you pick an unsafe language understanding that X matters more than safety, then you saw all of this coming and you made an educated gamble.
- ClumsyPilot 4y agoWe've had safe lnaguages for decades - for example Ada https://www.adacore.com/about-ada https://www.adacore.com/about-ada
- stonemetal12 4y agoThese Log4j issues aren't real hardcore exploits. They wrote a logger that could run arbitrary code, then were surprised when attackers figured out how to run arbitrary code. It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure.
- alcover 4y agoIt isn't a language problem Exactly. This flamy sub-thread has no point here.
- kelnos 4y ago> It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure. I'd prefer that the "fix" for this isn't "require that millions of developers around the world all change their behavior, and never screw up in the future". Languages can still protect against these sorts of bugs. Effect systems can describe as a part of the type system or function signature what kinds of things a function can do. For example, you could have a logging function where you know that the only side-effect is that it can write to stdout or stderr, or a file. Running arbitrary commands would not be allowed, and would cause the program to fail to compile. As a real-world example, I've used the Slick SQL library in Scala, and the query type has a type parameter for whether the query is an read or a write. It's easy to build a simple abstraction on top of your data layer to never allow a write to go through, for example, if that's something that's useful to prevent bugs. I think one thing I did with that was set things up so callers could not accidentally write to MySQL replicas; only reads could go to them, and writes had to go to the primaries. Granted, it takes discipline to build and use such a system, especially one that has such fine-grained effects. (I would expect most are more like a binary "does not do I/O" or "does I/O".)