As someone who has dived into Rust over the past few months, the two main reasons for employing it are:
A) Bleeding edge performance (Shares the same problem space as C/C++, zero cost abstractions etc.)
B) Memory safety (Giving it a rather unique flavour among systems languages - distinguishing it from the above two)
If you primarily work in C#, the latter won't be a problem you will be looking to solve anyway. I would say if the former intrigues you then Rust would be a great place to start.
Nah, my theory is you're seeing run-of-the-mill brash business dealings with the unusual characteristic of being broadcasted publicly.
You wouldn't accuse the same of CEOs from more 'boring' companies because we only get exposed to the results through sterile PR communication, despite the fact the same candid conversations still happen.
Liquid-fueled setup is largely unsuitable for ICBMs. Want something that can sit in the silo for years and then be immediately available - so solid rocket motors are the way to go, plenty of other defence companies that are specialists in this.
I'm yet to see a study that convinces me of the potential of this concept. All of them when you get down to the details have at least one of:
- An unrepresentative test set , i.e. a population with similar blood pressure at recording in which merely predicting a constant 'typical' reading would perform well in terms of accuracy.
- A major methodology flaw, such as 'demonstrating' an ability to detect fluctuations from a baseline calibration cuff reading in situations where you would expect no significant fluctuations to occur.
I don't have access to this particular paper, but suspect it has the same issue owing to the relatively small sample size.
I find the topic interesting because it also seems to be one of these areas where a metric is being invented with no existing "gold standard", which is a different problem than just validating a new sensor to replace an existing one in the same methodology.
What does it mean to do continuous blood pressure monitoring? Do we have any idea how BP is supposed to behave continuously, when clinical standards are around a random sampling in particular resting postures? And do you have to account for all the fluid movements and pressure changes that happen during activity, with muscles contracting and body parts accelerating?
This is my gut feeling about a lot of activity going on in modern corporations. Private equity firms, for example, have been historically blamed for a lot of once great engineering companies in the UK being combined into a bloated mess of activities - which ends up ultimately sacrificing competitiveness.
However I feel like your average voter shaking my fist angrily a bankers sometimes when trying to put it into words (I don't honestly have a lot of insight on how it all works).
Have you got any good book/essay recommendations on over-financialisation?
I recently needed to render markdown to view some notes. Thought opening chrome w/ a plugin or VSCode felt similarly sluggish options to do such a simple task. Now a few weeks after playing with textualize this pops up! Neat tool.
> In Go, I found that using an interface was not free: it can make the code slower. In C++, if you implement the following type and call count on it, you find that optimizing compilers are able to just figure out that they need to return the size of the inner vector.
I'm surprised at this, do Go interfaces really introduce much overhead? Of course this depends on the level of performance you care about but surely, being a statically typed language, lots of the same optimisations are available.
Interface methods in Go are like virtual methods in C++. In principle C++ compilers when statically compiling everything can often remove virtual method indirection for some objects, but I think in general this optimization is still uncommon and difficult to coax out a compiler. Go definitely does not do this, even though in principle it should be easier.
Basically, "interfaces" in Go and C++ actually refer to quite different language features. (Or at least, the author is using the term to describe quite different language features.)
This is common when doing LTO, without it there is no guarantee that there isn't some dynamically loaded code that would be broken, this is one area where JIT focused languages have an advantage.
There is overhead in interface indirection because the Go runtime needs to perform dynamic dispatch to determine which method to call at runtime.
C++ can optimize interface indirection away because it supports static polymorphism, which allows the compiler to generate specialized code for each concrete type used with a generic interface, eliminating the need for dynamic dispatch.
Go generally is pretty conservative about that kind of thing (namely, compiler optimizations). Go generally abides by a “what you write is what you get” kind of thing, especially when it comes to “non-local” optimizations. It’s generally opposed to anything that’s “clever.” (Just my feeling as someone who uses Go pretty often and who respects the choice they’ve made on that spectrum).
Interfaces always go to the heap in go, so yes, you can take some simple code that could easily live on the stack and make it slower by wrapping it in interfaces with go.
Exactly, it's just the wrong people at the top and the wrong incentives. Is Arianespace structurally capable of producing economical access to space? Probably not.
If you primarily work in C#, the latter won't be a problem you will be looking to solve anyway. I would say if the former intrigues you then Rust would be a great place to start.