Chapel maybe, but it is too low level to attract a large public outside of the HPC community.
2,319 karma · joined September 13, 2018
I did not argue about CUDA being proper C++ :)
I honestly believe that the best days of C++ as an accelerator language are behind.
That is the main problem currently: We do miss a modern language for system programming that play well with accelerators. C++ is not (really) one of them (Hello aliasing).
I do not know if Mojo will succeed there, but I wish them good luck.
It is currently not straight Python and will never be.
All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.
They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues.
Lets not lie to ourself: Python is inherently bad for efficiency and performance.
And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency.
The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse.
Mojo is different.
Mojo tries to start from a clean sheet instead of hacking the existing crap.
And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old)
And just for that, I wish them success.
Interesting.
Zigbee has this distinction between router node and non-router node.
Routers are active members of the mesh (relay). Non-routers are just clients.
Most battery devices in Zigbee acts generally as non-router.
It is surprising that Meshtastic did not follow this pattern. Zigbee is not a young protocol.
I am curious about that.
What is in particular broken ?
Any reason why Meshtastic is not using a well specified / tested a mesh aware routing protocol like BATMAN [1] ?
Nor it is in C++. Most default flag setup will report implicit conversions on numerical as error in C++
Unsigned / signed is mainly an issue if your language chose to silent implicit conversions.
Which honestly, is terrible design beyond simply signed / unsigned.
If you live in Arizona or in tropical climate maybe. For anybody else it is bullshit.
Solar production fell to few percents of its peak when the sky is covered.
Many European regions can spent multiple weeks during Winter with the sky entirely covered.
BESS is nowhere near the capacity required to even go pass a single day. And it is unlikely to change even over the next 10y.
So hoping to run entirely on Solar + BESS for a multi week Dunkelflaute is living in dreamland, no reality.
What happens in practice is that country like Germany will need to have a backup Gaz that matches its peak consumption in Winter if they want to go full renewable.
The other option is to throw the problem on your neighbours with interconnects. This is what Germany does with mainly Norway, Sweden and France. And this is not a sustainable solution.
That is just economics.
The intermittent nature of renewable means that overcapacity is structurally required to arrive to match partially the demand.
As an example, Germany has > 100GW of Solar installed capacity for a country where the average power demand is around ~60GW *total*.
Overcapacity means that the price of electricity naturally goes to zero (or even to negative) as soon as the sun shine. And this is very visible on the EU electricity market currently [1].
It is (obviously) terrible for the profitability of the means of production and it is not sustainable: No investor sane of mind would put money on the table for a system that sell at negative price when it produces...
To compensate that, most EU countries created the CfDs (Contract for difference) system. A minimum price is guaranteed by contract to the investor and the State pay the difference when the price are too low. The UK did it (and it costs billions) [2], France did it (and it costs billions) [3] and Germany is doing it [4].
So we are subsidizing and using public money to create an artificial profitability on top of an industry that we know is not profitable due to overcapacity caused by bad public policies.
Considering that this overcapacity is also reducing the profitability of nuclear powerplants in the first place (because nuclear is CAPEX based).
The pain is triple: The final consumer pays (1) the cost of the Grid restructuring for renewable (2) the cost of the Cfds to maintain the system alive due to overcapacity (3) the additional €/MWh to the now reduced profitability of the historical production means.
So yes, at the end, the price increase.
And it is what we see currently everywhere in Europe: Electricity price are increasing continuously even if Solar/Wind LCOE is lower than ever.
[2]: https://davidturver.substack.com/p/another-record-year-cfd-s...
[3]: https://www.enerdata.net/publications/daily-energy-news/euro...
[4]: https://www.aoshearman.com/en/insights/germany-to-reset-gove...
No. Nuclear energy production in China continue to increase and will probably continue to increase for the next 60y.
Its relative percentage in the global mix decreased. And this has nothing to do with Solar, but with the insane amount of Coal power plants that China had to setup quickly to match the increasing electricity demand of the developing country [1]
> The nukes need to stay at 100% all the time selling their power at a high fixed price to have any remote chance of being economical.
Nuclear plants are mainly CAPEX based. And yes, excessive solar capacity tend to decrease nuclear profitability and increase global electricity cost.
But that is mainly a problem of public policy, not a technical one.
In country without tremendous of Hydro storage (e.g Switzerland or Norway), the most balanced economical combination tend to be Nuclear for baseload and Wind+Hydro+Storage for peaks.
It is not. And people who repeat this lie have generally very little clue of the reality of an electrical grid and how it is designed and managed in practice.
Solar and Wind are cheaper in term of LCOE. LCOE is a secondary metric in a much larger equation.
A grid is managed in term of instant power matching the demand, not in term of energy. That changes a lot over a simplistic LCOE view.
Take into consideration the cost of power lines, the necessity of backup for the long dunkelflaute, the increase of demand over winter and the problem ROI with the overcapacity of solar... and suddenly the equation is not that simple anymore.
In reality, it is not "Just build Wind/Solar + battery Bro": It is much more complex and highly geographically dependent.
(1) A country with a lot of Hydro can generally easy run full renewable with a lot of Wind: Hydro acts as both as storage and a regulation.
(2) A country without much Hydro has a interests to keep the baseload Nuclear. It is mostly CAPEX based and the most economical low CO2 source around.
(3) A sub-tropical / tropical country has all interests to Spawn solar arrays. The air con consumption tend to matches quite well the solar production. At the opposite, Solar is almost an annoyance to the grid in Nordic countries because it produces outside of the peak of consumption and is intermittent.
Like often: there is no silver bullet.
The only part of your sentence what is true, is that indeed 'New nuclear' is way more expensive that it should be. That is however not inevitable, China demonstrate that quite clearly [1].
[1]: https://hub.jhu.edu/2025/07/28/curbing-nuclear-power-plant-c...
It is not only the oil shock.
Most of the nuclear initiatives at the EU level have been mostly blocked by the German government for the last 15y.
The Russian gas crisis in 2022 reshuffled the cards entirely: Germany realized that constructing its entire energy policy on a foreign asset (Russian Gas) was not really a smart move.
The German position changed significantly after the crisis with Friedrich Merz explicitly called the German nuclear phaseout 'a mistake'.
Soon after, Nuclear energy stopped to be a swear word at EU level and EU funding streams seems to have opened up again for Nuclear power.
The recent oil crisis is just the last nail in the coffin of the anti-nuclear lobby.
Nope. Starlink is not a tool for poor people. It's first and foremost a tool for middle class living in rural area with poor connectivity.
As a comparison, it is estimated to that there is around 198M people in Nigeria with a Mobile phone connectivity. Compared around 67K Starlink users.
Mobile being around 2-3x cheaper than Starlink there (even without considering the hardware), it remains an upper middle class privilege.
Maybe. If you believe we are heading to a situation with large numbers of colonies on the moon.
For now we are no way there and already struggle to just get back there.
There are ITUs rules that forbid that and the far side of the moon is declared as radio quiet.
The situation is one order of magnitude worst in radio-astronomy.
It is fair to state that satellite constellations will certainly be the main obstacle to multiple major scientific discoveries in the next decade.
This is a pretty naive and innocent take. There is good reasons to why customers might continue to find value in Mistral A.I.
(1) - There is no particular reason why "European" model should be worst than "Chinese" one. GDPR restrictions are not such a big deal and have been made lighter recently [1]. And contrary to China, Europe is not under hardware embargo.
(2) - Most domains are not software engineering and do not need ultra advanced and extremely large models with complex agent setup to reach their optimum in term of A.I usage.
(3) - At the opposite, there is pretty good reasons why companies would want to use European operators with the current geopolitical context (e.g Cloud Act, Risk of data leaks, Regulations, Taxes, Reputation, Geo-political risk, ...).
[1]: https://digital-strategy.ec.europa.eu/en/faqs/digital-packag...
It is true. But the stock of old repairable tractor will soon or later run dry.
The price of some of these are currently increasing on the secondary market.
If you told me 20y ago, that the old rusty tractor in the neighbour Grand'Pa's storage would be an appreciating asset, I would have laugh.
There is a tradition in several European countries named Affouage: If you live in a rural area, you can get very cheap (or even free) wood at the condition that you go to cut it yourself in the close-by forest.
Many many people who are doing this practice are still using today Massy Fergusson 135, Renault R98/461, Ford 3000-4000 series, SOMECA or similar low tech tractors.
The reason are simple: They are cheap to operate, cheap to repair (damages happen easily forest environment) and their small size is perfect for the task.
The demand for these things will never die. Rugged environment requires cheap and robust hardware.
If this startup can capitalize on that, they do have a market.
'If I had asked people what they wanted, they would have said faster horses'....Henry Ford
Nobody cares about repairability....until they are hit hard by it.
Anecdote: Around 5y ago, the lightning connector of my wife's iPhone died after 3y usage.
We brought it to an Apple Store and the official answer was "Sorry, we don't fix that on this model. Here is a 200€ discount on a new one"... The phone was still worth >900€ at the time.
Let's be clear: This kind of commercial practice are unacceptable both ecologically and ethically speaking. It is terrible customer service.
A lot of high end phones (outside Apple) at the time would have their USB-C port fixed in matter of few hours for <100€ in any random "I Fix it" store.
The battery is the exact same shit.
The quality of European publicly owned medias is highly country specific and variates quite a lot:
- Some of them are critically underfunded and it becomes visible (tendency to cheap sensationalism, superficial investigation or recycled content).
- Some of them are politically rooted (Left or Right) or controlled due to a direct/indirect government involvment.
But all considered: I would say that the average are still an order of magnitude better in term of content quality and independence that the average privatized media.
- The documentary is from the RTS. The RTS is the main publicly owned media from Switzerland. They are not the typical European owned public media: They are generally pretty well funded (contrary to most). They also tend to generate good (high) quality content, tend to be independent and rather neutral (leaning slightly to the left politically speaking).
- The video is in French because, in Switzerland, the media are divided in three group associated to the regional languages: RTS for the French, SSR for the German and RSI for the Italian. Thats why you do get German translation.
- They are generally pretty cooperative and open minded. If one of you want to submit english subtitles. Just contact them, they might accept it (I do not promise anything).
That's the neat part: You do not have too package for all the distro.
Just make your components easy to decouple with provided pkg-config (ideally) and a proper configuration mechanism.
No bundle, no hidden download or tangled vendored messy script.
Then it is easy to do: you can just provide the packages for your main targets (e.g Ubuntu, Redhat typically) and the community of other distros will take care of the rest.
(1) - Supporting only Server grade hardware and ignoring laptop/consumer grade GPU/APU for ROCm was a terrible strategical mistake.
A lot of developers experiments first and foremost on their personal laptop first and scale on expensive, professional grade hardware later. In addition: some developers simply do not have the money to buy server grade hardware.
By locking ROCm only to server grade GPUs, you restrict the potential list of contributors to your OSS ROCm ecosystem to few large AI users and few HPC centers... Meaning virtually nobody.
A much more sensible strategy would be to provide degraded performance for ROCm on top of consummer GPUs, and this is exactly what Nvidia with CUDA is doing.
This is changing but you need to send a clear message there. EVERY new released device should be properly supported by ROCm.
- (2) Supporting only the two last generations of architecture is not what customers want to see.
https://rocm.docs.amd.com/projects/install-on-linux/en/docs-...
People with existing GPU codebase invests significant amount of effort to support ROCm.
Saying them two years later: "Sorry you are out of update now!" when the ecosystem is still unstable is unacceptable.
CUDA excels to backward compatibility. The fact you ignore it entirely plays against you.
(3) - Focusing exclusively on Triton and making HIP a second class citizen is non-sensical.
AI might get all the buzz and the money right now, we go it.
It might look sensible on the surface to focus on Python-base, AI focused, tools like Triton and supporting them is definitively necessary.
But there is a tremendous amount of code that is relying on C++ and C to run over GPU (HPC, simulation, scientific, imaging, ....) and that will remain there for the multiple decades to come.
Ignoring that is loosing, again, custumers to CUDA.
It is currently pretty ironic to see such a move like that considering that AMD GPUs currently tend to be highly competitive over FP64, meaning good for these kind of applications. You are throwing away one of your own competitive advantage...
(4) - Last but not least: Please focus a bit on the packaging of your software solution.
There has been complained on this for the last 5 years and not much changed.
Working with distributions packagers and integrating with them does not cost much... This would currently give you a competitive advantage over Nvidia..
This is due to the physics reality of the ground itself: Power of a Geothermal well will decay over time to a point where the well become unusable and need to be closed.
It is due to the fact underground water is rich in minerals and raw elements. This soup will slowly but surely cement the well itself and its associated underground.
There are techniques (similar to 'fraking') to extend the lifetime of a well but only to some extent.
If the topic interests you (and you can bear artificially translated English), a French content creator did a pretty good video on the topic:
https://m.youtube.com/watch?v=q4xZArgOIWc
Additionally, Geothermal plants can emit CO2 (even a lot of CO2) in some geological configuration.
All of that makes Geothermal (for electricity) a bit controversial as "Renewable".
I precise that there is absolutely nothing wrong about low temperature Geothermal energy for residential heating and we should do more.
Feasible but difficult. CMake has a tremendous user mass, so you do want to be able to use a CMake-based project as a dependency. The CMake Target/Config export system expose CMake internals and make that difficult to consume a CMake built project without CMake.
The cleanest way to do that is probably what xmake is doing: Calling cmake and extract targets information from CMake to your own build system with some scripting. It is flaky but xmake has proven it is doable.
That's said: CPS should make that easier on the longer term.
Please also consider that CMake is doing a lot of work under the hood to contains compiler quirks that you will have to do manually.
> integration of other languages in the project?
Trying to integrate higher level languages (Python, JS) in package managers of lower level languages (C, C++) is generally a bad idea.
The dependency relation is inverted and interoperability betweens package managers is always poor. Diamond dependency and conflicting versions will become quickly a problem.
I would advise to just expose properly your build system with the properties I described and use a multi-language package manager (e.g Nix) or, at default, the higher level language package manager (e.g uv with a scikit-build-core equivalent) on top of that.
This will be one order of magnitude easier to do.
> how to handle qt?
Qt is nothing special to handle.
Qt is a multi language framework (C++, MOC, QML, JS and even python for PySide) and need to be handle as such.
It is completely fine to use -march=native, just do not make it the default for someone building your project.
That should always be something to opt-in.
The main reason is that software are a composite of (many) components. It becomes quickly a pain in the ass of maintainability if any tiny library somewhere try to sneak in '-march=native' that will make the final binary randomly crash with an illegal instruction error if executed on any CPU that is not exactly the same than the host.
When you design a build system configuration, think for the others first (the users of your software), and yourself after.
The 15000 was a typo on my side. Fixed.
- (1) Provide a way to compile without internet access and specify the associated dependencies path manually. This is absolutely critical.
Most 'serious' multi-language package managers and integration systems are building in a sandbox without internet access for security reasons and reproducibility reasons.
If your build system does not allow to build offline and with manually specified dependencies, you will make life of integrators and package managers miserable and they will avoid your project.
(2) Never ever build in '-03 -march=native' by default. This is always a red flag and a sign of immaturity. People expect code to be portable and shippable.
Good default options should be CMake equivalent of "RelWithDebInfo" (meaning: -O2 -g -DNDEBUG ).
-O3 can be argued. -march=native is always always a mistake.
- (3) Allow your build tool to be built by an other build tool (e.g CMake).
Anybody caring about reproducibility will want to start from sources, not from a pre-compiled binary. This also matter for cross compilation.
- (4) Please offer a compatibility with pkg-config (https://en.wikipedia.org/wiki/Pkg-config) and if possible CPS (https://cps-org.github.io/cps/overview.html) for both consumption and generation.
They are what will allow interoperability between your system and other build systems.
- (5) last but not least: Consider seriously the cross-compilation use case.
It is common in the world of embedded systems to cross compile. Any build system that does not support cross-compilation will be de facto banned from the embedded domain.
That's not what he said. He said this is the scenario in case of full cycle up and down every day. Which is obviously not how a central is operated.
Consensus today is that nuclear powerplant can live for around 60-80y without issues if the maintenance is done properly. The US park is getting there.
> This simply wouldn't have happened if it hadn't been necessary, the government wouldn't have allowed it at the time.
The government has no word to say over an ASN decision, specially when Nuclear safety is at stake.
It is France we are talking about, not the USSR.
Again, it is commonly admitted today, after the facts, that it was over-reacting. Thats said: It is bad economically as it cost EDF few billions. But it is exactly what you want to see for safety: Better overreacting than having an incident.
> A few years pass again and some people are talking themselves again into this technology being anything except useless.
So. You are taking one single year failure as a representative example of a technology that has given cheap, abundant and low carbon electricity for the entire Europeean continent for 3 decades ?
Do you have not the impression of being of slightly bad faith here ?
Because reality is very different of propagandists and lobby reports.
Currently, not a single major country right now can afford to have energy storage capacity large enough to pass, even a single day, without sun if running exclusively on solar power.
Not even China, the biggest battery provider world wide.
Considering that to get a stable and reliable grid, the needed capacity would need to supply for weeks during Dunkelflautes, this is realisitically not going to happen before multiple decades.
China has an energy problem it need to solve now: The country is developing so its electricity consumption is growing, rapidly.
Their solution is the most pragmatic on short term: Building coal plants.
Their long term solution is also the most pragmatic on long term: Using Nuclear energy to support the baseload and a mix of hydro, solar, wind for the peaks.