Earlier quoted context omitted.
Yes and it's impressive. For the competitive Minecraft player, I suspect starting their VM with XX:+UnlockExperimentalVMOptions is normal. A casual gamer is however not going to enjoy that.
Are you sure that enabling ZGC or Shenandoah requires UnlockExperimentalVMOptions ?
Migrating away from Rust
741–750 of 799 posts
Re: Migrating away from Rust
#742Earlier quoted context omitted.
Rust is actually quite suitable for a number of domains where it was never intended to excel. Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me. edit: The downvoters are missing out.
To me, web dev really sounds like the one place where everything works and it's more a question of what is in fashion. Java, Ruby, Python, PHP, C, C++, Go, Rust, Scala, Kotlin, probably even Swift? And of course NodeJS was made for that, right? I am absolutely convinced I can find success story of web backends built with all those languages.
It's possible to write web backends in Swift, but it's probably not a good idea. When I last did so, I ran into ridiculous issues all the time, such as lazy variables not being thread-safe, secondary threads having ridiculously small (and non-adjustable) stack sizes and there being generally absolutely no story for failure recovery (have fun losing all your other in-flight requests and restarting your app in case of an invalid array access). It's possible that some of this has been fixed in the last 5 years since I stopped working on that project, but given Apple's priorities, I somehow doubt that the situation is significantly better.
Re: Migrating away from Rust
#743Earlier 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…
enum Vehicle:
case Truck(loadCapacity: Int)
case Car(numberOfSets: Int, brandName: String)Re: Migrating away from Rust
#744Earlier quoted context omitted.
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.
Probably the intersection of people who (a) want an advanced ML-style language and (b) are interested in a CLR-based language is very small. But also, doesn't it do some weird thing where it matters in what order the files are included in the compilation? I remember being interested in F# but being turned off by that, and maybe some other weird details.
Re: Migrating away from Rust
#745Earlier quoted context omitted.
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 dev…
The effort of .NET Framework to .NET Core to .NET 5 and now up to .NET 9 is well over a decade long of steady and increasing progress.
Re: Migrating away from Rust
#746Earlier quoted context omitted.
F# compiler is cross os and allows cross compilation (dotnet build --runtime xxx), its packaged in most Linux distros as dotnet.
Ok that helps! So where does F# shine? Any particular domains?
Re: Migrating away from Rust
#747The 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…
> 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. So you mean, Rust is more of an intellectual playground, than an actual workbench? I'm curious how high the churn rate of packages in other languages is, like python or ruby (let's not talk about javascript). Could this be the result of rust being still rather young and moving fast? > Conv…
Both. IMO rust shines as a C++ replacement, ie low level high performance. But officially its general purpose and nobody will admit that it’s a bad tool for high level jobs, it’s awful for prototyping. I say this as someone who loves many aspects of rust.
> Could this be the result of rust being still rather young and moving fast?
My hunch says it’s something different. Look at the people and their motivations. I’ve never seen such a distinct fan club in programming before. It comes with a lot of passion and extreme talent, but I don’t think it’s a coincidence that governance has been a shitshow and that there are 4 different crates solving the same problem where maintainers couldn’t agree on something minor. It makes sense, if aesthetics is a big factor.
> Is Go still forcing hard wired paths in $HOME for compiling, or what was it again?
Nothing I’ve noticed. Are you talking about GOPATH hell, from back in the day?
Re: Migrating away from Rust
#748Earlier quoted context omitted.
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.
I don’t want to use a language with unknown ecosystem. If I need a library to do X, I’m confident I can find it for Go, Java, Python etc. But I don’t know about F#. I also don’t want to use a language with questionable hireability.
Re: Migrating away from Rust
#749Earlier quoted context omitted.
Probably much better, given the improvements on the Swift optimizer, but just goes to show "tracing GC" bad, "reference counting GC" good isn't as straighforward as people make it to be, even if they are renowned developers.
It's a cherry picked, out-of-date counter-example. Swift isn't designed for building drivers. In reality, a lot of Swift apps are delegating to C code. My own app (in development) does a lot of processing, almost none of which happens in Swift, despite the fact I spend the vast majority of my time writing Swift. Swift an excellent C glue language, which Java isn't. This is why Swift will probably become an excellent…
Do you have a counter benchmark? The burden is on you here to disprove the data presented. What that benchmark shows is that you spend A TON of time counting references, much more than tracing GC, unless you enter Swifts C++ networking code. I would think games don’t spend most of their time calling into networking code.
> In reality, a lot of Swift apps are delegating to C code. My own app (in development) does a lot of processing, almost none of which happens in Swift, despite the fact I spend the vast majority of my time writing Swift.
So what you’re saying is that any language will be good for gaming since they all can delegate to C?
> Swift an excellent C glue language, which Java isn't. This is why Swift will probably become an excellent game language eventually.
What makes swift better at calling C than Java? AFAIK Java has a perfectly good and brand new foreign function interface.
> This is why Swift will probably become an excellent game language eventually.
I would take this bet that it won’t. Purely on the sheer fact that gaming occurs on Windows and Swift is barely capable there.
Re: Migrating away from Rust
#750Earlier quoted context omitted.
Yeah this is my absolute dream language. Something that lets you prototype as easily as Python but then compile as efficiently and safely as Rust. I thought Rust might actually fit the bill here and it is quite good but it's still far from easy to prototype in - lots of sharp edges with say modifying arrays while iterating, complex types, concurrency. Maybe Rust can be something like this with enough unsafe but I hav…
You should give Julia a shot. That’s basically that. You can start with super dynamic code in a REPL and gradually hammer it into stricter and hyper efficient code. It doesn’t have a borrow checker, but it’s expressive enough that you can write something similar as a package (see BorrowChecker.jl).