No state has the right to exist, that thought terminating cliche makes no sense legally or philosophically. States are recognised by other states, with no legal rights involved. Also claiming that a call for the end of a state is a call for genocide is ludicrous, if that was the case then every revolution in world history would be a genocide.
That was their voluntary decision supported by the population of both states.
A closer analogy would have been some proposals to dissolve the German state forever after WW2, and get its parts annexed by other states. But that didn't happen.
Not to mention that Nazi Germany was actually doing an actual genocide. But that wasn't sufficient to warrant the same fate for them as a nation.
The latter part definitely did. See Konigsberg (now Kaliningrad, a Russian exclave) and all the parts of Germany that were ceded to Poland.
And the expulsion of ethnic Germans living in non-German lands across Europe postwar was certainly a form of ethnic cleansing, even if you believe it was justified to remove the justification Germany had for prewar annexations like the Sudetenland.
> It's almost like if bureaucrats who are writing regulations are experienced in writing regulations in such a way they can't be circumvented.
Americans often seem to have the view that lawmakers are bumbling buffoons who just make up laws on the spot with no thought given to loop holes or consequences. That might be how they do it over there, but it's not really how it works here.
You can also set up DNS records pointing to your home server's VPN IP, which, with Tailscale, I've found to be pretty static and then a reverse proxy on your home server. So I have my home network apps running on app1.my-domiain.com app2.my-domain.com, app3.my-domain.com etc, which only work when I'm connected to the VPN.
The downsides are that I need to be connected to the VPN at home to use the domain and I currently don't have SSL set up on the domains, so browsers complain when I connect to them. The second problem I could fix, but I'm not sure if there's a solution for the first.
You can fix them both in one. In your local network you host a local DNS, in my case I’m using pihole. It has records which point to the local IP of a reverse proxy. With this setup you can have SSL for your domain names on your local network.
To make it then work outside your local network, in tailscale settings you use “split dns” to set your DNS to be the IP of your pihole in the tailnet for your domain. Now when you try hit your local domains you should receive the same local IPs that you do at home. Then in the tailscale route settings of your machine hosting the reverse proxy you make it advertise the subnet of those local IPs. Now when you receive the local IPs your devices using the tailscale VPN should go to your home server with SSL and no external DNS.
There is a solution for the first. I have setup my home server torun Tailscale _and_ be a router to 192.168.2.x network (you can set this up in the Tailscale UI). I have server.mydomain.com to resolve to 192.168.2.x address and this way I can access it from the outside via Tailscale and from inside without the need to turn on Tailscale. I have https setup via DNS-01 challenge as well and updated automatically.
That's certainly not a criticism that could be levelled at Giantbomb, considering it was started when its founder, Jeff Gerstman, was fired from his job at GameSpot for giving a game a low review score while the developer of the game was doing a big marketing campaign on the site.
It's been widely understood in the Ruby community for some time now that metaprogramming—like in the example above—should generally be limited to framework or library code, and avoided in regular application code.
Dynamically generated methods can provide amazing DX when used appropriately. A classic example from Rails is belongs_to, which dynamically defines methods based on the arguments provided:
class Post < ApplicationRecord
belongs_to :user
end
This generates methods like:
post.user - retrieves the associated user
post.user=(user) - sets the associated user
post.user_changed? - returns true if the user foreign key has changed.
Aren’t all these enhancement methods that are added dynamically to every ActiveRecord a major reason why regular AR calls are painfully slow and it’s better to use .pluck() instead? One builds a whole object from pieces, the other vomits put an array?
It's simply not true that "regular AR calls are painfully slow." In the context of a web request, the time spent instantiating Active Record objects is negligible. For example, on my laptop:
Active Record methods are defined at application boot time as part of the class, they're not rebuilt each time an instance is created. So in a typical web app, there's virtually no performance penalty for working with Active Record objects.
And when you do need raw data without object overhead, .pluck and similar methods are available. It’s just a matter of understanding your use case and choosing the right tool for the job.
This is an interesting project! I'm going to recommend it to my team at work, since we've been moving to try to self-host more of our services.
I've been about building a Once-style project myself, how do you deal with tracking the licences, do you have the ability to revoke them if someone breaks the licence?
Hey Chris! If you or your team have any questions about Telebugs, feel free to shoot me an email at kyrylo@telebugs.com. I can set up a private demo just for your team.
Re: your ONCE-style project. That’s exciting! I wasn’t sure from your phrasing whether you’ve already started or are just about to. What does (or will) your project do?
As for licensing: I do have the ability to revoke a license, which means you wouldn’t get future updates. But of course, I can’t take back anything you’ve already downloaded (the code stays yours).
Sorry I meant to say "I've been thinking about building a Once style project" I've just got a couple of not very well fleshed out ideas at the moment.
In terms of licencing it's interesting, I suppose you could have the app phone home periodically, but since it's source available, someone could just remove that call. I guess the main idea is just that it's software for businesses and legitimate businesses generally aren't going to break licence agreements.
Thanks, I’m looking forward to hearing from your team!
I plan to document what it takes to build a ONCE-style product. It'll probably be a blog post (or a few). If you're curious, feel free to stay in touch - links are in my bio.
The app doesn’t phone home, for the exact reasons you mentioned. I also don’t want it to feel like you’re locked in a cage. I’m trying to build something I’d genuinely love to use, and ONCE gets a lot of that right.
I recently read The Ministry for the Future by Kim Stanley Robinson, and one of the ideas in it that I thought was very good was replacing our cargo ships with wind-powered ships, basically giant sailing ships. In the book, they were incredibly slow, with shipments taking months to complete, but if supply lines were set up correctly, that wouldn't matter for a lot of cargo. Cargo ships are a massive CO2 contributor, and it was interesting that a solution could be to return to sailing ships.
I know there are probably huge engineering problems preventing this from happening, so feel free to tell me why it's impossible.
Currently, ships need human sailors. They perform maintenance aboard ship as well as have legal oversight of the craft. We are not yet able to replace the crew with automation.
It's difficult to find skilled crewmembers willing to sign up to extremely long rotations away from home.
It just takes money. $100k-$300k/yr is plenty to have your pick of pretty good people, especially if there are any perks like the food being halfway decent (should be basically a given if you have to pay the chef a lot anyway).
That's not even close to true for the kind of large shipping we're talking about. Crews are small (the Ever Given had 25 people on board) but the ships they crew take up to ~100k gallons of fuel per day (Ever Given has a fuel capacity of 3622168.679 gallons, 13711400 liters, and is set up for voyages of ~30 days underway).
Fuel costs are ~$2.5 USD/gallon for bunker fuel. That means a cool $200k per day (conservatively).
It is absolutely not the personnel costs that'd be the big differences in expenses.
Not really. The unit economics work out heavily in favor of wind even with slower trips and absurd wages and the fact that oil has its externalities pushed to other people. Ignoring local manufacturing minima, the reason we don't do more of it is that the capital outlay is important and heavily favors faster trips, much like how excess solar for refinery power isn't often enticing because the factory spends too much time idle. Combine that with manuverability in canals (so you probably need a powerful engine anyway), and the project needs a lot of TLC to make economic sense while oil is subsidized to this degree, but unit costs aren't the culprit, and even wages at that extreme are totally fine.
But, ships need far smaller crews than they did in the past. A tall ship takes a larger crew than a steamship back in the 1980s. (I've crossed the Atlantic both ways.) Today, with automation, we have unattended engine rooms (unattended machinery spaces or UMS). You'll never totally eliminate a crew, for hte reasons you mention; but, we've reduced the size significantly.
> Nuclear ships are currently the responsibility of their own countries, but none are involved in international trade. As a result of this work in 2014 two papers on commercial nuclear marine propulsion were published by Lloyd's Register and the other members of this consortium....
> This is a small fast-neutron reactor using lead–bismuth eutectic cooling and able to operate for ten full-power years before refueling, and in service last for a 25-year operational life of the vessel. They conclude that the concept is feasible, but further maturity of nuclear technology and the development and harmonisation of the regulatory framework would be necessary before the concept would be viable.
> In December 2023, the Jiangnan Shipyard under the China State Shipbuilding Corporation officially released a design of a 24000 TEU-class container ship — known as the KUN-24AP — at Marintec China 2023, a premier maritime industry exhibition held in Shanghai. The container ship is reported to be powered by a thorium-based molten salt reactor, making it a first thorium-powered container ship and, if completed, the largest nuclear-powered container ship in the world.
Nuclear ships are technically possible, but have a massive number of downsides.
- The construction cost would be significantly higher than a conventional ship.
- Reactors are far from trivial, so you'd double or triple the crew required.
- Shipbreaking would become even more of an issue than it already is. You can't just beach a ship like this in Bangladesh and have a bunch of untrained people attack it with plasma cutters.
- The ship would be a huge target for pirates and terrorists. It's essentially a floating dirty bomb, after all, just waiting for the USS Cole treatment.
- A lot of countries would not accept nuclear ships, both due to perceived security risks and for more ideological reasons.
... and that's probably only the tip of the iceberg.
Nuclear is barely economically viable with land-based large-scale nuclear power plants running for 50+ years. They are an attractive option for some military ships, but I doubt anyone would be willing to risk it for regular commercial shipping.
> This source of power confers some advantages. "You will have ships going maybe 50% faster because the fuel is essentially free once you have made the upfront capex investment," Sohmen-Pao said.
You achieve ~0 emissions AND avoid increasing transit time going with pure sailing ships.
We should not under-estimate the need for speed in supply chains. Predicting future demand is hard. To be more specific, we're talking about predicting ~100M unique products (the order of magnitude that moves on the pacific) and some of them have very lumpy demand (e.g. invent a new product, but it depends on 100 other obscure products).
> if supply lines were set up correctly, that wouldn't matter for a lot of cargo.
One of the big problems facing logistics across the board is just optimization. But at some point, you run out of intuition to uncover more efficiencies. This space is actually a really good use for AI. In fact, it's even useful for predicting what to put on that boat ahead of when it's ordered/purchased (up to a point). So yes, longer shipping times might not be that big a deal for non-perishables and frozen products.
Not really. They’re 1.6% of global emissions if I multiplied the numbers on this page out right. The table says they’re 20% of shipping emissions, and the intro says shipping is 8% of global emissions (excluding ports and warehouses).
This result seems surprising until you realize that semi trucks produce 100x more CO2 per kg-mile of cargo.
We probably don’t have the physical space to onshore 6x the capacity in warehouse or whatever it would work out to around ports. Short of multilevel warehouses but I mean containers have been stacked 5 high since covid around the port of LA and I think that is about the limit without some significant rethinking of process. Maybe the ships could just anchor off shore for longer and function as the warehouse.
Because floating solar panels add drag proportional to their area, and it takes a lot of area of panels to power a motor that is sufficient for a cargo ship even without the added drag of the panels. Also, because oceans and the things one runs into in them aren't easy on solar panels being dragged along by cargo ships.
i wish there was more talk about this. it seems i heard a lot about making hydrocarbons from co2 in the air + solar or algae a couple years ago. if your hydrocarbons are made this way it seems they would be carbon neutral.
i'm guessing there's more research to make it feasable since i haven't seen "carbon neutral gas alternative" at the local Chevron.
There has been quite some buzz about ammonia, as it is fairly easy to turn electricity into hydrogen, and hydrogen into ammonia. It has a reasonably high energy density, is not too nasty to handle, and already has a huge industry built around it.
My understanding is that drag is more about the "front-on" view of a craft than how long the craft is.
Since solar panels are very thin and aimed up, it feels like they add minimal cross-sectional area to the craft. Your assertion seems trivially incorrect to me?
Oceans can be extremely rough, but even mild waves make it inappropriate to approximate PV as thin.
The requisite area to power a ship is huge, something like 1.4km^2 (ballpark estimate for 20% cells, reasonable capacity factor guess, 60 MW consumption requirement). If a ship is about 30m wide, it's trailing about 45 km of PV. You're not even into 4 digits of cargo ships before the combined length is longer than the circumference of the planet.
> My understanding is that drag is more about the "front-on" view of a craft than how long the craft is.
Drag (fluid mechanics generally) is... ludicrously complicated. For the typical shapes of ships, I believe you are correct that the main factor is cross sectional area perpendicular to the direction of travel, but that’s not universally true. i think that for a floating raft of panels, it would be proportional to the panel area, similar to how for winged aicraft its the wing area and not the cross section perpendicular to direction of travel.
There's a pressure drag and skin friction drag. Friction drag is supposedly a majority component unless you sail a brick. But I don't have sources to prove that.
Interesting idea, but that would require more than a square kilometer (or a 100m strip 10km long) of solar panels (not accounting for the additional power required to tow the panel array).
Solar power being useful doesn’t require 100% of propulsion to come from solar panels.
You see solar panels added to a wide range of boats because even bunker fuel isn’t free and panels are light for the power they provide over even a few days. A current 399.9 * 61.3m container ship doesn’t need panels everywhere to benefit, but the potential savings is significant if they do.
This is unfortunately not true because of the dynamics of diesel engines: there is by design surplus energy relative to requirements from running them at efficient operating points. Otherwise the ship is not a good ship.
You can always scale design to fit reduced demand. Also, loss of efficiency is more than made up for with vastly lower energy demand.
“Lowering speed reduces fuel consumption because the force of drag imparted by a fluid increases quadratically with increase in speed. Thus traveling twice as fast requires four times as much energy and therefore fuel for a given distance.”
“Container ship Emma Mærsk in Aarhus, 5 September 2006
Mærsk Line's E-class container ships such as the Emma Mærsk can save 4 metric kilotons of fuel oil on a Europe-Singapore voyage by slow steaming.[5] At typical fuel prices of US$600-700 per tonne,[4] this works out to a saving of US$2.4-2.8 million on a typical one-way voyage. Maersk's Triple E-class container ships were designed for slow steaming and have less powerful engines than their predecessors.[5]”
What you seem to be missing is that your understanding is not true because of the practical realities of operating large internal combustion engines.
For example, one tonne of fuel is about 11 MWh. So if you run the calculations, you will see that adding solar panels to a diesel boat, even if the energy they provide is free, essentially never ROIs, and makes the boat less reliable and useful as a boat.
These kinds of engines generate tens of megawatts when they are on, and they are always on when the ship is moving.
One tonne of fuel is more like 5.5 MWh. You did a mathematical calculation while ignoring engine efficiency.
The reality of large internal combustion engines is you still pay for every single kWh. These ships already have extremely complex electrical systems with multiple redundancies and load balancing etc.
The dealbreaker is R&D as unlike a house or sailboat you can’t just yolo where panels are placed and wires run etc, this is all bespoke engineering with few of any give design being manufactured and little available space.
No, one tonne of diesel fuel contains about 11 MWh of potential energy as determined by calorimetric methods. One tonne of fuel when consumed produces a variable amount of useful energy output depending on the efficiency of the engine.
If you said fuel was 5.5 MWh per tonne people would wonder what you cut it with.
The reality of outputting 80MW is that the power to your lights is a rounding error and you’d be better off buying a robot to regularly clean the hull.
> No, one tonne of diesel fuel contains about 11 MWh of potential energy as determined by calorimetric methods. One tonne of fuel when consumed produces a variable amount of useful energy output depending on the efficiency of the engine.
That’s almost correct, good try.
> lights is a rounding error
Ships use electrical power for far more than lighting, and no electricity is not a rounding error compared to profit it’s a significant expense for cargo ships.
I'm not an expert, but I've worked close to some of the engines that power those ships. My gut feeling is that you're vastly underestimating how much power those ships consume (and therefore produce).
Between Rails At Scale and byroot's blogs, it's currently a fantastic time to be interested in in-depth discussions around Ruby internals and performance! And with all the recent improvements in Ruby and Rails, it's a great time to be a Rubyist in general!
Is it? To me it seems like Ruby is declining [1]. It's still popular for a specific niche of applications, but to me it seems like it's well past its days of glory. Recent improvements are nice, but is a JIT really that exciting technologically in 2025?
Ruby will probably never again be the most popular language in the world, and it doesn't need to be for the people who enjoy it to be excited about the recent improvements in performance, documentation, tooling, ecosystem, and community.
I think ruby can get popular again with the sort of contrarian things Rails is doing like helping developers exit Cloud.
There isn’t really a much more productive web dev setup than Rails + your favorite LLM tool. Will take time to earn Gen Z back to Rails though and away from Python/TS or Go/Rust.
My impression is that a Rails app is an unmaintainable dynamically-typed ball of mud that might give you the fast upfront development to get to a market or get funded but will quickly fall apart at scale, e.g. Twitter fail whale. And Ruby is too full of "magic" that quickly makes it too hard to tell what's going on or accidentally make something grossly inefficient if you don't understand the magic, which defeats the point of the convenience. Is this perception outdated, and if so what changed?
If the the Twitter fail whale is your concern, then your perception is outdated. Twitter started moving off Ruby in 2009. Both the CRuby VM and Rails have seen extensive development during that decade and a half.
I never worked at Twitter, but based on the timeline it seems very likely they were running on the old Ruby 1.8.x line, which was a pure AST interpreter. The VM is now a bytecode interpreter that has been optimized over the intervening years. The GC is considerably more robust. There's a very fast JIT compiler included. Many libraries have been optimized and bugs squashed.
If your concern is Rails, please note that also has seen ongoing development and is more performant, more robust, and I'd say better architected. I'm not even sure it was thread-safe when Twitter was running on it.
You don't have to like Ruby or Rails, but you're really working off old data. I'm sure there's a breaking point in there somewhere, but I very much doubt most apps will hit in before going bust.
The CRuby VM, or the CRuby interpreter alone is at least 2-3x faster since Fail Whale time. And JIT doubles that to 4 - 6x. Rails itself also gotten 1.5x to 2x faster.
And then you have CPU that is 20 - 30x faster compared to 2009. SSD that is 100x - 1000x faster, Database that is much more battle tested and far easier to scale.
Sometimes I wonder, may be we could remake twitter with Rails again to see how well it goes.
My issue with Ruby (and Rails) has always been the "ball of mud" problem that I feel originates from its extensive use of syntactical sugar and automagic.
Rails can become a ball of mud as much as any other framework can.
It's not the fastest language, but it's faster than a lot of dynamic languages. Other than the lack of native types, you can manage pretty large rails apps easily. Chime, Stripe, and Shopify all use RoR and they all have very complex, high-scale financial systems.
The strength of your tool is limited to the person who uses the tool.
Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.
I haven’t seen a direct comparisons but I wouldn’t be surprised if Truffle Ruby was already faster than either elixir, erlang or php for single threaded CPU bound tasks too.
Of course that’s still way behind other languages but it’s still surprisingly good.
In my work I’ve seen that TruffleRuby codebases merging Ruby and Java libraries can easily keep pace with Go in terms of requests per second. Of course, the JVM uses more memory to do it. I mostly write Go code these days but Ruby is not necessarily slow. And it’s delightful to code in.
> Python? Ruby with YJIT, JRuby or Truffle Ruby usually beats python code in benchmarks.
Isn't that moving the goal post a lot?
We wen't from 'faster than a lot of others' to 'competing for worst in class'.
I'm not trying to be facetious, I'm curious as I often read "X is really fast" where X is a functional/OOP language that nearly always ends up being some combination of slow and with huge memory overhead. Even then, most Schemes (or Lisps in general) are faster.
Being faster single threaded against runtimes that are built specifically for multithreaded, distributed workloads is also perhaps not a fair comparison, esp. when both runtimes are heavily used to write webservers. And again, Erlang (et al) come out faster even in those benchmarks.
Is TruffleRuby production (eg. Rails) ready? If so, is it that much faster?
I remember when the infamous "Truffle beats all Ruby implementations"-article came out that a lot of Rubyists were shooting it down, however this was several years ago by now.
Moving the goal posts? Perhaps I misunderstand what you are asking.
Python is the not the worst in class scripting language. For example perl and TCL are both slower than python.
Originally you just asked, "such as" [which dynamic language ruby is faster than?]
Implying ruby is slower than every other dynamic language, which is not the case.
JRuby is faster than MRI Ruby for some Rails workloads and very much production ready.
Truffle Ruby is said to be about 97% compatible with MRI on the rubyspec but IMHO isn't production ready for Rails yet. It does work well enough for many stand alone non-rails tasks though and could potentially be used for running Sidekiq jobs.
The reason to mention the alternative ruby runtimes is to show that there's nothing about the language that means it can't improve in performance (within limits).
Whilst it's true that ruby is slower than Common Lisp or Scheme, ruby is still improving and the gap is going to greatly reduce, which is good news for those of us that enjoy using it.
Thank you for a great answer; I did not mean any ill will and apologize if that was how it came across.
Perl, Tcl, Smalltalk etc are basically non-existant from where I'm from, so they didn't occur to me.
Perhaps I'm projecting a lot here. I have worked a lot in high performance systems and am often triggered by claims of performance, eg. 'X is faster than C' when this is 99.9% of the times false by two orders of magnitude. This didn't happen here.
Java's Hotspot was originally designed for Smalltalk, and SELF.
Two very dynamic systems, designed for being a complete graphical workstation, Perl, Tcl, Python, Ruby were as originially implemented, not even close of the original Smalltalk JIT paper from Peter Deutsch's paper"Efficient Implementation of the Smalltalk-80 System." in 1984!
the ruby is faster than c is because of the yjit. they are moving a lot of c ruby standard library and core language stuff into ruby code so the yjit can optimize it better. akin to java and their bytecode being able to optimize things on the fly instead of just once at compile time.
No one uses Ruby because it is fast. They use it because it is an ergonomic language with a battle-tested package for every webserver based activity you can code up.
Crystal is an ergonomic language, too, looking a lot like Ruby even beyond a cursory glance. What Ruby has, like any longstanding language, is a large number of packages to help development along, so languages like Crystal have to do a lot of catching up. Looking at the large number of abandoned gems though, I'm not sure it's that big a difference, the most important ones could be targeted.
I'm not sure that has any relevance when compared with Python or JS or Go though, they seem to have thriving ecosystems too - is Rails really that much better than the alternatives? I wouldn't know but I highly doubt it.
> is Rails really that much better than the alternatives?
I really think so. I've _looked_. I've tried all sorts of other web frameworks. And, admittedly, I am most familiar with Rails, so I'm maybe a bit biased. But it's hard to find anything that comes particularly close to the productivity of using Rails. The tooling's great, the ecosystem is great, it's organized well, the documentation is good. It's just... really a pleasant experience to use.
Elixir's Phoenix comes pretty close, as does PHP's Laravel, imo. Special shout out for Rust's Loco, too, which is relatively new, but looking potentially promising.
I recommend giving Rails an open-minded tire kicking. I think you'll be surprised by how quickly you can get going.
I've used Rails (I've possibly committed to it, though I've forgotten if I have), my point is that I don't know those other languages' frameworks well enough to judge the difference, but I don't see any complaints.
You even seem to admit as much while being most familiar with Rails. Do you know anyone who'd love to switch over? Or would you choose it ahead of a competitor if you were green? There'd have to be a large competitive advantage.
I’d jump ship if there was a mature, stable competitor in the Typescript ecosystem.
Unfortunately I think language differences mean it’s going to be a long time before anyone catches up. Ruby just makes for some really interesting wizardry that as far as I can tell isn’t possible (or perhaps not as ergonomic?) in Typescript.
Furthermore there seems to be a cultural difference. I haven’t met many JS devs who came to the Ruby side and were like, “Aw shit this is better.” (I’m one such dev, but I hated Ruby and Rails for a really long time before I changed my opinion and embraced it.)
But at this point in my career I value stable boring technology way more than my personal taste du-jour so I code in Ruby and really love Rails.
I am still hoping once Crystal stabilise on Windows ( Currently it still feels very much beta ). They could work on making compiling speed faster and incremental compiling.
Unfortunately it is, because too many folks still reach out to pure interpreted languages for full blown applications, instead of plain OS and application scripting tasks.
Sure, but I wouldn’t expect deepseek to either. And if any model did, I’d damn sure not bet my life on it not hallucinating. Either way, that’s not heresy.
