You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
I feel like we don't talk enough about about the knock-on costs of manual memory management. Garbage collection may not be a perfect way of managing memory, but it at least is *a* standardized way of managing memory which is consistent all the way through the language stack.
In the absence of such structures, individual libraries have to invent their entire own memory management idioms in order to talk to the outside world. One of the most pure, horrifying examples I've seen: This eleven-line boilerplate is how you allocate *any* object in Vulkan.pic.twitter.com/V6SkQeyKoI
Notice the "XXX" there; the idea is that you have to manually replace XXX with "Queue", or whatever Vk type it is you're trying to allocate. In other words, you cannot script or abstract this in any way, except by using C macros that string-paste to construct type names.
This is not Vulkan being silly, but rather is necessary because when you pass around a structure you need some way of communicating inside and outside the library who is responsible for managing that bit of memory and releasing it when it's done.
Now imagine what happens if, for example, you have to work with both Qt and Vulkan in a single application, and each of these libraries has their own bespoke memory management idioms, and you are going to have to be the one writing glue code to make them communicate.
The true horror of the Vulkan APIs is that the more you think about it the more you realize the Vulkan API is more or less precisely determined by the shape of the problem it is trying to solve. https://twitter.com/0x21376B00/status/968526775423614977 …
The Vulkan API should shame us as a species. We created this, all of us, by creating the need for it.
a friend (@silentbicycle, i think?) once told me that the absence of manual memory management is basically a prerequisite for composeable code precisely because it requires everyone to agree on memory. this is why package management in C/C++ will always be a nightmare.
Yeah. It's valuable not just for memory management, but because it's a mechanism that everybody agrees is allowed to have visibility across abstraction boundaries. Otherwise, every module needs to coordinate resource hand-off, complicating interfaces.
What benefits could come from agreeing on other cross-cutting mechanisms (that aren't necessarily about memory)? Erlang gets tremendous value out of agreeing on a concurrency & error-handling approach, for example.
thats the conceit of a VM like the CLR. you have an agreed upon GC, type system, error handling, (large) standard library, C-interop, etc. it's great! but its a VM. Rust is the only VM-less platform of standardized cross-cutting mechanisms i can think of.
Yeah, this is what's finally bringing me over to Rust. I don't want to write code by Rust's constraints, but maybe I can think of it like Rust's memory constraints being "these are the module boundary constraints" and use cheatz to violate the constraints in-module.
Incidentally, I am still waiting for a language that has a way of agreeing how exceptional conditions are handled across module boundaries. I don't believe exception handling is good enough
What I want is a standard idiom where actual errors like "invalid parameters" and exceptional-but-expected conditions like "file not found" are handled within the same mechanism, yet the mechanism understands one is lighter-weight and must be easier to do casually than the other.
Sometimes @BrianTRice tries to convince me this is what common lisp "conditions" are but i still haven't gotten around to learning how this works.
100% this! One of the big wins in objc imo; a consistent refcounted memory model enforced by language and used by all libs (with escape hatches). Also warming up to Rust for the same reasons...
Yes. And available in C world via CF...
Yeah! and CF-style APIs may be pretty ugly at times, but they’re mostly consistent and interoperable. knowing the shape of one Apple C API means you know most of them. ownership rules, calling conventions, lifetimes, threading...
And Apple keeps doing things like backporting GCD blocks into C... it's a very nice ecosystem.
Rust feels annoying at first, but I can tell you that having memory management built-in to the language, and usable primitives like strings and vectors makes things *so much better* compared to C/C++.
You do know C++ has standardized vocabulary types like string and vector... and that Rust's Vec is so called because of C++?
Are you referring to the STL? Because I would disagree that the STL can be described as "standardized"
Things have gotten better on this front but I would still describe the STL as a slightly unpopular third-party library which coincidentally happens to be designed by the standards committee and distributed with some compilers
This is entirely unrelated to the reality of writing C++ code today.
Every single large C++ codebase I've worked on replaces STL with their own thing, not preserving any names.
I'd argue that's due more to poor/slow implementation in MSVC's STL, plus no move semantics, not it not being standardized. And it's gotten a lot better in the modern C++ era.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
