> The explicit safety target that FAA and other regulators have settled on is that catastrophic events should be “extremely improbable,” meaning one per billion flight-hours. The regulation of this kind of aviation is nothing short of maniacal.
He is, airlines have been complaining about the paperwork involving anything that flies for decades - however given incidents like [1] with fake parts being spliced into legitimate supply chain, or how that paperwork enables accident investigation boards to quickly determine root causes often in a matter of weeks to months, the regulations do have merit.
On the other hand, you got a ton of Global South countries, particularly in Africa, with very lax enforcement of any kind of standards, and they don't end up with hundreds-of-pax-dead catastrophes every year, so either the regulations could be relaxed legitimately across the board or the lack of catastrophes is mostly because almost all planes flying out there are Western-built with considerable amounts of safety margins, redundancies and fail-safes built-in.
Some companies in a regulated industry want less regulation. Big surprise.
But no, less regulation is not what we need in aviation, cars, food or medcine. Those regulations have litteraly been written in blood.
And guess how many of those lax airlines are allowed to land in e.g. the EU. Not that many, and those airlines from those regions that are allowed in European airpsace are adhering to EASA requirements, and thus are the opposite of lax.
No matter how you design an aircraft, and safety margins there are lower than for e.g. cars, with bad and lacking maintennace it becomes a safety hazard rather quickly.
I don't disagree with your overall point, but I think it's important to keep in mind that these companies often want more regulation— especially regulation that they're already compliant with. Of course EASA compliant airlines don't want to open things up to airlines that can operate more cheaply. Whether or not that's solely a consideration of safety is less clear.
Age 67 is another example where unions do not want more competition. I imagine a hypothetical relaxation of CPL regs would be similarly opposed by airlines and unions alike as they certainly wouldn't welcome the resultant competition. Desire for regulation can have many motivations.
That's the big issue. This is going to hurt smaller developers more because they can't afford to fight it.
The big question is: to what extent to Unity games need to be able to talk to Unity's servers? If they're looking at number of installs (and apparently that includes pirated copies even?), serve ads, and probably provide other services, that sounds like the games need a connection to the server. In which case they may be able to disable your game if you don't pay. And then even if you could sue them, the real damage is already done.
If you'd amended the source, then it wouldn't be the same version and the license would be invalid. If you want to use the perpetual license, you can't do anything with the source.
> Epic grants you a non-exclusive, non-transferable, non-sublicensable license to privately use, reproduce, display, perform, and modify the Licensed Technology in accordance with the terms of this Agreement (the “License”). This means that as long as you are not violating this Agreement or applicable law, you can privately use the Licensed Technology however you want. If you want to share the Licensed Technology or anything you make with it, Sections 3 and 4 below address when and how you can do that.
In section 3/4 it goes to that you can compile your game and give the output to outsiders if you pay the roylaties when applicable or share them royalty free on epics github (basically you make a pr to merge your stuff upstream) or on unreal marketplace (sell it)
I'm not intending to be defensive (I'm sure there's loads of people on here with more knowledge about licensing terms), but usually a corrective post is something that we can learn from. Just saying something is wrong with no more info seems against the spirit of HN.
If you understood the problem then you’d know that their argument is about how Unity’s new pricing change is retroactive, affecting all Unity versions and charging fees to devs for games made years ago.
Unreal uses perpetual licenses for their versions meaning this kind of bullshit behavior is not possible
Perhaps it is you who doesn't understand. We all get that part, and it makes sense in isolation. Yes, that is better.
Then it's goofy af to say Godot might make a license change that necessitates using one version in perpetuity-except a version you and others are allowed to modify and distribute.
> Epic is not doing this out of the goodness of their heart, they're doing it because it is beneficial to them. Epic is a multi-billion dollar corporation part owned by a massive conglomerate.
Holy straw man! And there’s certainly no self-interest involved with me using their engine without giving them a cut under 1 mill right?
You can make this argument about literally anything.
Godot must have no self-interest in releasing their engine for free and making $30k a month to develop their project.
Who cares what the motivation is if it gives real benefits to devs. If anything it tells me they’ve picked a business model that’s mutually beneficial unlike Unity
While you can make this argument about literally anything, it seems apt to make it about a multi-billion dollar company chasing a trillion dollar company.
It's fine to support them while they are the underdog and are saying and doing the right thing, but don't pretend like they will say and do the right thing forever.
I don't think the parent was ever saying they'll be good forever. More that if they do become evil, their licensing lets you continue using a revenue structure that made sense at the time you chose it (even if new versions have super awful terms).
> Who cares what the motivation is if it gives real benefits to devs.
Motivations matter, because they will decide in which direction a project moves over time, or if situations change. Epic is the "good guy" now, but only because they are an underdog. If they become the dominator, they might become the predator which Unity tries to be at the moment.
But if we are honest, such uncertain possibilities don't matter if they are so far in the future. This might be a problem for future games, 10, 20 years down the river..
I’ve been trying to use emacs and vim/nvim on and off for a several years now but it always seems like a task in vain. Half of it works and it’s a real pain to get something usable.
I wish I could use Linux but I work in the gaming industry ina company that solely creates windows games so it’s not really an option…
I've had good results with wsl2. The only thing that frustrates me is magit performance on a big project with literally twenty years of commits. (It was originally an SVN repo.)
It became one of those hate memes. A target of irrational fervor among anyone caught in between. If you ask those angered they pull out a list of petty grievances a mile long composed of misleading or highly interpretive wrongs.
I haven’t had the pleasure to try out V yet but I hope this discussion can rise above. Endless bickering leaves a sour taste in my mouth.
> If you ask those angered they pull out a list of petty grievances a mile long composed of misleading or highly interpretive wrongs.
How can you assert that they're misleading or highly interpretive wrongs if you haven't dug into them yourself and actually used V? All the negative press I've seen on V has been highly detailed and reproducible.
You don’t need to have touch it to see. Just browse this thread. A big one mentioned is over promising, which is pretty interpretive for a language only on version 0.4 of its development cycle. Most other complaints are slight variations of this. Promising magic performance or magic features without a good explanation, is another variation. This would be well and good for a fully released language, which this is not. All that tells me is the creator is overly ambitious for their own good and possibly naive, which I hardly classify as a sin.
Whenever this topic comes up I’m at a loss to understand why anyone would waste so much energy mud slinging over some personal language project. It only makes sense if it’s become a hate meme. My pocket word for an event that’s a sort of social singularity. It occurs when enough popular voices have directed the entirety of a community to shame a target based on some perceived wrong, real or otherwise.
Wherever it comes up I’m pretty taken aback by how tribal and ego focused we can be, even among the smartest of us. And that thought isn’t meant be taken as condescending. After all, we’re only human. And for a larger span of human history, that word has meant “hairless ape” more than anything else.
They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible, and their implementation was missing lot of properties they were advertising. If you would look at their sources or try out V when they released it you would have seen how outrageous their claims were.
Last time I looked was beginning of 2022, and I read their stdlib implementation and tried the compiler. They advertised their non-GC solution, “auto free”, but it literally didn’t work, your program would just leak. And if you actually look at what they meant by “autofree”, it is a reference counting GC. They advertised Rust memory management ergonomics but without relying on linear types? Their way to do system calls was by running commands in shells.
Unless things changed drastically V lang, as described by their documentation, is a vapor ware.
I'm still waiting for that CS breakthrough to happen - Rust guys will be so mad they spent their time writing lifetime annotations for the borrow checker :)
You can look up vlang.io on web archive and see that it never said GC-less autofree. It actually explicitly said that RC/GC are used for stuff that can't be freed during compile time.
> No. V's memory management is similar to Rust but much easier to use. More information about it will be posted in the near future.
May 2019
> No. V manages memory at compilation time (like Rust). Right now only basic cases are handled. For others, manual memory management is required for now. The right approach to solve this will be figured out in the near future.
April 2020
> No. V manages memory at compilation, like Rust:
vlang.io/docs#memory
August 2023
> You can look up vlang.io on web archive and see that it never said GC-less autofree
Here's a direct quote from the documentation [0] from 2021:
> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
So most objects are freed by the autofree engine, and the rest are freed via reference counting. This implies that no objects are freed by the GC, which is exactly what I've said.
> What's written is correct, what's the issue again?
The fact that the feature promised is impossible. I'm quoting some comments from which this whole discussion has started, since you don't seem to be able to follow:
> dgellow: They got lot of push back because what the core devs were describing Vlang to be was technically close to impossible
> amedvedikov: There were no close to impossible/missing features.
Static analysis (autofree) with reference counting, by itself, cannot theoretically free all of the objects during the runtime of the program. And I know that you know that since you've made the decision to switch to a tracing garbage collector.
The choice of tracing garbage collection makes the initial claim much less impressive and innovative - Go already has escape analysis, which is basically an implementation of autofree. But Go used a garbage collection from the start, so escape analysis is just an optimization - exactly what autofree is for the current V with GC.
V promised something impossible, it's not a big deal, we all make technical mistakes and learn from them. What makes it a big deal is your stubborn attempts to rewrite history and gaslight people.
> It can't, that's what it says on the home page. Stuff that can't be freed during compile time is handled via GC.
The documentation I've quoted and posted a source to specifically says that all objects are freed either by 1) autofree or 2) reference counting.
> What's the impossible claim?
The impossible claim is that all objects are freed either by 1) autofree or 2) reference counting. As I've mentioned, neither static analysis (which is what autofree is) nor reference counting is capable of completely freeing all unreachable objects at runtime - reference counting is in particular unable to handle cyclic references.
> What's the issue again?
The issue is you vehemently claiming that V has never, ever promised a feature that was impossible - which is false, as I've demonstrated and cited with reference to archive.org of V lang documentation. So can you stop doing that, please?
> You pointed to an old version of the documentation
Yes, because that version of documentation specified a feature that was impossible, which is exactly what we're discussing.
> V never promised autofree without GC or RC
First of all, I never mentioned "autofree without RC". I am strictly speaking about "autofree without GC".
Second of all, V documentation has had the "autofree frees 90% of objects, RC frees everything else" segment, which clearly implies no GC. So the documentation has clearly specified that feature, which was an impossible feature.
Even the next paragraph says:
The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
Which explicitly implies that objects are exclusively freed only by autofree and reference counting.
2) Your emphasis of "everything" seems to imply a contrast to Python or Go method of memory deallocation:
"It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything
which would mean that Python, Go and Java trace everything, which isn't true. None of the three languages (Python, Go, or Java) use GC to trace everything - there are multiple optimizations (such as escape analysis and reference counting) that allow a certain percentage of objects to be freed by means other than tracing GC.
V is not a finished product nor 1.0 yet. It's unproductive to act like things were carved in stone, from day 1. Programming languages go through development phases, where things do change and lead developers are allowed to make changes.
But gaslighting people and pretending that overly grandiose claims/promises haven't been made in the past leaves a bitter taste, and doesn't inspire trust in core developers. Instead, it makes me think that the core devs are incapable of admitting a mistake - which would make their language a hazard.
For example, what if V gets huge and a serious security bug gets discovered - how can I trust that the developers will properly communicate the existence of such a bug and not just keep quiet about it, consider how they aren't even willing to admit that V has made some impossible claims/promises in the past? If I discover a bug, will they also pretend that the bug doesn't exist, even when confronted with indisputable evidence, because it threatens to damage their reputation?
As long as that attitude doesn't change, I'm not touching V with a 10 foot pole.
You're still pretending that V has never made an impossible claim, which I have clearly demonstrated that it has.
See my numerous replies to you in this thread, where I have quoted the documentation, provided the archive.org link and explained why the claim is impossible.
Do you have any other argument except "nuh-uh, didn't happen, lol"?
The homepage still makes the claim that "[autofree] takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation."
There is no citation for where this 90-100% number comes from, it seems to be pulled completely out of thin air.
Autofree, as it currently exists, cannot handle structs at all, so any program whose memory allocations consist of more than 10% structs unfortunately proves this claim false.
For a specific example, a while ago I wrote a minimax tictactoe program[1] in V, which specifically used a struct to store the board state rather than an array.
In this case, with the minimax running for 4 total moves, valgrind tells me:
==8518== HEAP SUMMARY:
==8518== in use at exit: 2,250,360 bytes in 68,544 blocks
==8518== total heap usage: 161,756 allocs, 93,212 frees, 4,762,235 bytes allocated
So only 93212/161756 allocations were freed, which is 57%.
... Now, I don't actually care that much that autofree doesn't work on structs. I think that's quite reasonable, as it's a very difficult thing to implement!
But, in my opinion, your website should really cite where this 90-100% number comes from, i.e. which benchmarks were used to generate it, so that it is clear that it isn't just completely made up.
(As it currently stands, I would argue this is false advertising specifically because there's no citation for this number!)
Why isn't there a citation for this 90-100% number? I really am extremely curious where it comes from.
As for why I am posting a similar message (not nearly the same post, though) to you here as I did a year ago:
It is because I am very, very curious about where this number comes from and why there is no citation for it! It is fascinating to me.
(And, more generally, I have empirical experience with autofree that many users don't seem to have... so it seems useful to post about that experience to provide extra context for everyone else on this website).
I find carbon and the development of a modern replacement for C++ intriguing to watch. But for the life of me I can’t understand why someone would want this over a more mature language like D
The problem with D is changing direction every couple of years regarding the next big feature that will finally bring the masses into the language, while not quite finishing the last big feature that predated it.
Even Andrei Alexandrescu is back doing C++ at NVidia.
I also don't know if the code I write in D today will compile 20 years from now. A few months ago there was a discussion on the D forums which spilled over here about constant churn due to breaking changes in the language.
I think Google is exploring other options as well, such as Rust. Carbon is a more aggressive experiment with higher risks. They've been very clear about Carbon's experimental status and that users should consider using Rust or something else instead of Carbon if they can use the one right now.
This is something I’ve been thinking about for some time, a new type of programming that uses an ai model for parsing. It’s a interesting thought that can lead down many rabbit holes. You could have AI interpret a lot of expressiveness into a language while having an optimizing AI turn whatever crazy thing we come up with into fast code.
For any prospective language designers out there. Please don’t make human based language programming a thing again. That’s an idea that should stay in the waste bin. A language that describes programs shouldn’t be ambiguous. I also wouldn’t trust any AI—no matter how smart—to create code I’d be happy with, unless I could go into very specific detail.
No limits on structure serialization though. Make that a one liner please
Maniacal really? Is the author living in reality?