Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)B
Posts
2
Comments
242
Joined
2 yr. ago

  • I don't really like the title either, but the article does demonstrate how unfortunate it is that we're effectively locked in to using the ABI at some level of nearly every piece of software.

    That said, there definitely were languages with better type systems prior to the invention of C. Pascal is a frequently-cited example.

  • Sorry, I'm not sure what your point is. I realize that you can almost completely avoid JavaScript, but the point I'm making is merely that there is a real technical limitation that limits the choices developers can make for front-end code, and although WASM is making great strides in breaking down that barrier (something I've been thrilled to see happen, but which is going much more slowly than I had hoped), the limitation is still there. Conversely, such a barrier has never existed on the backend, except in the sense that C limits what all other languages can do.

  • Ehhh, I mean this more strongly. I've never met people more in denial about language design problems than C++ adherents. (Though admittedly I haven't spent much time talking to Lisp fans about language design.)

  • I see where you're coming from, but no matter how many null pointer exceptions there are in Java code, you're almost always protected from actually wrecking your system in an unrecoverable way; usually the program will just crash, and even provide a relatively helpful error message. The JVM is effectively a safety net, albeit an imperfect one. Whereas in C++, the closest thing you have to a safety net, i.e. something to guarantee that invalid memory usage crashes your program rather than corrupting its own or another process's memory, is segfaults, which are merely a nicety provided by common hardware, not required by the language or provided by the compiler. Even then, with modern compiler implementations, undefined behavior can cause an effectively unlimited amount of "bad stuff" even on hardware that supports segfaults.

    Additionally, most languages with managed runtimes that existed when Java was introduced didn't actually have a static type system. In particular, Perl was very popular, and its type system is...uh...well, let's just say it gives JavaScript some serious competition.

    That said, despite this grain of truth in the statement, I think the perception that Java is comparatively robust is primarily due to Java's intense marketing (particularly in its early years), which strongly pushed the idea that Java is an "enterprise" language, whatever that means.

  • I mean, if you're talking about CVEs permitting attackers to get control of the hardware of lots of systems, then yes, I agree

  • There were memory-safe languages long before C was invented, though; C was widely considered "dangerous" even at the time.

  • WASM has no native ability to access most web APIs, including the DOM. JavaScript is literally unavoidable on the front end.

  • Genuine question: if you're writing a new CLI utility, why not Rust? This is arguably where Rust has most excelled, most famously with ripgrep.

  • Oh, trust me, Qt is still primarily C++. It's effectively a massive set of C++ libraries.

  • I mean to be fair, that's a pretty useful tool.

  • Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there's a space before the parentheses?

    There are definitely some major issues with Scala.

  • I was a professional C++ developer for several years, and came to the conclusion that any professional C++ developers who don't acknowledge its flaws have a form of Stockholm Syndrome.

  • Well, except "robust", unless you have very strict code standards, review processes, and static analysis.

    (And arguably it's never elegant, though that's almost purely a matter of taste.)

  • I've met people with C++ Stockholm Syndrome, and I think their trajectory is different. There's no asymptotic approach toward zero; their appreciation just grows or stays steady, even decades into their career.

  • The logo and "join our Discord" text are more than half cut off for me. Is that the original cropping, or is it a client (Jerboa) issue?

  • Rust is extremely geared toward maintainability at the cost of other values such as learnability and iteration speed. Whether it's successful is of course somewhat a matter of opinion (at least until we figure out how to do good quantitative studies on software maintainability), and it is of course possible to write brittle Rust code. But it does make a lot of common errors (including ones Go facilitates) hard or impossible to replicate.

    It also strongly pushes toward specific types of abstractions and architectural decisions, which is pretty unique among mainstream languages, and is of course a large part of what critics dislike about it (since that's extremely limiting compared to the freedom most languages give you). But the ability for the compiler to influence the high-level design and code organization is a large part of what makes Rust uniquely maintainability-focused, at least in theory.

  • At the time, she called it a "compiler", but its function was more akin to what we'd call a linker or assembler today.

  • Do you mean Grace Hopper, who wrote the first assembler?