As someone who spent a few years working on a compiler in this space — it’s tough, but are the results of instant startup and immediately decent performance without warm-up satisfying to use in practice. I really hope this takes off and yet another language can break free from dominant interpreter + jit compiler monoculture that we currently have for higher-level programming languages.
I usually use center 2/3 of 27'' screen with just a single top-level window for a similar reason. That puts it up to around 20.5'' and around 6:5 aspect ratio. I don't find having many windows shown at the same competing for my attention more productive. I don't benefit from having multiple code columns shown at once that much either and would rather switch among tabs or windows via shortcuts.
For me Mathematica is much more akin to numpy+sympy+matplotlib+... with absolutely crazy amount of batteries included in a single coherent package with IDE and fantastic documentation. In a way numpy ecosystem already "won" industry users over, yet Wolfram stack is still appealing to me personally for small experiments.
Dimming reduces total brightness over time and shifts color balance away from neutral. Latest "Pro" displays from Apple now have built-in support for calibration but only with high end calibration equipment: https://support.apple.com/en-gb/guide/mac-help/mchl628f5edf/...
The implementation is great, since it doesn't add fix up profile on top factory calibration, but actually fully replaces factory calibration internal LUT. It worked wonders to completely fix my M1 MBP screen that got noticeably tinted over time. I don't mind brightness reduction since I almost never use it at more than 200 nits, usually around 100. Nominal 1600 leaves lots of buffer for decay over time.
I've had similar issue my OLED TV with the same fix. Got my LG C1 calibrated as well and it looks fantastic again.
It's a shame there are no iOS or Android phones that support calibration out of the box. Some iPads support subset of pro display calibration software (called fine tune calibration), but still lack full recalibration support.
Don't get me wrong it's a fantastic product and great price point, but the only thing it makes me think of is the complete failure of iPadOS. Ultra portable MacBook with is A18 with 8G of ram is infinitely more useful to me (for non-pen input) than full M4/M5 chip with more ram that's completely wasted due to needless OS restrictions.
I might be the only one, but it's still to this date (and dating all the way back to 2014 with the first iMac 5k display) Apple is the only company that truly gets HIDPI desktop displays with high quality gloss and 200+ ppi at screen this large. In the meantime popular and widely sold gaming screens with matte blur filters and mediocre ppi give me headache and eye fatigue after a few hours of use. Prior generation Studio Display is the only external display that truly worked for text heavy work with my eyes (including software engineering), and I'm sure the latest generation is fantastic as well.
Apart from prioritizing FFI (like Java/Scala, Erlang/Elixir), the other two easy ways to bootstrap an integration of a new obscure or relatively new programming language is to focus on RPC (ffi through network) or file input-output (parse and produce well known file formats to integrate with other tools at Bash level).
I find it very surprising that nobody tried to make something like gRPC as an interop story for a new language, with an easy way to write impure "extensions" in other languages and let your pure/formal/dependently typed language implement the rest purely through immutable message passing over gRPC boundary. Want file i/o? Implement gRPC endpoint in Go, and let your language send read/write messages to it without having to deal with antiquated and memory unsafe Posix layer.
For example let's say I want to go to display settings from search. I enter 'monitor' in search since I forgot how it's called. First results: accessibility, privacy and security, control center, and only 4-th category Displays. It's 8-th line if you count sub-categories.
I usually google where a particular setting is now since I don't use the exact same words and the settings search is very literal.
Have any studies been done on the use of newer or less popular programming languages in the era of LLMs? I'd guess that the relatively low number of examples and the overall amount of code available publicly in a particular language means that LLM output is less likely to be good.
If the hypothesis is correct, it sets an incredibly high bar for starting a new programming language today. Not only does one need to develop compiler, runtime, libraries, and IDE support (which is a tall order by itself), but one must also provide enough data for LLMs to be trained on, or even provide a custom fine-tuned snapshot of one of the open models for the new language.
There are two variations of the B permit one can get. An unrestricted B permit isn't tied to a specific employer and provides a path toward permanent residence (C permit) within five years for EU citizens or ten years for non-EU citizens. Based on my experience, EU citizens almost always get an unrestricted permit and are treated relatively well by the immigration process: at their first application, they receive a five-year B permit, and at the first renewal five years later, they automatically get a C permit. As a EU citizen you just need to find a job, and your right to work is essentially unrestricted.
The non-EU path is quite different. A non-EU citizen only gets an unrestricted B permit if they prove they have special skills that are not currently available on the local job market. There is a yearly quota for such permits. One can also be unlucky and get an L permit, which is for temporary work only. Moreover, restricted B requires yearly renewal with a demonstration of ongoing employment at each renewal.
If you get a restricted B permit (or L), you don't have any direct path to a C permit, no matter how many years you've lived in Switzerland. You can complete your bachelor's, master's, and PhD degrees and continue working for a university as a contractor afterward, and still not be eligible for the path toward a C permit after over a decade of living in the country. To get a C permit, the last two years prior to the application must have been on an unrestricted B permit, working a full-time, unlimited-term job contract. The change to an unrestricted B permit requires you to have become a "special talent" during those prior years; otherwise, it won't be granted.
For anyone interested in playing with distributed systems, I'd really recommend getting a single machine with latest 16-core CPU from AMD and just running 8 virtual machines on it. 8 virtual machines, with 4 hyper threads pinned per machine, and 1/8 of total RAM per machine. Create a network between them virtually within your virtualization software of choice (such as Proxmox).
And suddenly you can start playing with distributed software, even though it's running on a single machine. For resiliency tests you can unplug one machine at a time with a single click. It will annihilate a Pi cluster in Perf/W as well, and you don't have to assemble a complex web of components to make it work. Just a single CPU, motherboard, m.2 SSD, and two sticks of RAM.
Naturally, using a high core count machine without virtualization will get you best overall Perf/W in most benchmarks. What's also important but often not highlighted in benchmarks in Idle W if you'd like to keep your cluster running, and only use it occasionally.
Hey, as someone who spent a few years reimplementing another language trying to decouple it from JVM (Scala JVM -> Scala Native), some pitfalls to avoid:
- Don't try to provide backwards compatible subset of JVM APIs. While this might seem tempting to support very important library X with just a bit of work, I'd rather see new APIs that are only possible with your language / runtime. Otherwise you might end up stuck in never-ending stream of requests to add one more JVM feature to get yet another library from the original JVM language running. Focus on providing your own unique APIs or bindings to native projects that might not be easy to do elsewhere.
- Don't implement your own GC, just use mmtk [1]. It takes a really long time to implement something competitive, and mmtk already has an extensible and pluggable GC design that gets some of the best performance available today [2] without much effort on your end.
- Don't underestimate complexity and importance of multi-threading and concurrency. Try to think of supporting some form of it early or you might get stuck single threaded world forever (see CPython). Maybe you don't do shared memory multi threading and then it could be quite easy to implement (as in erlang). No shared memory also means no shared heap, which makes GCs's life much easier.
- Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline. If you don't have a compelling use case (usually due to unique libraries), the performance might not matter enough for users to migrate to your language. When you do optimize, I'd rather see fast startup, interactive environment (think V8), over slow startup but eventually efficient after super long warmup (like jvm).
I see that jank is already doing at least some of the things right based on the docs, so this message might be more of a dump of mistakes I've done previously in this space.