2,917 karma · joined April 21, 2019
It is possible to write a blazing fast JSON serializer/deserializer on pretty much every programming language, and most languages have many of them.
Swift does not, and it does not seem that it will have one in the near future. This is quite disappointing, taking into account that Swift is one of the 3 major-platform native languages (C# windows, swift macos, C on Linux).
So yeah, it is quite surprising that the major platform language in one of the main platforms in use has extremely poor JSON support. Even more surprising is that there is no path forward to fix that.
There are many pros/cons of using json, but this was a "non issue" (if it isn't fast enough, we can make it fast - turns out we cannot because the platform is controlled by Apple and they don't want to).
Sure. And if you are writing a concurrent application with 500k LOC , 99.99999999% of your code will be safe Rust.
Safe Rust that you can refactor at will - at least, in my anecdotal experience of working 3 years full-time on a concurrent >100kLOC Rust application, I have yet to see a big refactor that introduces a concurrency or memory safety bug. In my previous 15 years of doing the same in C++, I actually have to see a refactor by myself or others that did not introduce multiple bugs.
> Then if I'm writing a concurrent queue or concurrent hash-table I'm on my own since 100% of my codebase is unsafe Rust.
You can write a concurrent queue using safe Rust (e.g. it is trivial to write a spinlock using safe Rust that you can use for that). You are choosing not to do that, and provide your own instead.
Your job is not to write the unsafe code, but to _prove_ that it is safe to use from safe Rust.
Once you do that, the other 99.999999999% of your application can just use it without issues.
If you don't want to do that, Rust belt has soundness proofs for most concurrency primitives in the standard library. Aaron Turon's thesis has similar proofs for the ones in crossbeam. Etc.
> I suppose you didn't try to write any concurrent data structure.
You suppose wrong.
> Even a hundred of lines of concurrent code is incredibly hard to debug without tools when it involves multiple threads synchronizing with each other.
So don't do it? I've done it a couple of times, and the first thing I do is set up the fuzzer and thread-sanitizer for the build. That catches most bugs early.
I've never proven my implementations to be sound, but they were always good enough for my use cases. I've hitted bugs in my application when using them, but finding those bugs was always trivial, since they are only located in the 100 LOC of unsafe code.
---
I think you are fully misunderstanding the claim fearless concurrency. It is a claim about safe Rust, and you can write huge, complex, and extremely efficient concurrent applications using safe Rust without having to write one line of unsafe Rust yourself, and using only unsafe Rust code that has been proved correct.
If the only thing you use Rust for is writing concurrent data-structures, Rust is very specific that these claims do not apply there. You seem to not have understood this yet, and without having understood that, the chances that your implementations are correct are very thin. I hope you are not using them for anything important.
> You mean you you've never used any wireless connections to your machine?
Yes: I clicked on the network, typed the password, and it worked, always. If the machine already has seen the network, i don't even have to click, it just connects. If one of my machines (e.g. my iphone) has seen the network, the network and its credentials are stored on iCloud, so my laptop and my tablet can just connect to it. I never had to google how this works, never had to install anything to make this work, never had to change any configuration file to make this work, etc.. Same for VPNs, VNCs, corporate networks, network drives, etc.
> You've never had to set up backups or change audio settings?
Yes, I clicked on enable backups, clicked on the box that enables daily back ups, clicked on the drive where I wanted to store them, and it worked, always.
I can restore, browse, partially restore, backups with one click using time machine. I never had to google how this works. It always worked.
> change audio settings?
Yes, I clicked on the audio button, and volume worked, muting worked, all 4 sound outputs worked, always worked, etc.
---
On linux, over the last 15 years, i have googled at least for days to do _each_ of these things for customers:
- can't connect to a particular wlan, corporate wlan, etc. needed new drivers, upgrade kernel, change some etc config to enable something, etc. Same for network drives, cloud drives, SMB, ...
- sound, damn sound: sound cards not being detected (hell on my lenovo yoga an update to 19.04 Ubuntu pushed a kernel patch that broke my sound cards driver: no sound card detected, still not fixed on Ubuntu 20.04 5 months later - no sound in the times of corona and web meetings - great!), alsamixer, etc files, pulse audio, .... I have had to google a lot about each of these things, and fiddle a lot over the last 15 years, on dozens of machines, for dozens of users, for hours.
- backups, on Linux, have fun. I've set backups for ext4, zfs, and btrfs. ALWAYS had to google for hours. Every time I had to restore a backup, had to google for hours. Some times restoring did not work. Some times backups did not work. Encrypted backups do not work out of the box (Apple's full-disk encryption is enabled by default - but enabling it and having work with everything is just 1 click - on Linux full-disk encryption is a mess).
---
So no, I never had to set up anything on MacOS X in the last 15 years. The things were in the obvious place, and I just used them, and they just worked. No need to even google how to do the thing, or what to install to get it done, or configure the install, or read bug reports to work around issues, nothing. They just damn worked, as they should.
Its 2020, and setting things for companies using Linux is my day job. These people would all save a ton of money by just using macs or windows machines. The amount of time their employees waste on setting up and maintaining their machines instead of doing their actual work is astonishing.
Changing the screen takes ~20 minutes, and a new screen costs ~16$.
I will probably upgrade to the iPhone SE2 at some point, but given that my phone works perfectly for what I use it for, paying 550$ for an upgrade just does not make sense.
So no, you don't have data races or undefined behaviors.
If you mix safe Rust with unsafe Rust, and your unsafe Rust has a bug that causes a data-race, then you only have to search for the bug in the 0.00001% of your code base that uses unsafe Rust. Which is many orders of magnitude better than even "safe" languages like Java.
I've spent zero days, zero hours, zero minutes, and zero seconds fiddling with setting anything up in macOSX over the last 15 years.
I manage a bunch of Linux systems, from laptops to desktop to servers, and over the last 15 years I've probably spent months of my life setting up stuff that should have just worked.
I use a mac at home and as my dev machine, because I charge quite a bit of money for doing that for Linux, and I don't want to throw my own money like that during my free time.
> Itunes, Mail, etc, none of the software shipping with MacOS is actually any good.
I use many Microsoft Office Apps, Adobe suite apps (mainly photoshop, lightroom and illustrator), and all of them just work.
VNC clients, VPN clients, Samba, they all just work. External devices, no issues. Do I want to stream my display over wifi to my television, or my audio to the stereo? Just one click away. Do I want to restore the back up of one directory from 2 years ago ? Its three clicks away.
On Linux, half the steps to each of these things are filled with hours and hours of research in the Arch wiki. Do you want to stream your monitor to your TV? Start by setting up a media server, and then 200 steps. Do you want to restore a partial backup of some folder in a BTRFs drive, a dozen steps that I cannot remember. Like no way. I don't want to remember how to do these things, and I don't want to have to look it up. If nobody is paying me to do these things it should be completely obvious how to do them and it should just work.
But hey, do convince your employers to use Linux everywhere, its great for the business.
* MacOS X was a very good OS for developers,
* MacOS X 11 is not.
The first claim is discussed in the prelude, but irrelevant for the conclusion. Three arguments are given for the second claim:
* macOS11 runs on ARM
* macOS11 UI supports touch
* macOS11 is not open and good [like macOSX] but easy and good enough
That's it. This leaves me quite disappointed.
macOS 11 running on ARM, RISCV, x86 or powerpc has little to do whether it is good for developers. I have an intel mac and do a substantial amount of ARM development on it: qemu works just fine. I expect qemu to work as good on arm for developing for x86.
macOS11 supporting touch does not say anything either about whether it is good for developers. Windows UI supports touch, and that's quite good, even for developers. I also have a Lenovo Yoga, and I can fold it, and sketch on it, which is great for web meetings. All thanks to having a good touch screen and good OS touch support. So IMO this change could make macOS11 better for devs than macOS10.
I haven't heard any information suggesting that macOS11 is less open and less good than macOS10. macOS10 was never great. It has quite old BSD utilities that are often subtly incompatible with their Linux or modern BSD variants for apparently no reason. macOS11 does not make this better or worse. macOS10 requires pretty much every process to grant permissions for everything nowadays, which makes it a bit of a pain to do something in the terminal without granting all permissions to the terminal, but that's only one click away, already "prepared" by apple, and you only have to do this once, etc. Each release of macOS 10 has made it more painful to use for development in some ways, and also better in other ways (zsh as default shell, C++17, C++ modules, dropping CUDA support, no native Vulkan support...). It was never great, it was always kind of a mixed bag.
What Rust proves for safe Rust is that even if you were to use these incorrectly, your program is still data-race free and memory safe.
That is, if you use relaxed where you actually wanted to use sequential consistency, your program might do many sorts of incorrect things (e.g. a counter is incremented in the wrong order), but it will not have undefined behavior (it won't dereference a null pointer, doing an access out of bound, double free, or having a data-race).
To write atomic code that creates a data-race, you'd need to use unsafe Rust, and then your program would have UB.
Rust proves this for safe Rust using ownership + borrowing, and `Sync`+`Send`. Ownership and borrowing deal with "aliasing xor mutability" which essentially eliminates all data-races, because a data-race requires a conflicting access involving two aliases where one is a write, and these two features prevent that from happening. `Sync` and `Send` provide proofs that some concurrent accesses are ok, e.g., an atomic relaxed write that conflicts with an atomic relaxed read is ok (what's not ok is unsynchronized conflicting accesses).
As mentioned this does not proves that your program has no logic bugs, only that it has no data-races and UB. It is possible to write programs in safe Rust that do not do what you intend.
In fact, the fastest (#1 Top500 as of June 2020 https://www.top500.org/lists/top500/2020/06/) super computer in the world, and one of the most efficient (#9 Green500 as of June 2020 https://www.top500.org/lists/green500/2020/06/), uses ARM CPUs and has an implementation of these for them.
Woah woah, hold your horses.
Thread-safety is a definition in the specification of the operational semantics of programming languages. It is a precise mathematical term used in proofs.
The C, C++, and Rust memory models precisely define thread-safety as "the absence of data-races".
Whatever the wikipedia says just does not apply (and if the wikipedia does not mention this, it is just incomplete in its treatment of thread safety).
The problem is that some people don't know what these mean. I'm not sure why though. Like, I could understand that somebody coming to Rust from Java wouldn't know what "memory safety" means since it is essentially a solution to a problem that Java does not have. But most high-level languages do not protect you from data-races, so this is a problem that Rust does solve and one can run into in most widely-used programming languages (e.g. in Java they are also called data-races).
The large majority of comments I read about Rust safety claims are very explicit that Rust provides memory safety and data-race freedom.
You seem to be arguing that these comments are leaving out important information by not clarifying that "This does not mean that Rust prevents all bugs, e.g., you can still write programs with logic bugs, race conditions, dead locks, DDoS, ... and the list goes on and on... in Rust".
If somebody does not know what that "memory safety" and "data-race freedom" is, they should just ask, but if they don't, and they make an incorrect assumption, then its kind of their fault, not the fault of whoever wrote such a comment for not mentioning all the things that these two properties do not guarantee.
Also, it is actually trivial to build Rust programs that prevent some race-conditions, like deadlocks (just a cargo flag away), so if anything, I'd complain that people being "too correct" by restricting themselves to "data-race freedom" are leaving out some important advantages of Rust.
If you develop for Mac, chances are you want your CI to use the same target hardware, which means cloud ARM hardware to run Mac VMs.
They are not talking about "unpacking on the fly for processing", but rather about "unpacking on memory to be able to call an opaque API outside your control that expects the unpacked representation". That requires copying in-memory to interface with that API.
Your approach only works if you are willing to "re-implement the world" to interface with whatever packed format suits your application.
With zero-copy serialization you don't have to do that.
The first i7 from apple starts at ~1.6x the price of the ipad pro in the macbook air 2020, yet the results of comparing the a12z with that show that, performance wise, nothing really changes: https://browser.geekbench.com/v5/cpu/compare/2626721?baselin...
I'd suspect the reason is that these benchmarks are long enough, that the Intel CPUs just end up completely throttled down after the first ~30-60s, while the A12Z does not.
Either way, the trade-offs here have multiple axes, and honestly die-size is not something I as a user care about. I care about performance / $ and battery life / $. The A12z seems much better along these two axes than either of the Intel CPUs in the Air 2020.
To find something competitive in terms of performance (but worse battery life) from Intel, one does need to go to the Core i7 1065G7 that you mention, which delivers approximately the same performance as the A12Z: https://browser.geekbench.com/v5/cpu/compare/2627162?baselin...
However, the first machine with that CPU is the Macbook Pro 13' 2020, and that starts at ~2x the price of the ipad pro. From looking at the upgrade prices, the cost of that i7 alone might be by itself ~50% of the whole ipad pro cost, or larger.
So while you are right that these two are comparable in terms of raw power, I doubt they are comparable in terms of performance/$ and battery life/$. Without knowing the exact costs of each we can only speculate. If that intel i7 is 2x more expensive than the A12Z, then perf/$ would be half as good, and since raw battery life is worse, the battery life/$ axes would be twice as bad.
I don't think this is the criticism being raised.
The main criticism being raised against non-zero-copy serialization is that this often requires maintaining different memory representations for the same value - the copies are the consequence of transforming from one representation to another one.
So this is Geekbench 5 showing the difference between a 2012 macbook air i5 and a 2020 macbook air i5 - both base models and similar price: https://browser.geekbench.com/v5/cpu/compare/2613713?baselin...
And this is a thread in the rust subreddit about compilation speed on macbooks where some users report the performance increase for different generations of macbook pros and macbook airs, if you want a more "realistic benchmark" to calibrate geekbench results: https://www.reddit.com/r/rust/comments/gypajc/macbook_pro_20...
This is the ipad pro 2020 crushing the macbook air 2020: https://browser.geekbench.com/v5/cpu/compare/2612714?baselin...
And this is the improvement from the previous generation ipad A10 to the ipad pro's A12Z - 2x speed up in single a generation: https://browser.geekbench.com/v5/cpu/compare/2613991?baselin...
You are definetely right that Moore's law is hitting Intel hard. But AMD is still doing quite well, nvidia and "ati" are doing incredibly well, and Apple chips have been doing extremely well over the last couple generations.
Maybe you are right, and Apple won't be able to deliver 2x speed ups in the next 2 generations. I'd expect that, just like for Intel, things won't abruptly change from one gen to another, but for this to happen over a longer period of time. Right now, only apple knows what perf their next 2 gens of chips are expected to deliver.
The only thing we know is that Apple ARM chips are crushing their previous generation both for ipads and iphones year after year, and now they are betting on them for macbooks, and potentially mac pros, probably for at least the next 10-15 years.
Apple has an ARM-based product on sale today that has a better screen, better battery life, and better performance, than the 2020 Macbook air for many workloads, including compiling and doing development work (it crushed the air in the benchmark sets that can be run there).
That product is the 2020 ipad pro, and that is why there are so many posts about people actually trying to turn them into development machines.
This product is one step away from being a real laptop: it is missing real MacOSX.
The performance of the Intel-based Macbook Air has increased by 1.8-1.9x from 2012 to 2020 (that's 8 years). Apple already has internal A13 prototypes, and A14 is probably going to the prototype phase right now.
I can't imagine the numbers working in favor of Intel. By 2021 Intel can probably deliver a 1.1-1.2x speed up tops for Macbook airs, while Apple can probably deliver a 2x speed up for 2021 with the A13 and another 2x one for 2023 with the A14. Being able to scale the same chip for iphones, ipads, and macbooks, reusing internal resources, and avoiding the "hassle" of having to deal with Intel.
The only thing that's IMO in the air is what is going to be the discrete graphics story for macbook pro's and Mac pros.
Its unclear whether it would make sense for AMD to deliver discrete gfx products that interface well with ARM, and the Apple-nvidia bridge burned long time ago. So I wonder whether Apple has openings for electrical engineers to work on discrete graphics verification & design, and driver developers. It would strongly hint that apple would design their own discrete gfx in house.
Yes, public servants should be interested in doing their job properly.
In Germany at least, they are un-fireable, so it isn't unusual for many of them to just being counting the days until retirement. Some "harder" task arrives? Sorry can't do that - what are you going to do about it? I can't be fired.
On the international whistleblower hotline of the financial regulatory agency? At least they could have connected them with somebody, or tell them to send an email somewhere, but hanging up doesn't sound shady to me, it just sounds lazy :P
The tests of my Rust range-v3 like library compile in ~12 seconds. The tests of C++'s range-v3 take ~320 seconds to compile.
> Please avoid obvious exaggerations...
The incremental compile of the same library takes in Rust ~1 second. In C++, it still takes ~320 seconds, zero improvement because C++ header-only generic libraries do not benefit from incremental compilation.
> Modules are not even used yet by any big project nor properly supported yet, and they are not expected to speed up compilation much anyway.
I maintain a ~500kLOC C++ project that uses modules. C++ Modules did not speed up compilation at all over simple PCHs.
> It does have a cache per user/project/etc., which is basically the same and without it the speed would be atrocious.
No it does not. Check out any project from crates.io into a subdirectory, do a cargo build. Check it out into another sub-director, do a cargo build. All dependencies are re-built.
You'd need to go way out of your way and set up like sscache to get something similar, but Rust and cargo do not do this.
> It isn't hard: C can be compiled way faster than either C++ or Rust because the code and type system is much simpler.
Citation needed. On my machine, rustc spends ~80% of its time in LLVM, which is slow, because the translation units are huge. The other 20% is split into ~5% parsin, ~5% type checking, and ~10% LLVM-IR generation.
Even rustc's synthetic trait metaprogramming benchmarks do not spend even 10% of the compile-time in type checking.
So if you have a test for which rustc spends most of its compile-time in type checking, go ahead, and post a link. We'd love to add it to rustc's benchmark suite.
Also, on my machine, while clang spends less time in code generation, it is still over ~60%.
Clang spends more time in parsing and type checking, and that's because C++ overload resolution scales with the number of visible overloads, and the more header files you have, the more overloads there are (e.g. an error with operator<< on a ~500kLOC project produces ~2000 "potential candidates"). While that's part of the slowdown, still 60% of the time is spent in LLVM. The reason is that idiomatic C++ just produces more code than C due to templates, inlining, etc. for similarly-sized TUs.
Parallelizing compilation within a TU is hard to do well. Rustc tries without much success and clang does not. In C, you can simply parallelize by using more compiler processes to compile fully independent TUs in parallel. These TUs are also smaller because idiomatic C code doesn't use many macros to generate code, most functions are linked opaquely, generics also generate few code via void*, and the worst culprit of long compilation times in C, which is including too many header files, can properly be cached using PCHs.
Nobody is claiming that? At least not in this thread.
I think your confusion stems for thinking that "Rust == borrow checker". The borrow checker is a tiny part of Rust.
> The mental overhead of rust
I find the mental overhead of Rust to be smaller than that of Python, Go, Java, Haskell, C, C++, Lisp, and pretty much any other language that I've ever used.
In Rust I don't have to think about multi-threading, data-races, memory management, resource acquisition and release... the compiler does the thinking for me. I also can refactor and reshuffle code at will, and trust the compiler to catch all errors.
Changing a type that pretty much every translation uses in a 500k LOC code base and add multi-threading to it? No problem, just try it out, and if it compiles, it is correct.
I can't say the same of Go, Python, Java, etc. where threading errors are impossible to debug. And well, it wouldn't even be worth trying. It would be impossible to make sure that the code is correct, even after fuzzing for weeks.
- "[short seller] Do you speak english?"
* "[BaFin] Sure of course.
- "[short seller] I have proof of Wirecard's fraud..."
* "[BaFin - interrupting] Wirecard? Oh sorry no we don't speak english. [hang up]"
And that right there is indeed BaFin's fault. They are at best negligent and at worst a malicious entity, that has scammed many investors out of a lot of money.
That's not being short handed, that's being negligent. They knew something was up with Wirecard, and they actively tried to ignore all the warnings, and now all stakeholders have lost ~80% of the share value.
So yeah, the DAX is a joke and Germany is a banana republic.
That's because things don't work.
I moved from i3 to Sway and back to i3 because Sway didn't deliver of being compatible with i3.
Then there is the xdg portal mess which makes screen sharing through a web browser weird.
And also the whole XForawarding mess, which makes all Apps using it blurry in HiDPI. I use my computer for work, and 99% of it happens in emacs. The remaining 1% is using Chromium, which also does not support Wayland yet, so for me 100% of my wayland experience on HiDPI amounts to "all text on Wayland is blurry". There is no "HiDPI per-App" setting to fix this, scaling to 1.5x is also bad, etc. And that's without entering on the "wl-roots will never support nvidia thing". I need to use both AMD and nvidia hardware for work. I don't care about whether Wayland's desktop war (e.g. Sway) against nvidia, who has 50% of the GFX market, and 99% of the compute market, is honorable or not. But I do care about not being able to work on Wayland while X works just fine.
Sway devs say that this is 100% nvidias fault. From my POV, all other desktops manage to work with nvidia's hardware just fine, Sway does not, so I see this as being 100% Sway's fault. Without an i3 replacement I can't use Wayland, so until this fanaticism finished, I'll probably won't be able to use it.