Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

701–710 of 799 posts

Re: Migrating away from Rust

#701

Post by spookie »

fc417fc802 wrote: post #532
spookie wrote: post #497

Earlier quoted context omitted.

You can manipulate texture coordinate derivatives in order to just sample a subset of the whole texture on a pixel shader and only shade those pixels (basically the same as mipmapping, but you can have the "window" wherever you want really). This is something you can't do on a compute shader, given you don't have access to the built-in derivative methods (building your own won't be cheaper either). Still, if you want…

That is true. Hadn't occurred to me because I'd had in mind pixel sorting stuff I did in the past where the fetches and stores aren't contiguous. Interestingly enough the derivative functions are available to compute shaders as of SM 6.6. [0] Oddly SPIR-V only makes the associated opcodes [1] available to the fragment execution model for some reason. I'm not sure how something like DXVK handles that. I'm not clear if…

Huh wasn't aware of that. Nice.

About the performance question, during the frag shader phase neighbouring pixels are already being tracked, so calling those is almost free. It would be difficult to match that performance when already on the compute phase.

Re: Migrating away from Rust

#702

Post by variadix »

akoboldfrying wrote: post #513
josephg wrote: post #430

Earlier quoted context omitted.

> It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide. I've gone back and forth on this, myself. I wrote a custom b-tree implementation in rust for a project I've been working on. I use my own implementation because I need it to be an order-statistic tree, and I need internal run length encoding. The original vers…

> Recently I rewrote the b-tree to simply use a vec of internal nodes Doesn't this also require you to correctly and efficiently implement (equivalents of C's) malloc() and free()? IIUC your requirements are more constrained, in that malloc() will only ever be called with a single block size, meaning you could just maintain a stack of free indices -- though if tree nodes are comparable in size to integers this increa…

Depends on if you need to allocate/deallocate nodes. If you construct the tree once and don’t modify it thereafter you don’t need to. If you do need to modify and alloc/dealloc nodes you can use a bitmap to track free/occupied slots which is very fast (find first set + bitmanip) and has minuscule overhead even for integer sized elements.

Re: Migrating away from Rust

#703

Post by vips7L »

cies wrote: post #650
vips7L wrote: post #581

Earlier quoted context omitted.

Yes via sealed classes. It also has pattern matching.

So they are there, but ugly to define: public abstract sealed class Vehicle permits Car, Truck { public Vehicle() {} } public final class Truck extends Vehicle implements Service { public final int loadCapacity; public Truck(int loadCapacity) { this.loadCapacity = loadCapacity; } } public non-sealed class Car extends Vehicle implements Service { public final int numberOfSeats; public final String brandName; public Ca…

You implemented this much more verbosely than needed

    sealed interface Vehicle {
        record Truck(int loadCapacity) implements Vehicle {}
        record Car(int numberOfSeats, String brandName) implements Vehicle {}
    }

Re: Migrating away from Rust

#704

Post by tptacek »

mwcampbell wrote: post #506
tptacek wrote: post #440

Earlier quoted context omitted.

No plausible advance in nanotechnology could produce a violin small enough to capture how badly I feel about out professional being "plagiarized" after decades of rationalizing about the importance of Star Wars to the culture justifying movie piracy. Artists can come at me with this concern all they want, and I feel bad for them. No software developer can. I disagree with you about the "plagiaristic" aspect of LLM co…

I'm not making an argument from grievance about my own code being plagiarized. I actually don't care if my own code is used without even the attribution required by the permissive licenses it's released under; I just want it to be used. I do also write proprietary code, but that's not in the training datasets, as far as I know. But the training datasets do include code under a variety of open-source licenses, both pe…

I don't mean to attribute the overwhelmingly common sentiment about intellectual property claims for things other than code to you, and I'm sorry that I communicated that (you didn't call me on it, but you'd have had every right to).

I stand by that argument, but acknowledge it isn't relevant here.

My bigger thing is just, having the experience of writing many thousands of lines of backend code with an LLM (just yesterday), none of what I'm looking at can meaningfully be described as "plagiarized". It's specific to my problem domain (indeed, to my extremely custom stack) and what isn't domain-specific is just extremely generic stuff (opening a boltdb, printing a table with lipgloss), just assembled precisely.

Re: Migrating away from Rust

#705

Post by smittywerben »

pjmlp wrote: post #599
smittywerben wrote: post #83

Earlier quoted context omitted.

C# has aged better but I feel like Java 8 approaching ANSI C level solid tools. If only Swing wasn't so ugly. They should poach Raymond Chen to make Java 8 Remastered I like his blog posts. There's probably a DOS joke in there. Also they should just use the JavaFX namespace so I don't have to change my code and I want the lawyer here to laugh too.

Java current version is 24.

[gong sound]

The Master said, “I consider my not being present at the sacrifice, as if I did not sacrifice.”

The Analects (Confucius, 551-479 BCE), translated by James Legge (1815-1897)

Re: Migrating away from Rust

#706

Post by Groxx »

bmitc wrote: post #213
klabb3 wrote: post #204

The fact that people love the language is an unexpected downside. In my experience the rust ecosystem has an insanely high churn rate. Crates are often abandoned seemingly for no reason, often before even hitting 1.0. My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game. Once all the fun parts are solved, they leave it for dead. Conversely and…

I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.

To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields.

They've effectively dropped it a couple times in the past, and while they're currently putting effort in, the company as a whole does not seem to care about stuff like this beyond brief bursts of attention to try to win back developer mindshare, before going back to abandonment. It's what Microsoft is rather well known for.

Re: Migrating away from Rust

#707

Post by bunderbunder »

imtringued wrote: post #679
bunderbunder wrote: post #148

Earlier quoted context omitted.

I worked in a regulated space at one time, and my understanding is that this is a big reason they chose .NET over Java. Java relies a lot more on third-party libraries, which makes getting things certified harder. Log4shell was a good example of a relative strength of .NET in this area. If a comparable bug had happened in .NET's standard logging tooling, we likely would have seen all of the first-party .NET framework…

None of this makes any sense. There is no waiting. You just do it. In no universe can you justify using a vulnerable log4j version. You force gradle to use the patched log4j and be done with it. Five years has nothing to do with Java. It means nobody cares about security in the first place. Outsourcing such a trivial security problem to Microsoft is just another nail in the coffin. "I have no capacity to develop secu…

I'm not saying that making an exception is the correct course of action. But it isn't my call to make so it kind of doesn't matter what I think in this case.

What I'm trying to point out is that I've never known this kind of security vulnerability to be quite such a hassle to eradicate when working on the .NET stack. Because the "batteries included" nature of .NET just makes it easier. On Java the supply chain tends to be more unwieldy. Which seems to engender both increased maintenance hassle and a greater tendency toward normalization of deviance. Perhaps as a way to try to sand the sharp corners off of the maintenance hassle.

Re: Migrating away from Rust

#708

Post by Ygg2 »

chubot wrote: post #563
WalterBright wrote: post #470

Earlier quoted context omitted.

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

So in D, is it now natural to mix borrow checking and garbage collection? I think some kind of "gradual memory management" is the holy grail, but like gradual typing, there are technical problems The issue is the boundary between the 2 styles/idioms -- e.g. between typed code and untyped code, you have either expensive runtime checks, or you have unsoundness --- So I wonder if these styles of D are more like separate…

> "gradual memory management" is the holy grail

I don't think gradual types are as holy grail as you make them out to be. In gradual typing, if I recall correctly, there was a large overhead when communicating between typed and untyped parts. But further

But lets say gradual memory management is perfect, you have to keep in mind the costs of having GC + borrow checking.

First thing, rather than focusing on perfecting GC or borrow checking, you divert your focus.

Second, you introduce an ecosystem split, with some libraries supporting GC and others supporting non-GC. E.g. you make games in C# and you want to be careful about avoiding GC, good luck finding fast enough non-GC libraries.

Re: Migrating away from Rust

#709

Post by fc417fc802 »

spookie wrote: post #701
fc417fc802 wrote: post #532

Earlier quoted context omitted.

That is true. Hadn't occurred to me because I'd had in mind pixel sorting stuff I did in the past where the fetches and stores aren't contiguous. Interestingly enough the derivative functions are available to compute shaders as of SM 6.6. [0] Oddly SPIR-V only makes the associated opcodes [1] available to the fragment execution model for some reason. I'm not sure how something like DXVK handles that. I'm not clear if…

Huh wasn't aware of that. Nice. About the performance question, during the frag shader phase neighbouring pixels are already being tracked, so calling those is almost free. It would be difficult to match that performance when already on the compute phase.

That's just a matter of what's in cache. If your compute shader operates in coherent blocks it should generally be on par with the equivalent fragment shader. The potential exceptions are where access to dedicated hardware functionality is concerned.

What I'm curious about is if there's a hardware intrinsic that computes derivatives or if the implementation of those opcodes is generally in software.

Re: Migrating away from Rust

#710

Post by dudinax »

goku12 wrote: post #499
dudinax wrote: post #275

Earlier quoted context omitted.

My feeling is that rust makes easy things hard and hard things work.

I'm not going to deny your experience. But is Rust really that hard? It's a very smooth experience for me - sometimes enough for me to choose it instead of Python. I know that the compiler complains a lot. But I code with the help of realtime feedback from tools like the language server (rust-analyzer) and bacon. It feels like 'debug as you code'. And I really love the hand holding it does.

"Hard" maybe the wrong word.

Tasks that are simple in most other languages, like a tree that can store many data types, are going to take a lot more code and a lot more thinking to get it to work in rust.

Generics and traits have some rough edges. If I rub up against them, they're really annoying. Otherwise, if I can avoid those then I agree with you that rust is smooth, and the trade off is worth it.

Post reply on HN