221–230 of 279 posts
Earlier quoted context omitted.
If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).
If Java cared about being fast it'd have value types.
Earlier quoted context omitted.
The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?
Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT. Do you have evidence to the contrary?
https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
Earlier quoted context omitted.
The distro maintainers take your source code and package it. If they need to update the program due to an outdated dependency they don't need to recompile the whole program but rather just relink their cached object files with the newer version of the static library (if applicable).
Object files are compiled code with the API and ABI already baked in. This approach effectively combines the downsides of static and dynamic linking.
Obviously it is not the same at all (LTO, inlining etc.
Indeed in some cases API and ABI breakage requires you to recompile your program from scratch. This is not differnt from dynamic libraries where ABI breakage is only discovered during runtime.
The use case Im talking about tough is your classical 3 bugfix in a library.
A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either. As far as I can tell, there's really nothing wrong with Swift, and it probably ha…
I would say it is the reverse on what concerns Apple platforms, Rust isn't a competitor to Swift. It will never have tooling parity with Swift. Trying to use Rust instead of Swift on Apple platforms is only for those that enjoy the pain of creating ecosystems from scratch.
https://gs.statcounter.com/os-market-share
Maybe it doesn't matter because developers prefer macOS, so the rest can be treated as a secondary case? Not even close.
https://survey.stackoverflow.co/2022/#section-most-popular-t...
What about servers? Network services and SaaS are a huge industry, of course. Admittedly, I can't even find a good source for what marketshare macOS has: most "server marketshare" counts seem to exclude it or just merge it in with "UNIX-likes". The number appears to be extremely small. There's definitely some exceptions; I think Imgix has been deploying Macs to the datacenter. However, in order to do so, they essentially had to build custom rack mount equipment for desktop machines... I think it's very safe to say that macOS deployments for services are extremely in the minority, and the majority of macOS data center deployments aren't even for general network services specifically but mainly just for CI.
OTOH, macOS Server and any "server" SKUs of Macs have been discontinued as far as I know.
"Rust isn't a competitor to Swift" is not the zinger in Apple's favor that you think it to be. In fact, Apple would be best to support making Rust work better on Apple platforms if it can't support making Swift work better on other platforms in a much more significant way than it has in the past few years.
And this all makes sense. Apple developers had been extolling the virtues of Objective C for a long time, including how it is superior to C++. I'm not even arguing for or against that PoV, but Objective C had at least pretty good compiler support on platforms outside of macOS and it did nothing for its adoption. The main place you'd see Objective C on other platforms were in software originally written for macOS, like `unar` on Linux. That's mainly it...
Unless you want Swift to fail in the long term, I think this PoV is a very badly losing position.
Earlier quoted context omitted.
Microsoft has plenty of conflicts of interest to contend with, but that hasn't stopped them from being able to make some inroads towards appealing to other platforms. Perhaps it would be unwise to trust that they've "changed" and invest in Microsoft tools or ecosystems, but it's beside the point: I think it's fair to say that Visual Studio Code and TypeScript have achieved widespread success across the board. I think…
Yeah, but if you want top tooling for .NET, the answer is still pretty much Visual Studio on Windows. The cross platform version of .NET and VS4Mac/VSCode only support a subset of the whole development experience. Many libraries on the ecosystem are still stuck in .NET Framework, wrappers for COM libraries, or plain Windows APIs, given its Windows focus between 2001 - 2016. If you want a Visual Studio like experience…
What's crazy is that in .NET's case, Microsoft has it a lot more "free" because the community is willing to go great lengths to just do it themselves. Like for example, the entire Mono ecosystem: MonoDevelop, Xamarin, Unity, etc. has proven quite successful. Now that Roslyn is open source, it should easily overtake Mono... but it hasn't really.
.NET is basically a cautionary tale. It's pretty amusing that the same company that made TypeScript and VSCode popular across platforms is having strategic trouble doing the same for their wildly sought after CLR/.NET ecosystem.
Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle. The amount of dynamic linking issues I encountered on GNU/Linux was insane (fuck libstdc++). Not even glibc manages to keep forward compatibility working (breaking memcpy, breaking DT_HASH, ...)! It's much better to just statically link your binaries (unfortunately many…
You can't ship reasonable plugin for most of the popular content creation tools - be it audio, video effects, 3d modelling, etc. without support for dynamic/shared libs. Okay, maybe you can - at the risk of performance cost - e.g. your out-of process plugin that need to move data in/out with a cost, and then it over complicates - because the plugin process might've died - how do you restart it, how do you get it back…
Earlier quoted context omitted.
I did it for 10+ years at my last job, you need a build system that hammers on everything really hard to set the rpath on everything, you shouldn't need wrappers. It definitely isn't idiomatic though.
What is the philosophy behind why it's not done like this Linux? Also, what about Nix?
Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle. The amount of dynamic linking issues I encountered on GNU/Linux was insane (fuck libstdc++). Not even glibc manages to keep forward compatibility working (breaking memcpy, breaking DT_HASH, ...)! It's much better to just statically link your binaries (unfortunately many…
IMO dynamic linking is rad if you have a known system compatibility table and known vendor (distro) selection for the OS components/key deps. The issue rather is that it is a pain in the butt to configure and understand.
A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either. As far as I can tell, there's really nothing wrong with Swift, and it probably ha…
This is all very hand-wavey. Are you just describing a chicken-and-egg scenario? Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory…
I can make some concrete examples: If Apple wants Swift to be successful in the open source world, it needs to at least get basic "passes test" level of support for the BSDs, and some other less common architectures. Look at the architectures supported by the "golang" package in Debian:
> amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x
Now compare to the list of architectures supported by the Swift package in Debian: ... Oh. There's not one!
If this isn't getting the point across, I don't know what will.
(Side note: There are "official" Swift packages for Ubuntu, even if they're not upstreamed, but they only exist for amd64 and arm64. I know there is "community" support for riscv, which is pretty cool. Still... This is definitely a problem for Swift use in the open source community. Without Swift packages in Debian upstream, for example, I don't even think software based on Swift can be packaged for upstream inclusion.)
Earlier quoted context omitted.
> When you dynamically link a library, the entire library is loaded into RAM. It doesn't. When you dynamic link a library, no part of it is loaded into RAM. It is page-faulted in, as it is used. In the end, only parts that were really used were loaded into RAM.
A page will be loaded in if any part of it is useful. Given that functions will be laid out more or less randomly throughout a shared library, and programs use a randomly scattered subset of the functions, I think its safe to say that you'll get a lot of bytes read in to ram that are never used. Especially when we take the filesystem's read-ahead cache into account - which will optimistically load a lot of bytes near…
We have order files for this purpose so that functions are not randomly scattered: https://www.emergetools.com/blog/posts/FasterAppStartupOrder... . This technique is widely used by well known apps.