It’s a simple architecture that works directly with the hardware, without an operating system. That’s a good gateway to embedded programming, and it’s fun.
I'd like a thin compile-to-JS language with a Rust-like syntax, only because after writing Rust/Golang/Swift for a while, I keep forgetting to write parens in `if cond` and `for … in`. Suffix .await is a nice to have too.
I'm not so sure about implementation of Rust's semantics in JS. If I want exact Rust semantics, I can use WASM.
That's the plan for the initial prototype. My goal is to advance beyond this stage to generate optimized JS. While it's going to be less readable than handwritten js/ts, the trade-off would be performance boost.
From recent experiences in profiling and optimizing different backend apps, I'm confident that imposing some constraints on JS we can get noteworthy improvements on the performance front better or equal to golang. Here's a subset of the constraints I'm looking at:
- Avoid out-of-bound reads in arrays and monomorphization.
- Manage memory allocations. (pools)
- Implementing inlining, also done by V8 and JSCore.
- Keep variables close to usage context.
- Being picky about standard js operations.
- Using 'new Array(n)' for creating longer arrays, and '.push()' for smaller ones but if frequently calling methods on an array, avoid preallocating.
- Avoid arrays with holes, prefer using arrays with numbers.
- Use cached prototypes for object creation.
- Avoid working with strings as much as possible, use typed array when possible.
- Partial evaluation.
ps: Thank you for all your work in the Rust ecosystem, I've used a lot of your crates over the last year.
The optimizer assumes that a non-atomic non-volatile value written to memory stays the same, until some code that could modify it is executed. This allows a lot of obvious optimizations, like hoisting needlessly repeated computation out of loops, removal of redundant loads, and optimizations of common subexpressions and arithmetic.
If a value in memory could suddenly revert to something else, then
if obj.x == 1 {
print(obj.x)
}
could print "2", and such paradoxes can lead to unsafety:
if obj.x < array.len {
array[obj.x]
}
Defining that values in memory can't be trusted would mean giving up on a lot of optimizations, and require implementations to emit a lot of mostly-useless copying of values to protect them from being unexpectedly modified.
I think it's underappreciated that Rust's `unsafe{}` doesn't exist in isolation. Rust has facilities for building safe abstractions on top of it, and has a culture of taking this abstraction layer seriously.
Danger of unsafe features and FFI is usually conditional — you can use a pointer only until some point, or only on a single thread, etc. A use of unsafe in Rust doesn't become "be careful!" kryptonite spreading around the program. It's possible to build walls around it to contain it completely.
In Swift + unsafe or Java + JNI I've struggled building equally solid abstractions around FFI. They don't have "you can call it only once" or "you can't call go() after finish()" as a compile-time check. They don't have "you can use it only within this scope" (they may use a closure/callback to give access to an unsafe object, but these aren't hermetic, so that's a convention not a guarantee). Exposing objects to Swift or Java requires the higher level language to be in charge of their lifetime.
> They don't have "you can use it only within this scope" (they may use a closure/callback to give access to an unsafe object, but these aren't hermetic, so that's a convention not a guarantee).
You can use the same trick as Haskell's STRef to prevent reusing a "leaked" unsafe object, although it's cumbersome enough in Java that you may not want to.
The ST monad trick requires second-order polymorphism, though [to type runST :: forall a. (forall s. ST s a) -> a]. Are any of those languages capable of it?
Java certainly is; you might have to encode it as having your callback be an object with a (polymorphic) method, but for a long time that was something you had to do to express any callback in Java, so it's well-supported.
I haven’t had a chance to fully explore the new features and there are probably still some sharp edges, but the addition of non-copyable types and borrowing/consuming bindings in Swift 5.9 should bring it a lot closer to Rust in those respects, especially the hermeticity aspect. If you haven’t experimented recently, might be worth doing - this is also one of the big focuses of the language in the near term, so there should be lots more progress coming too.
Java’s recent Foreign Function & Memory API gives you temporal, spatial and thread-safety.
In short, foreign memory is represented as a Segment, with known bounds (it also has a possibility for unbounded “pointers”, for e.g. c strings), associated to a scope. It can only be used within that scope, and will get automatically closed at the end of it.
Visibility of multiple networks can be used to refine the position.
GPS takes time to acquire and isn't always available indoors. SSID method is quicker, and it's most likely the method your phone uses to get the position first.
As you say, it’s a method to get a coarse location and then refined using GPS which by the way does not really take time to acquire once you have downloaded the almanac and have the coarse location.
So this ‘allows applications to track location’ actually allows applications to track coarse location which then does not allow them to refine using GPS.
This is already a reality with the fully electric self-driving tech we have now: trains. And no, people still dislike long commutes, even if they can play steam deck on the train.
Whats an example of a “non legacy” manufacturer that has perfect software?
Im currently in the process of selling my Tesla (“non legacy manufacturer”) back under lemon law because of constant hardware and software issues like windows intermittently refusing to roll up (despite 6+ service center visits), windshield wipers not working, random alerts about “faults” they allegedly can’t locate in their logs, getting alerts on my phone that windows are left open when they’re not, lane departure warnings when the setting is turned off and i am not departing a lane, loud popping noises on speakers followed by infotainment “crashes”, etc.
That's a lemon. That's unacceptable of course. We do know from millions of teslas sold that they work fine over the mass of cars. They are made by people, they'll have problems, they will break. But the sum of experiences is good outcome. The opposite seems to be the case with the ultium cars.
A lot of that almost sounds like something is shorted in the wiring in the car, and the software doesn't understand that something is physically wrong.
Lots of hardware companies (not just auto makers) don't understand software. They treat it like just another line item on the BOM, like a bolt, a windshield wiper blade or a door panel. The purchasing guy finds some 'software' that barely meets the minimum written requirements at the cheapest price, they scoop it onto the product somewhere on the assembly line, and then never think about it again. This is how we get things like our TV's (pre-Google/Apple) on-screen menus and our printer's setup UI.
> The purchasing guy finds some 'software' that barely meets the minimum written requirements at the cheapest price, they scoop it onto the product somewhere on the assembly line, and then never think about it again.
Are you implying that car manufacturers are window shopping for off-the-shelf software to run the core embedded logic of their complicated and highly specialized electric motor vehicles? And there is such a plethora of OTS offerings they can go with the lowest bidder?
That's exactly what that person is "implying", and that person is correct. But with the caveat that this applies much more to things like infotainment than to things like engine control. Lots of car software is purchased off the shelf and then customized slightly for branding purposes. But obviously some manufacturers do write their own software. For instance, as far as I'm aware, Tesla's software is all written in house (someone can correct me if I'm wrong here).
> The purchasing guy finds some 'software' that barely meets the minimum written requirements at the cheapest price
You're talking about Microsoft Office 365, right ?
Software for your car (except Tesla early models) is written by SW engineers (not coders), under strict quality requirements, with very big time pressure. And it is tested. And it is an item on the BOM because, if it does not work, it is not released.
That was an epic screw up. Hopefully the only one that ever happens to them. New auto (tesla, rivian, ?) have generally avoided them.
Some of the details that got out about what happened at Rivian:
Problem cause #1: to push an update, you had to cut and paste various version numbers together onto a command line. Someone messed that up, oops, meant to say this instead of that.
Problem cause #2: bad test strategy. The dev tested it before he pushed it, so no worries? Except the dev test vehicle was a "special test car" that had extra security tokens on it. So the install worked and test passed. But regular cars didn't have those certs.
So lots of obvious things to fix there. No command line mucking about to push a real production release! And test the final thing on a regular fucking car with no special dev stuff.
Tesla has multiple hardware versions, and their main panel of the original S has a v1 and v2 main console hardware. They pushed a release once that broke things in the map for the original version that caused it to use an excessive amount of cpu. I got this one, seems like it just made everything really really slow and some things failed. It took them like a 6 weeks or more because they got around to undoing the fix. I think part of that was all of them had the updated cpu so they didn't see it. It was still driveable, just degraded infotainment ui.
VW has had software updates that they would not push over the air because they took so long the 12v battery could run out before it finished, risking bricking the car (main battery couldn't charge the 12v during os update). Solution, bring your car to the dealer to do the update. Apparently also considered giving everyone a better 12v battery.
