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

Really annoying, I was starting to use it for a few niche communities instead of Reddit.

If they relaunch, I hope they develop something integrated with the fediverse. I believe the time to build walled gardens is over, plugging with the fediverse might give them a running start to build something g together with the wide fediverse community, maybe something easier to use for non-techies and well moderated.

We will see I guess…


Well, most of the Threadiverse would block federation with digg if that were to happen, just like how it happened to threads.


Rust/Loco is unironically the most interesting framework right now.

Loco follows up the Rails formula pretty closely, and makes easier to learn Rust by taking care of a load of boilerplate code.


Concur on most interesting! I really hope it works out, but am cautious.

It is surprising to me seeing the rust web backend scene; many libraries, server frameworks, and users, but they are all Flask-analogs, without the benefit of the reasonably-robust ecosystem Flask has. My suspicion is that people are using them for micro-services and not websites/webapps, but I haven't been able to get a straight answer on this about how people are using these tools. I.e. even though rust is my favorite overall language and see no reason it couldn't be used for web work, I still use Django.

Axos, Axum, Rocket, Diesel etc, are all IMO not in the same league as Django. My understanding is that addressing this is Loco's Raison d'etre.

Another aspect of the Rust web ecosystem: It's almost fully gone Async.


It's quite a gap really.

I'll say this, coding agents make the lack of a "batteries included" framework like rails or Django somewhat less daunting.

But "convention over code" and having a default structure / shape for projects is extremely helpful and you feel it when it's missing.

For my last small project I looked at Loco but ended up passing on it because I felt like adoption wasn't great yet. I really hope it takes off, though.


It's really hard to get away from ssjs frameworks for front-end, so for my startup it's Axum + Seaorm for "the api" and a Svelte SSR "front end" / view layer.

I think rust programers are more likely to want flask/rack than Django/rails.


I'm at a point now where I'm not even a little interested in new frameworks. I want tried and tested. Preferably something that has been around for 15 years.


I am keeping Facebook just because of a couple of Groups.

My timeline is completely useless, I have an endless stream of suggested post and ads, nothing relevant to me.

Meta is supposed to know me, I use Instagram quite a bit (following F1 teams, some comedians and a bunch of tiktok-style content creators), but somehow this does not translate in targeting on FB, just generic targeting for my population type.

I tried Threads and it was the same. Pretty useless.

Say what you want about X, but at least there I can curate my Following tab and Lists, and have an informative experience.

Except for Instagram due to my F1 passion, Meta is completely useless for me. And once I move those followings on X and Youtube, I guess I'll have no use for Meta software at all. Kind of a shame.


Another reason to use Gemini then.

Less impact on gamers…


TPUs still use ram and chip production capacity


They could have led the way to a social web using Google Reader.

Make a Disqus-like comment section that shows the comments in RSS articles from Reader.

Also Reddit, by empowering the GReader Groups capabilities.

But no, let's copy Facebook and force everybody on it. And kill Google Talk while at it.

I'll never forgive Google for that.


Yep, luckily they represent a very small, albeit loud, minority of Linux users.

The vast majority of Linux users are very happy to get an official GOG Galaxy for Linux. I hope they will plug into Proton and collaborate with Valve, but we really need official tools and brands on Linux for common users to feel comfortable enough to come over.


Couldn't agree more! I have been purchasing on steam due to the lack of a native client, especially save game syncing. As a bonus, as a greenfields project, maybe we'll see less cruft than the native Steam client.


Remember Valve released HL: Alyx to promote their first VR headset.

It is not unreasonable to get a pair of titles to promote these two new products.

A man can dream, but a new HL for the Steam Machine and a new Portal for the Frame would be great.


It would also be the biggest sales pitch in the universe

"Buy a Steam Machine and get Half Life 3 for free" "Buy a Steam Frame and get Portal 3 for free"

Tech and software support should be absolutely perfect though..


Exactly this point.

Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.


You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.


There are quite a few gotchas for this, especially web apps. THis is understandable because it was added after the fact, vs. a first-party design requirement. It's cool and might work for you, but taking a non-trivial .net codebase to native AOT can be tough, and if you're starting greenfield, why go .net?


FWIW, the .net folks seem to have put a lot of effort into the native AOT pipeline in the last few releases. We have a large, non-trivial application with a fair amount of legacy code, and getting it AOT’d in .net 10 (targeting wasm, even!) was not an insane lift.


How is the WASM target looking nowadays? I tried it in 2023 and early 2024, and it was far from complete (JS interop, poor documentation scattered across GitHub issues, and so on). I still can't find a single trustworthy source of documentation on how to proceed. C# would look great at the edge (Cloudflare Workers).


Sure, legacy applications won't be easy to move over but Microsoft has been quite consistent in working towards making microservice applications easy to build and run with AOT by moving more and more components over to using source-generators and promoting minimal-API's.

Their target is probably not entirely greenfield projects (although I wouldn't mind it myself), but rather those with existing investments that start new projects that still want to share some parts.


And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.


You can't use reflection with AOT compilation. That's what AOT compilation is. Java has the same limitation for AOT compilation, for example.


Most reflection usage is for JSON (de)serialization and for that you can use source generators, which also offer better performance.

https://learn.microsoft.com/en-us/dotnet/standard/serializat...


These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.


Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.


Golang's reflection is severely limited by design, so that there is nothing to restrict during compilation. On the other hand, you lose out on powerful tools such as C#'s System.Reflection.Emit. To note, the biggest library limited by AOT compilation, ASP.NET (which does still work with it if you design around the limitations), is being updated to work better with it (and source generators play a big part of that).


They're self contained and native, but they're still massive.

There's been some work on CoreRT and a general thrust to remove all dependencies on any reflection (so that all metadata can be stripped) and to get tree-shaking working (e.g. in Blazor WASM).

It seems like in general they're going in this direction.


Smaller is better, of course, but I've never found the size of .NET binaries to be an issue.

What problems does this cause?


If you're trying to pack hundreds of microservices into a cluster, having containers using 80MB of ram minimum instead of 500KB can become a big deal.


Not every library is capable of building to Native AOT, which means any app that depends on those libraries run into the same problem. If the library or app uses reflection, it likely isn't capable of Native AOT compilation.


Just an FYI, Go still bundles a runtime in its native binaries. C#'s AOT has restrictions on what works (largely reflection), but these same restrictions apply to Go (although Go applies these restrictions into how it's designed for the entire thing).


rust and go are only good at single binary. when you need a few their size adds up quickly, because they don't really do shared libs.


Gambas is a modern, open source Visual Basic dialect in the style of VB Classic.


I tried bsky for one year, and I agree that I was getting mostly American politics… which as a European is just noise for me.

I went back to Mastodon, it’s much better to follow tech people.

And feedly for RSS to get all the news I can dream of.

Not sure what the point of Bluesky is anymore, it’s just twitter but on the left side of politics. Sad, the tech stack was interesting as an evolution of Nostr.


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

Search: