Hacker Newsnew | past | comments | ask | show | jobs | submit | jeroenvlek's commentslogin

Exactly.


I've been using Hyprland now for 4 months and it's my first tiling WM experience. I absolutely love it and actually donated 10 euro to the dev(s?).

Having said that: This is simply not mature enough yet to warrant a 60 euro a year subscription, regardless of premium features.

To be clear, I do see the potential and I would actually pay it but this is too early.


Hasn't Hyprland been in the works for years? Maybe try Niri or sway. Sway is rock solid IME.


Apologies, I should have been more specific. "Mature" was a reference to its feature set, not its stability. It runs fine in my setup. I meant things like automatic resolution and scale switching, for example, without having to edit my config file Indeed, I can script that myself, I will. My point is more that if that's the kind of thing I need to do myself, then I'm not paying 60 euro a year.


Am I interpreting this correctly to say that if you travel through the universe (at relativistic speeds?) and you arive at your destination, then you are reset to be the same person as when you started the journey?


> Am I interpreting this correctly to say that if you travel through the universe (at relativistic speeds?) and you arive at your destination, then you are reset to be the same person as when you started the journey?

If you manage to arrive at the same place and time that you started from (i.e. because you time-travelled, e.g. by going through a wormhole), then you are necessarily the same person when you arrive as you were when you departed.

It's kind of a cool result. The laws of physics conspire to keep the universe consistent even in the presence of time travel.


Well in the model of General Relativity. Laws of physics are human descriptions of how we think nature operates based on current observations. It's not like we have a wormhole available to test time travel, assuming wormholes actually exist in nature. We don't really know if nature "conspires" to keep things consistent like that. Physicists do have a desire to come up with consistent theories though.


> It's kind of a cool result. The laws of physics conspire to keep the universe consistent even in the presence of time travel.

Indeed. I find this very cool and this paper gives some interesting examples of how this might unfold including Einstein clocks and the grandfather paradoxon.


It might make more sense of you think of spacetime as literally one thing, with one constant value. That value being c (or some meta value that boils down to the same thing).

Energy in all its forms (including velocity), mass, etc. or the lack thereof being ‘space’, and time being what you have ‘left over’ when you subtract ‘space’.

The more mass, or velocity, etc. you have, the less ‘time’ you get left over. That is time dilation, both in the presence of masses and when you’ve got a lot of velocity (because having a lot of velocity means you have a lot of energy).

That is an alternative formulation of e=mc^2. [https://en.m.wikipedia.org/wiki/Mass%E2%80%93energy_equivale...].

At the point your velocity hits c (somehow), you have no ‘time’ left over from your perspective, so wherever you go, you go there instantly from your perspective. No time has passed for you. Same if you are ‘inside’ a singularity like a black hole.

Space time curvature (aka gravity) may arise from that effect not just being a point one, but a subtle cumulative area effect.

In that model, time travel, FTL, and any other lack of causality (aka effect after cause) make no sense, because there is no ‘lever’ for such a thing to ever happen.

Maybe if someone could invent negative mass/energy (we currently have no evidence/idea such a thing could exist!), or a way to manipulate the fundamental factors that make spacetime spacetime. We have no concrete idea how to even conceive of trying such a thing idea right now though.

That result is terrifyingly boring in its implications though, which is why we try to avoid it.


> That result is terrifyingly boring in its implications though, which is why we try to avoid it.

What result? A result that the entire Universe is deterministic and already determined, like a movie already recorded to tape that we are somehow watching play from inside?


That could be one.

But I was referring to the possibility that it’s energetically impractical to ever get out of the solar system (or even travel within our solar system) in a way that any human is likely to ever want to do it. (Aka no FTL, or even near light speed)

And this likely applies to anything we’d call ‘life’ too.

And that time is actually one way, so no do overs, and no time travel. (Either because of the 2nd law of thermodynamics, or the 2nd law is an effect of this!)

If we accepted that, it would kill what - 95% of all Sci-fi ever?


A closed timelike curve is the name in General Relativity for a time machine: you go forward in time and wind up in your past, and you go around and around the loop forever.

The point is that when you get to the same point in the loop your state must be what it was the last time you were at that point in the loop.

If you have a relativistic trajectory that doesn't form a loop in time there's no reset effect.


Wouldn't the fact that entropy must increase mean that you can never get to the exact same state as you were before?

Consider that Heisenberg's uncertainty theorem states that we cannot know precisely the position and velocity of a particle at the same time, not even in theory. Thus, they don't have precise values even in theory. Then how could you ever return back to the precisely same state which never had a precise value to begin with?


> Wouldn't the fact that entropy must increase mean that you can never get to the exact same state as you were before?

What you're running into is the observation that near closed timelike curves quantum mechanics inevitably becomes important.

> Consider that Heisenberg's uncertainty theorem states that we cannot know precisely the position and velocity of a particle at the same time, not even in theory. Thus, they don't have precise values even in theory.

This is a popular-level understanding of QM. The first sentence is true because it includes the all important 'at the same time'. The second is... trickier.

Position and momentum are observables, not state variables (unlike classical mechanics). They are incompatible so they suffer from Heisenberg uncertainty. But that doesn't mean a state can't have a definite position or momentum.

You can construct a wavefunction with a definite position. By Heinsenberg uncertainty, if you try to measure its momentum you can get any value. Likewise you can construct a wf with a definite momentum but if you measure its position you can get any value.

Nevertheless the system has a definite wf. For these two different wfs it is perfectly fair to say the first has a definite position and the second a definite momentum.

> Then how could you ever return back to the precisely same state which never had a precise value to begin with?

If the system goes around a CTC and returns to the same wavefunction it's the same. Quantum mechanical systems have definite states. But weirdly in QM position + momentum are not state variables.


Thanks for the great explanation. Quantum weirdness is weird.


Ex falso quodlibet - "from falsehood, anything follows". If you start with a false assumption, you can logically derive any statement from it, even if that statement is absurd.


"A" universe, but not "the" (i.e. our) universe.

Specifically: https://en.wikipedia.org/wiki/Gödel_metric

It's specifically a universe where time travel definitely happens.


From the paper:

> Finally, we stress again that our main results are valid in an arbitrary background spacetime (including charged Kerr black holes [51, section 12.3]), provided that the CTC of interest is the orbit of a periodic one-parameter family of symmetries of the metric. This happens in all axisymmetric models whose rotation Killing field becomes timelike somewhere.


Thanks, that's what I get for skim-reading :)


I think it's more like: "Quantum mechanics is consistent with what we expect to happen with matter that exists in a closed timelike curve: everything is reset upon return to the starting spacetime point."


In the average organization, if you're not talking to other departments then, almost by definition, you're also not doing DDD.


It's not almost it is exactly the definition. The key thing about DDD is ubiquitous language, which is everyone using the same language. And learning things from the domain experts who are in other departments. If you're not talking to other departments you can't be using the same language as them. Nor can you learn from the domain experts. Nor even ensure that the domain flow maps the same as the company. DDD and BDD are fundamentally about talking to people. But that's the hard part so people skip it.



Ultimately even conventional 3d assets are rendered into pixelspace. It all comes down to the constraints in the model itself.


A key strength of conventional 3d assets is that their form is independent of the scenes in which they will be rendered. Models that work purely in pixel space avoid the constraints imposed by representing assets in a fixed format, but they have to do substantial extra work to even approximate the consistency and recomposability of conventional 3d assets. It's unclear whether current approaches to building and training purely pixel-based models will be able to achieve a practically useful balance between their greater flexibility and higher costs. World Labs, for example, seems to be betting that an intermediate point of generating worlds in a flexible but structured format (NERFs, gauss splats, etc) may produce practical value more quickly than going straight for full freedom and working in pixel space.


Very cool! Like others here I've done something similar about a decade ago [0], but only with inheritance and mutation. This was C++ and Qt.

[0] https://github.com/jeroenvlek/evopic


As a freelancer myself I go one step further and actually charge hourly rates. This granularity helps both with short workshops and fulltime projects because with the latter I'm often asked to work overtime or I have personal errands to run. Charging by the hour smooths this quite a lot.


I went the other way (hourly -> daily) and found it much more enjoyable. I have multiple clients and it's clearer for everyone what days I'm available for them. Otherwise I might juggle between "urgent" work for two clients and have a call for a third, which is suboptimal. Now, I'm considering adding back some hourly rates for calls outside my working days and for overtime work, to align incentives of all parties.

Rates and what you charge is a major interface with clients so it's worth taking the time to come up with a structure that suits you (first).


> I went the other way (hourly -> daily) and found it much more enjoyable.

Doesn't work too well with maintenance on existing products; clients really would rather not pay for the hours between a PR being submitted and the PR being merged. Toss in a good dose of 'waiting for your tech lead to answer these questions', 'waiting for feedback on this proposed document', 'waiting for infra to give me access', etc, and many clients completely balk at daily rates[1].

For complete products daily billing works nicely.

[1] This is because they know that a turn-around time for granting access to their labyrinthine infra for all the machines that might be needed is going to take more than a day.


For me hourly rates work best too. I charge only for real work, not for breaks, because really working an 8h day is unrealistic for me.


As someone transitioning into contracting (Senior dev), do you have any advice?

Was thinking of hitting up recruiters with my rates.


I think hourly attracts cheaper clients that will want you to be extremely exact in your timesheets.

Day rate clients often don't necessarily care what you do with the time as long as your deliverables are being met – but it still helps them to pay on a time-basis as it's an easier model and more predictable


I've found hourly with an initial up front minimum works well.


Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless.

It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?

I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.


I used to think that it was more likely that Rust would "expand upward" to provide the higher level syntax that people want in a language like I describe above, but it does seem like the language development has vastly slowed down in terms of big new features. I don't necessarily think this is a bad thing; plenty of people didn't like how much churn there was in the first several years after Rust 1.0 came out. I personally didn't mind since I never ran into any significant breakage in what I worked on, but I definitely noticed a change in how open companies seemed to be to use Rust in any capacity coinciding with Rust's releases growing smaller on average; I think "frequency of major language features" is often used as a proxy for "language maturity".

At this point, I think a new language is more likely to provide this niche than Rust, and I also don't think that has to be a bad thing. Having Rust scoped more to lower-level programming where you're more worried about things like minimizing heap usage and avoiding copying strings or whatever rather than trying to be all things to all users might end up with a better experience in the long run.


Lol, and there are the downvotes


Amazing list and despite having read sci-fi almost exclusively for the past 5 years, luckily there's still so much more to read!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: