This is a bit confused. You're saying `float`, but a float comes with NaN by default. Any float can take NaN values.
If you actually want the compiler to check this on the level of the type system, it'd have to be `NonNaNFloat | NaN`. Then you can check which one you have and continue with a float that is guaranteed to not be NaN.
But (importantly) a NonNaNFloat is not the same as a float, and this distinction has to be encoded in the type system if you want to take this approach seriously. This distinction is NOT supported by most type systems (including Rust's std afaik, fwiw). It's similar to Rust's NonZero family of types.
You keep talking about Rust, but I'm not referring to Rust. This thread is discussing a (hypothetical, as-yet undeveloped) type system for a new version of Nim.
Hypothetically, no, the float type would not admit NaNs. You would be prevented from storing NaNs in them explicitly, and operations capable of producing NaNs would produce a `float | nan` type that is distinct from float, and can't be treated like float until it's checked for NaN.
And I'm not sure why it's being discussed as though this is some esoteric language feature. This is precisely the way non-nullable types work in languages like Kotlin and TypeScript. The underlying machine representation of the object is capable of containing null values, yes, but the compiler doesn't let you treat it as such (without certain workarounds).
Huh? Rust is just an example here. What I am saying is that you're just redefining float to mean NonNaNFloat.
This is fine, I guess, but it will cause a bunch of problems since e.g. Division of two floats has to be able to return NaNs. At that point you either need to require a check to see if the value is NaN (inconvenient and annoying) or allow people to just proceed. Not sure I am exactly sold on this so far.
Nobody's trying to sell you on anything. You again seem to be out-of-context with respect to the discussion being had.
The parent commenter stated that sum types work differently from a hypothetical float / NaN split, because compilers can't always "understand the code fully enough" to enforce checks. I simply responded that that is not true in principle, since you could just treat non-nan floats the same way that many languages treat non-null types.
Indeed, everything you're describing about non-nan floats applies equally to sum types - you can't operate on them unless you pattern match. You're highlighting the exact point I'm trying to make!
The fact that you consider this system "inconvenient", is entirely irrelevant to this discussion. Maybe the designer of Nim simply cares more about NaN-safety than you or I do. Who knows. Regardless, the original statement (that
sum types and non-nan floats can't work the same way) is incorrect.
Unfortunately, Rust doesn't seem to be smart enough to represent `Option<NotNan<f64>>` in 8 bytes, even though in theory it should be possible (it does the analogous thing with `Option<NonZero<u64>>`).
Yeah, people be random sometimes, internet can be hostile. But why is @GrapheneOS still engaging? After 2-3 messages you won't really improve on anything, and their goal is probably to just suck energy, so the only way to win is to not engage at all. Also ruins the conversations about the the content, instead people end up focusing on that crazy-on-one-side exchange.
Internet 101: don't provide sustenance to the creatures who sometimes live under bridges.
It's often possible to get through to people who are initially hostile. They were friendlier than a lot of the Free Software community on Mastodon and didn't even link to harassment content. They burned themselves out and stopped on their own so they're still not blocked.
> It's often possible to get through to people who are initially hostile
If there is a hint of the person actually reading your messages, then yeah, I'd agree in many cases. But read the messages this person posted, it is clear after just a couple of messages that they're not responding to anything @GrapheneOS actually wrote, they're spewing nonsense into the ether.
Personally, I don't think it's worth trying to save everybody, focus on people who are actually willing to listen, and have a conversation instead.
It's because GrapheneOS is very black and white and reactive in their communication. 4chan found them ages ago and there's a daily GrapheneOS Thread on /g/.
On most platforms if a post's author replies to a reply, that will boost it above others. Admittedly I don't use mastodon and can't spot how many replies that post actually received (I see 25 boosts, 0 quotes, 21 favourites, but not the number of replies/comments)
Goes to show the fundamental UX design flaws of Mastodon and Twitter. If it were on Hacker News or Reddit it would be instantly downvoted. Even if the OP replied to the comment, it would still be buried. But because of how Mastodon and Twitter are designed, if the OP replies it will get amplified.
We can block accounts from grapheneos.social to stop their posts being shared by our instance. If they posted a link to harassment content, all their replies and the replies to those in the linked page would be gone. Our chat rooms have a much lower bar for bans because it's disruptive for everyone using it. There's currently someone raiding our Matrix chat rooms spamming images including CSAM because they're angry we banned them for their harmful behavior in our rooms. Our moderation team turned on the automation for removing this which previously led to someone escalating to a swatting attack when they couldn't spam gore and CSAM anymore. It's best not to ban people if they're not really causing any harm because we have enough people targeting us with libel, harassment and even violence already.
100% state bot. I wouldn't even think it was just France, other state actors would love to see GrapheneOS go down as well. How dare citizens have technology we can't access.
It doesn't look like a troll. It's best not to do something which could cause them to escalate to obsessive harassment. It could potentially turn into more violence in the form of swatting attacks or something else.
> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
Most of these will usually make a program crash. Crashes are testable and not a memory safety issue. Exception handling was created specifically to deal with this.
Use after free is generally VERY hard to exploit. Double free can corrupt data structures more with control. Use after free is basically at the mercy of the allocator and program state, where whatever gets written to the same memory address may or may not be relevant.
There is a reason why most vulnerabilities these days are either higher level logic bugs, or things that require code execution on the machine.
Pet peeves nitpick: it's not even a tuple. Go doesn't have tuples. It just has special-cased "multiple return values", which means that it's often impossible to just stuff the return of a function call (error value and all) into any data structure to aggregate them. You just can't do without first defining a struct since tuples don't exist in Go.
? Putting a program into a safe container or isolation boundary (this is roughly what GC is in this context) causes it to be memory safe. This is not an interesting observation. It also causes it to be significantly slower, to the point of not being competitive anymore.
> It means it is no longer possible to draw a line between any two points (portals can shadow portions of the space such that some points are not connectible
This feels a bit like saying that putting a wall in a room makes it non-euclidean since there's now a barrier in the way.
I know where you're coming from, but this is confusing geometry and topology. (Curvature vs. how the space is connected.)
> This feels a bit like saying that putting a wall in a room makes it non-euclidean since there's now a barrier in the way.
Maybe that's what H. P. Lovecraft meant about non-Euclidean architecture in R'lyeh. ;D
(It probably isn't - the quote from The Call of Cthulhu says "the geometry of the dream-place he saw was abnormal, non-Euclidean, and loathsomely redolent of spheres [...]".)
If you define "a line" as "blocked by another line (standing in for a wall)", it would be non-Euclidean, by virtue of breaking the axiom that says a line can be infinite extended, so that's not a particularly compelling argument.
I don't need to "confuse" geometry and topology. Euclid's axioms require both flat geometry and no "connections" in the space. It's right there in the axioms, if you can read them properly. They have no accommodations for "topology", and it is certainly not just a handwave "oh, whatever, it's no big deal" to extend them to handle it.
Almost everything that people think is ugly about Rust's syntax exists for very specific reasons. Most of the time, imo Rust made a good decision, and is just making something explicit.
Some things take time to get used to (e.g. if let), but for most people that's less an issue of syntax, and more an issue of not understanding a powerful feature (e.g. pattern matching deconstructions).
The reasons do not matter here. It is still ugly / noisy / overly-complicated and probably could have been done better.
I understand pattern matching deconstructions, I have seen it in other languages. Funnily enough they were nowhere as ugly / noisy / complicated as Rust's is. Rust seems to have bolted on a lot of fancy shit that may be appealing to a lot of people and that is it.
In your link, the first one is fugly, the last one is fine. Maybe Rust just encourages ugly (i.e. complicated) code a bit too much.
As someone who mostly writes Clojure code professionally during the day, I agree, Rust's syntax is complicated for no good reason, ugly and overly-verbose. But then I think that about most Algol-like language too, not just Rust.
And despite that I do use Rust when I want something simple to deploy/deliver, as handing over a binary that just runs is such a nice experience, and it's real easy to make fast. As long as I don't have to maintain in long-term, Rust is fine for what it is.
> It is still ugly / noisy / overly-complicated and probably could have been done better.
I don't know, it feels like you're just saying that you don't like it, missed the point of the post, and are not giving us anything concrete. Can you list a very clear example of how you'd improve the syntax?
Again, see the post: You can remove things, but you're losing explicitness or other things. If you want a language that's more implicit, this is fine. I don't.
> Can you list a very clear example of how you'd improve the syntax?
The demand that I must design a better language to have valid criticism is absurd - I don't need to be a chef to know food tastes bad, do I? I'm a user of languages, not a language designer. My job is to evaluate whether Rust's syntax serves my needs, not to solve the PL design problems that led to it.
The syntax is noisy. That's not "missing the point" - that's the direct consequence of the design choices you're defending. If your argument is "the complexity is necessary for memory safety" fine, but don't pretend the cost doesn't exist or that pointing it out is invalid.
You're conflating "can identify a problem" with "must solve the problem". Those are different skills. I'm evaluating Rust as a user, not auditioning as a language designer.
No, I just don't think you have identified a problem in the first place. You've complained a lot, but you've not even been specific enough to point at a single concrete thing! You've been so lacking in specifics I don't even know if you'd prefer Ocaml, Go, or Python-style syntax over Rust! Like, I can't tell since all you've said is that you don't like it, without even telling me how you don't like it or what you prefer!
You say "over-complicated". I disagree, my impression is that is mostly about as complicated as it needs to be to solve the problems it is trying to solve.
I'm actually fine with almost all the decisions that Rust made in terms of logic and concepts, but specifically don't like the synthax itself: the symbols, keywords like the consonant-only "fn" instead of "func" for instance, the fact that || {} starts a lambda instead of || -> void {}, the fact that you can return things by simply having them in an if branch. It's the main reason I don't use the language.
Most of those are a matter of preference, implicit return is just plain better, and it would be absolutely insane if closures required the return type to be specified. I do agree that the toilet bowl `|_|()` syntax is ugly, though.
Again, I think JS/Typescript has a better syntax, since the implicit syntax is better when unbranched, like x => expression, but it's harder to read the more branches there are, since it's hard to visually scan where results can be located.
I really dislike them. Makes me wonder if you just got distracted and forgot to finish the function. Be explicit, don't make me have to spend time figuring it out.
Meh, if these are the main reasons you don't use the language, I don't know what to tell you. I get having preferences, but whether the keyword is `fn` or `func` is such a banal, trivial thing that doesn't matter at all.
They could have at least put the types on the left. Types on the right are a good fit for mathematics, where everything is single-letter symbols, so your eyes do not have to go across the line to see the entire definition, but in programming function definitions often span an entire line on screen, so the most important information should be the first thing shown! Also most programmers do not have formal education in mathematics, so the whole "function : domain -> image" syntax is foreign to them. We really should strive to democratise programming for everyone, rather than make it isolated to a small clique of "properly" educated white men who all went to the same university.
The type of a variable and the return type of a function are the most important pieces of information regarding those, so they ought to be on the left. It also fits the data flow going right to left (i.e. how the '=' operator works). C's type declarations can get pretty gnarly, so there is definitely room for improvement there. I would say Java (and C#) got it as close to perfect as possible.
If you want to replace C/C++ you should make your language look as inviting as possible to users of the old one. I truly think this strange fetish for putting types on the right is what gives C programmers the ick when they see Rust for the first time and is hampering its adoption.
After using C and Java for years and years I absolutely loved types on the right when I started using Scala. On the right just makes so much more sense to me, and I'm not a math guy.
"if let" just breaks my brain, it feels backwards to me and takes me a minute each time to work out what's going on. In 40 years of programming I've never seen a syntactic construct that I found less intuitive. And it would probably be easily fixable, if it was more along the lines of "if x matches Some(let z)".
> IMHO Rust has severe problems and what is considered "modern" is mostly taste.
Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool.
I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust is as a language.
Ada and SPARK fulfilled the promise of a safe systems language decades ago without making most of the mistakes Rust does. Rust has its strong sides, sure, but it's far from the only shop in town. The GCC happens to include an Ada compiler as well.
The problem is they forgot about making the language approachable so it lives in its bubble for safety criticial usage (which Rust kinda starting to eat its lunch from with the certified Rust fork)
If you’re referring to Ferrocene with the certified Rust fork, then I’d like to make the minor correction that we don’t consider Ferrocene a true fork, but rather a downstream distribution of the Rust projects compiler. There are very little changes to the compiler itself. Most relevant changes are documentation, build process and different test coverage - we do test architectures that upstream does not.
For starter it looks completely alien my real introduction to Ada was with this article comparing it to Rust on solving advent of code [1] but it gives me that feeling when I try to read Haskell code (not that extreme). I did not actually give it a real chance though but its user base even more niche than Rust so idk. It has really cool properties (being able to define n bit datatypes is nice) but it is also leans to more on the imperative side so that also does not interest me.
It seems like Ada more or less has to have memory safety bolted on -- that is what SPARK does -- and it's not clear that Ada's bias towards OO is better than Rust's bias towards functional programming.
Are you talking about features like type inference (so the Rust code could be less clear, since types are not always written out)?
That is a 'subtle whataboutism' reply, actually...
you see, GP did not speak in relative terms, but absolutely: They believe Rust has problems. They did not suggest that problems with programming languages are basically all fungible, that we should sum up all problems, compare different languages, and see which ones come out on top.
No need to sully CL with this kind of elitism. Any language you need to be a genius to use is a bad language. That's one of the fundamental issues with C. We're all imperfect idiots some of the time and one instance of undefined behavior breaks any guarantees the language gives you.
I find that languages with a high intellectual barrier to entry are much more pleasant places to be since people like the OP can't understand them and we never have people try to bully us into doing things _the right way_.
This is someone who says things like
>It's important for the project as whole to be able to
move forward and rely on modern tools and technologies
and not be held back by trying to shoehorn modern software
on retro computing devices.
Elitism is it's own form of bullying and needs to be treated as such.
I don't particularly like large swaths of humanity, but I also try hard not to be elitist towards them either. I'm not always successful, but I make a strong effort as my family raised me to be respectful to everyone, even if you don't personally like them.
If you actually want the compiler to check this on the level of the type system, it'd have to be `NonNaNFloat | NaN`. Then you can check which one you have and continue with a float that is guaranteed to not be NaN.
But (importantly) a NonNaNFloat is not the same as a float, and this distinction has to be encoded in the type system if you want to take this approach seriously. This distinction is NOT supported by most type systems (including Rust's std afaik, fwiw). It's similar to Rust's NonZero family of types.