>Mainstream language design is basically living with a flatmate that is slowly succumbing to his hoarding tendencies and simply doesn’t realize it.
@sir speaking of which, I'm quite curious to hear more about your own secret project^W^W design opinions.
>> Mainstream language design is basically living with a flatmate that is slowly succumbing to his hoarding tendencies and simply doesn’t realize it.
Something that gets lost in that analogy is that it equates "change" with "additional features/complexity" – but many language changes are about *removing* special cases and *reducing* complexity.
That quote was in the context of #rust, so that's an especially large oversight: most recent changes have (thankfully) simplified the language
@codesections this is not necessarily true. These "simpliciations" just simplify the language on the surface-level, which generally just means making it more concise. This doesn't actually simplify the underlying language - it does the opposite, complexity still increases.
> These "simpliciations" just simplify the language on the surface-level, which generally just means making it more concise. This doesn't actually simplify the underlying language
That's true for some changes.
In other cases, special cases in the compiler/standard library have been removed. Or APIs have been made more consistent, again a simplification.
I'm not saying that's true for *every* change; I'm saying it's true for *some*, and that change is a necessary part of simplification
@codesections @sir I don't use Go nor Rust so I don't really have any skin in the game, but with the Go model they maintain simplicity by not changing the language much. With the Rust model they strive for simplicity by removing/changing features they already added.
Rust is never going to be as simple as Go, but the two languages use diametrically opposed methods for developing the language.
Rust definitely uses the hoarder model, even if cleaning crews come by every so often...
> the Go model they maintain simplicity by not changing the language much. With the Rust model they strive for simplicity by removing/changing features they already added.
That's a good way of looking at it (with the caveat that Rust doesn't break backwards compatibility – code from 1.0.0 runs perfectly on 1.42.0. So it's less about *removing* things than *deprecating* them when there's a simpler way.)
Also, it sounds like some of Go's superficial simplicity comes at the expense of ignoring significant edge cases, which can ultimately result in more complexity in the end https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/
But I don't have anywhere near enough first-hand experience with Go to know if that's true and don't have anything at all against it as a language.
(I think Google's motives for creating it are pretty creepy, but that doesn't say anything about the quality of the language itself)
Hiding real world's quirks behind a layer of abstraction is not simple. It's inherently complex. But if it lifts some complexity off of user's shoulders, that's a trade-off worth considering.
But what they did here, was introducing new quirks, which then need to be worked around by the user.
Complex to use, complex to implement - the worst of both worlds.
Neither one is ever going to be "simple" if you are working beyond the trivial case (designing entirely for people who live where you do and speak the same language).
Even designing for the case of "All US users" you need to worry about encodings and annoyingly complex timezones.
but implementing only bytestrings makes the language/stdlib much simpler, assuming the underlaying OS also uses bytestrings all over the place and knows nothing about unicode (unlike Windows). You're basically pushing all of the encoding handling onto the user, who may decide they don't really need to get into that if all they do is pass strings from one place to another.
Implementing a language any time in the past 10 years (maybe 20 years) and not having UTF8 as a first-class citizen in your strings is begging for pain when it's obviously a necessity for anything higher level than a keyboard, and probably even then.
Imagine you're writing a web service.
You take some strings from a user, put it in a database, then later retrieve them, pass them through HTML escaping, and paste them in the middle of a template from a file.
Characters are multi-byte strings, and have been since Microsoft adopted smartquotes. But even before then you were limited by the encoding you chose.
Just use UTF8 it makes sense everywhere but the ivory tower.
@sir that guy also says he avoids slices and prefers to make a new allocation for every because he doesn't like the syntax, even if that is using more ram and not supporting no_std https://lobste.rs/s/fmcviy/language_designers_stop_using_for#c_r2s4tn
@yeah super cool how you dig up unrelated comments in other threads to trash someone's opinion
@sir i didn't dig it up, i read it before and remembered his nickname
@sir sorry, i thought he is a troll, but now i see he has a github profile, 900 comments and he also wrote that post
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!