himujjal
But this is what we should be celebrating. Something that came out of people's efforts and hard work.
Maybe in a few years of iteration it will reach a stage where we can actually use it for simple tasks or even as a remote execution setup.
Always good to have options. Also for a programming language that actually enabled the creation of this OS, that is big news! Great going guys!
Yes, its not native to the OS primitives etc. But with a strong core graphics engine, that's just an abstraction away. You can always create WinUI/SwiftUI like look and feel. The ecosystem is what we need to look out for.
Congratulations on the launch and best of luck. A step forward into removing Electron bloat from the world of desktop apps
I don’t like “American” only politics in it. Thats it. In fact I would like zero politics in it. (from anywhere in the world)
Bash the mediocrity in software that we have produced over the years. Slow. Electronbased. Etc.
I can have both the opinions.
Also I will support Andrew Kelley on Mastodon if he says the same.
Separation of Concerns.
But I would really suggest keeping politics out of Zig stuffs.
I don’t even know what ICE is. Just read about it.
This is a show of power.
Like: “I am an American and since I am building the software, I am going to push MY politics into your throat”.
That means, to show similar power, I need to build a software as influential as Zig so that I can push my agendas of my country down your throats.
Heck let me do just that.
Keep politics to politics forums, keep code to code.
One allocator for parser, one for scanner. One for type allocation. Keep them all for semantic analysis. Write the output renderer (binary/language). Deallocate.
In this whole process, it makes it so easy to not think about memory anymore. Just enjoy writing your program.
They have done some incredible job. Implementing things I didnt know existed about software/hardware.
You will receive tons of improvements and updates. I love this idea!
That being said, the Nim team is working on it as per a few issues: [1] https://github.com/nim-lang/rfcs/issues/6 [2] https://forum.nim-lang.org/t/2114
I love the language, and this is probably the only bottleneck for me.
But I left it because of recursive imports. I had to basically put all my types into one file and use them from various others. For a relatively medium sized project (~10LOC), its a but of a hassle. Refactoring is an issue.
That being said, the language is fantastic. Can anybody with experience suggest me what HTTP library/framework do they prefer for servers?
Zig just needs some runtime event loop like Tokio or AsyncIO from Rust to get up and running with its fantastic async model.
This project is really good. Really really good!
You will see the request being sent as a websocket. The lemmy author implemented lemmy so as to see how fast you can get the site working. Inferno, Rust, WebSockets. He probably didnt have expect the scaling issues that come with it.
Anyways, I am happy the site exists. Kudos! Looking towards better implementation in the next release
InertiaJS is an idea/implementation I like and its way of mitigating this issue of meta-framework dependence.
Somehow these meta-framework don't make much sense once you go past the basic DB -> REST -> SSR apis. Productivity decline is a guarantee. DX will suck your soul. Svelte is a far enjoyable library/framework than SvelteKit.
They did bring a lot of good things into the world of JavaScript, but I think this architecture will soon be obsolete for regular template (webpages) or simple SPAs (webapps).
That being said, one of the most promising contenders is InertiaJS though. I think something like InertiaJS will come in 2-3 years and make these meta-frameworks obsolete. Why? The DX.
Using GraphQL and all those jargons and all. Would a Rails app (not considering perf) be good enough for the same.
I am asking being curious.
I should rewrite the project again. But be as simple as possible.
That was my first C project ever during my University. :P
My father and my uncle both have had history of losing cash to robbery earlier in the past in broad daylight. Snatch and run. Huge amounts of cash. My wallet has not seen any paper-based cash in over 1-2 years now and I live in a Tier-4 town/city.
The habit of not giving the extra 1-2 rupees of extra change has gone. Now, its the exact amount. Plus no one these days have to loan out payments. You can directly pay the amount quick.
The scale and the way UPI has become such an integral part of Indian lives is such so much valuable that the minor inconveniences (Privacy & customer care) are ignorable.
Svelte has a cool DX. Best I have seen. SvelteKit not so much.
Now, I am not specifically targeting SvelteKit to be fair. But the whole host of meta-frameworks like NextJS, NuxtJS etc which Vercel is pushing.
These frameworks in general are too much complexity added. SSR is hard and the best way to handle all of these is to not have a server layer at all. That is just abstract the rendering/routing part and leave the rest of the server stuffs to the user.
I want to simply write my Fastify/Express/Go-gin/Django app. Then add SvelteKit as my front-end with SSR support.
Right now, I first write SvelteKit and then think how am I going to integrate Express and Fastify to it (for a moment let's leave non-node solutions).
Trust me. If you simply leave the server out of SK and generate a simple API abstraction like `res.send(renderSKPath('/users/:id', { serverData }))`. It would have done the job.
I think its difficult to express what I want to say, but in short, remove the server and keep SK as a rendering layer only.
P.S. I know that there is an express adapter for SK. But that is not the point of this comment at all.
Plus I can't use it with Go, PHP, Ruby, Rust etc when it comes to SSR (without running multiple servers and handling deployment nightmares).
Something about this whole Node + SSR Front-end is smelly. (next, nuxt, solidstart) I love Svelte as a framework and a way of writing UI, but SvelteKit. Eh! Not so much.
SvelteKit is too much complexity for no reason. Goes opposite of what Svelte was meant to be: Simple and intuitive.
When I say turbopack, I was thinking why the hell would someone need this. Vite is fast enough for everybody. Quite fast indeed. Then there is Parcel which is also quite good and reliable.
I never felt with Vite performance was an issue at all. Everything is so dang fast in my company's website. We are unnecessarily optimizing stuff!
I was writing a compiler I remember where I hit the 5k LOC mark in Nim. And then the errors and stuff. It was a terrible experience putting all the types into one file, the functions into others etc etc. The DevExp is bad that way.
Other than that, I don't see much issues with Nim to be fair. Its quite a good language that ticks all boxes
And this is not actually known before joining. At least bun says that outright.
Some people actually don't mind working hard unlike others if things are interesting. Not everyone is the same. There is certainly more fun working on bun out in the open than solving some random bug in Netflix, Amazon without even being noticed. And with forewarned warning.