141–150 of 185 posts
Earlier quoted context omitted.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
By the virtue of being the most convenient alternative, not because its actually good.
32 bit 4mhz processor with ~64kb of nvram all running off of an induction charge!
Earlier quoted context omitted.
> writing a full OS in Java IMAO, Android kind of achieve that...kind of. They write lots of OS logics in Java (or Kotlin) but mixing lots of system services written in native code at the same time, interconnected by the famous (or infamous?) Bind IPC.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
Earlier quoted context omitted.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
Don't forget the Java Ring! https://www.ebay.com/itm/300495374337
That is pretty awesome! When I joined the Java effort in '92 (called Oak at the time) the group I was with was looking at writing a full OS in Java. The idea being that you could get to just the minimal set of things needed as "machine code" (aka native methods) you could reduce the attack surface of an embedded OS. (originally Java was targeted to run in things like TV's and other appliances). We were, of course, wo…
There was one for a while though wasn't really targeted at users: https://en.wikipedia.org/wiki/JavaOS
Earlier quoted context omitted.
By the virtue of being the most convenient alternative, not because its actually good.
How is that not actually good? Engineering is all about tradeoffs, and ‘works’ is pretty high praise frankly.
Earlier quoted context omitted.
I find that Rust is like maybe 1.5-2x more productive to code in than say C or C++. Part of that is the tooling has so much less arcane baggage, part of that is that I need to reach less for external tools for metaprogramming, part of that is fewer crazy macro/template compiler errors, and part of that is less time spent debugging. It all adds up.
I've heard very inconsistent things about this, which is interesting. Often people say Rust is less productive, as there's often "makework" involved with satisfying the borrow checker. I suspect a lot of it revolves around how you perceive that sort of thing: it can be cast as both productivity (satisfying it can potentially rule out bugs) or a loss of productivity (you were already satisfied the code was correct). B…
The borrow checker slowed me down a lot at the start but these days it's not a big deal. Eventually you internalize the easiest ways to make it happy (clone and pass references as needed) and can reserve tricky optimizations for hot paths where they actually matter.
I would say that today, most of the times I sit down to write some Rust I'm nearly as productive as in higher-level languages... but then ~20% of the time I get bogged down in complicated type signature stuff (especially with async code, ugh) and it's a time suck.
Earlier quoted context omitted.
How is that not actually good? Engineering is all about tradeoffs, and ‘works’ is pretty high praise frankly.
You can justify every project that has succeeded against any odds by saying "but it did succeed". It's true, but imo not a very good way of judging when a technology was a good fit or not.
Ideological purity is rather subjective, and has an unfortunately poor track record of real world success.
Earlier quoted context omitted.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
Also many SIM cards (UICCs) / embedded SIM modules as well as e.g. the Secure Element that Samsung uses for Knox run with Java Card.
Earlier quoted context omitted.
Embedded JVM is actually huge/pervasive and runs things as benign as the chip on your credit card.
After reading your comment I was surprised to find out that credit card chips have any processing capabilities whatsoever, which they apparently do, though at least according to gpt4, they are far too basic to run java/jvm. ?
Earlier quoted context omitted.
By the virtue of being the most convenient alternative, not because its actually good.
It's actually very well suited to low level extremely low power embedded systems. The toolkit and dev experience targeting these platforms is actually pretty good DX. 32 bit 4mhz processor with ~64kb of nvram all running off of an induction charge!