Earlier quoted context omitted.
If you do not want to mess with Rust borrow checker, you do not really need a garbage collector: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang with Rust's expressivenes…
Can you help me understand when to use Rc instead of Arc (atomic reference counter)? Edit: Googled it. Found an answer: > The only distinction between Arc and Rc is that the former is very slightly more expensive, but the latter is not thread-safe.
Dada, an experimental new programming language
421–428 of 428 posts
Re: Dada, an experimental new programming language
#422Feel like there would be fewer posts and languages like this if people just took 10 seconds to read about modern C#.
If only it played well with Linux, but Mono is always playing catch-up
Re: Dada, an experimental new programming language
#423Re: Dada, an experimental new programming language
#424Earlier quoted context omitted.
I think there is value in elevating it from an ergonomic point of view, especially when walking that boundary between concurrency and parallelism. Pure concurrency has the advantage that you can do away with a lot of complex and nuanced synchronism mechanisms, by virtue of the fact you’re not actually sharing memory between parallel lines of computation. Something that makes writing correct concurrent code quite a bi…
> concurrency has the advantage that you can do away with a lot of complex and nuanced synchronism mechanisms, by virtue of the fact you’re not actually sharing memory between parallel lines of computation. That's the bit I reject. In practice you are saying that there are no reentrancy concerns between preemption points (async calls), and marking those points explicitly in code help avoid bugs. I claim that: a) ther…
You would hope if this was done properly you wouldn’t be using callbacks at all, because that’s kinda throwing away any benefits async/await provides, and reentrancy to the event loop should require explicit markings.
> if we value explicit markers for reentrancy, we should be instead explicitly marking reentrancy-unsafe regions with atomic blocks instead of relying on the implicit indirect protection of within-async regions.
In principle yeah kinda agree, but a lot of code isn’t reentrancy-safe, I would argue that most code isn’t reentrancy-safe, unless carefully designed to be reentrancy-safe. So a programming model that implicitly makes most code protected against reentrancy does provide value, and make it harder for difficult to debug concurrency bugs to slip in.
I don’t necessarily think it’s the “best” approach, I much prefer people actually think about their code carefully, and be explicit with their intentions. But that requires quite a lot a of experience, and understanding the detailed nuances that come with parallelism, something many engineers simply don’t have. So I think there’s a lot of value in programming paradigms that provide additional protection against those types of errors, but without forcing the type of rigour that Rust does, due to the learning barrier it creates.
I suspect that async/await is here to stay for now, but I very much see it as part of a continuum of concurrency paradigms that we’ll eventually move past, once we find better ways of writing safe concurrent code. But I suspect we’ll only really discover those better ways once we fully explored what async/await offers, and completely understand the tradeoffs it forces.
Re: Dada, an experimental new programming language
#425Earlier quoted context omitted.
I don't know why you think it implies reals. Most people would assume BigDecimal
Probably most people want accurate fractions (1/3), so they likely want Rationals. Of course machine-adjacent minds probably immediately want to optimize it to something faster.
I see no reason why I would need to represent it as an accurate fraction instead of two numbers, even if I divide it later I can always just do that inaccurately since the exact aspect ratio doesn't matter for resizing images (<1% error won't affect the final result)
Re: Dada, an experimental new programming language
#426Earlier quoted context omitted.
You can have target language to be as far fom host language as you like. For one example, again, borrowed fom Haskell universe, is Atom [1]. It is a embedded language to design control programs for hard real-time systems, something that is as far from Haskell area of application as... I don't know, Sun and Pluto? [1] https://hackage.haskell.org/package/atom-1.0.13
I'm sorry - of course you can. my problem is that switching back and forth I internally get them confused. and I start moving the target language to be closer to the host. while this might be my failing alone, I've seen this happen quite a bit in other language design projects.
Re: Dada, an experimental new programming language
#427Earlier quoted context omitted.
"Number" implies at least the reals, which aren't computable so that's right out. Hans Boehm's "Towards an API for the Real Numbers" is interesting and I've been gradually implementing it in Rust, obviously (as I said, they aren't computable) this can't actually address the reals, but it can make a bunch of numbers humans think about far beyond the machine integers, so that's sometimes useful. Python at least has the…
I would argue that what "number" implies depends on who you are. To a mathematician it might imply "real" (but then why not complex? etc), but to most of us a number is that thing that you write down with digits - and for the vast majority of practical use cases in modern programming that's a perfectly reasonable definition. So, basically, rational numbers. The bigger problem is precision. The right thing there, IMO,…
Note parent said "at least the reals"
Re: Dada, an experimental new programming language
#428Earlier quoted context omitted.
Yes, that's true - "number" is probably more broad than I'd really want. That said, python's "int", "float" and "decimal" options (although decimal isn't really first class in the same way the otherse are) feels like a nice balance. But again, its interesting the way even that is probably a bias towards the type of problems I work with vs other people who want more specification.
"Number" implies at least the reals, which aren't computable so that's right out. Hans Boehm's "Towards an API for the Real Numbers" is interesting and I've been gradually implementing it in Rust, obviously (as I said, they aren't computable) this can't actually address the reals, but it can make a bunch of numbers humans think about far beyond the machine integers, so that's sometimes useful. Python at least has the…
- Leopold Kronecker