This means your difficulty is not programming per se, but that you are working on a very suboptimal industry / company / system. With all due respect, you use programming at work, but true programming is the act of creating a system that you or your team designed and want to make alive. Confusing the reality of writing code for a living in some company with what Programming with capitalized P is, produces a lot of misunderstanding.
Wow. I think that's a serious mistake. Maybe GitHub is no longer so great and snappy but nowhere to justify moving something that needs: 1. Money, 2. Exposition, to something obscure just because it's a bit better. It's Git with an UI anyway, there isn't such large difference. I don't care about the fact the post is harsh: it's the content that it is broken from my POV because. It is absolutely legit to do something like that, in theory, but when you are handling a project that - at this point - is also the chosen language of a non trivial amount of folks, you need to act not just following what you like, but what is better for the project in the long time, and it is very hard to see how going away from GitHub (the fucking big market of open source software in the main city plaza -- let's use the same post tones) is better for Zig. What I think it is better is, of course, not absolutely better, but let's zoom on this issue root cause. It is the classical developer intolerance for tool that are not "as they wish/think", which is very common among technical people, but is a POV, I mean this "tool oriented" workflow, where this little feature/customization matters so much in your life (instead of adapting a bit and do not care), that I believe is a problem in our industry, and also has effects on the design philosophy of many programmers, that are too details oriented. Coders spend the majority of their life in the terminal, not on in GitHub. To check issues / PR there is not this Stranger Things Upside Down nightmare.
Another problem with that is that you know what you are leaving, but you don't really know what you find in the new place. GitHub used to go down often in the early days. Now they may not be snappy and unfortunately like 99% of the web felt for this Javascript framework craziness. But the site is always up, I bet has disaster recovery and serious backup policy, and so forth. Can you find this so obviously in other smaller places?
GitHub Actions are seriously broken and that alone is a technically sound enough reason to move: the sleep.sh bullshit has degraded the performance of our CI for a long time, as it regularly livelocks in an endless while(true) spin runner agents, who stop processing new jobs. The agent itself has poor platform support also because it has a runtime dependency on .NET, and lately GH Actions started running jobs out of order with the result that old jobs would starve and time out, causing PRs to turn up red for no real reason.
It's a real problem to run a project like Zig if your CI doesn't work. I guess we could have paid for an external CI service, but that as well would depend on GitHub APIs, so we would have gained what, a couple years? Given the current trajectory of GitHub I wouldn't trust them to maintain those APIs correctly for any longer than that (and as far as I know the current vibe-scheduling issues might already be reflected in the APIs that third party CI providers would use).
Let's not forget that "GitHub is an AI company now".
As a side note, people said that not posting anymore on Twitter and leaving Reddit was also a death sentence for Zig. Time has passed and we're still alive so far, while in the meantime both platforms have started their final journey towards the promised lands of the elves.
They won't get there tomorrow or the next month, but I'm sure there has been a time where people started moving from Sourceforge to GitHub and somebody else remarked that they were doing something needlessly risky.
As far as we can tell Codeberg is a serious attempt at a non-profit code sharing platform and we feel optimistic enough about its future that we're willing to bet on it.
I hope the best for Zig, Loris. But even if Zig will survive and prosper (I hope for both), still I believe this is not a sounding decision and not the right attitude. I hope I'm wrong, but I wanted to share with you my reasoning. Here you are moving away from the open source marketplace AND from your main revenue stream. It's not similar to not posting anymore to Twitter. A better parallel would be not posting anymore on Hacker News anything Zig related, in terms of potential outcome.
We've been directing people to use other means to donate for a few years now, so GH Sponsors is not our main source of income anymore (and hasn't been for a while). It's still a significant chunk, but it's also not going to go away overnight.
> A better parallel would be not posting anymore on Hacker News anything Zig related, in terms of potential outcome.
I've been thinking about this lately and in my experience (having seen the effect of HN posts in the past when Zig was smaller vs now) the community is already big and vibrant enough that an HN post alone doesn't do too much of a difference. To be clear, I don't think that HN is losing relevance (unlike all the other big platforms mentioned earlier in this conversation), but our situation has changed.
People now are more and more learning about Zig though cool Zig projects, not by looking at yet another superficial language comparison blog post, which is the kind of content that tends to get to the top of HN more often than not.
More in general I think that your point about not pulling away from all the markeplaces of ideas is valid, but most of those marketplaces are not as good as they claim to be and we have the luxury to run a project that has a strong community connected to it, meaning that we won't be starved of attention or contributors by moving away from GitHub.
This whole situation has an interesting parallel with what's happening in our community wrt chat platforms, if we happen to be at the same tech event in person I'll be happy to share with you all the details :^)
> It's still a significant chunk, but it's also not going to go away overnight.
You despise and are leaving GitHub, but intend to keep collecting money from their sponsorship feature/program? Sounds like they are doing something right then…
I had to scroll too far for someone to mention third-party CI. GitHub Actions free runners have always sucked, but the third-party runner ecosystem is really strong for those who can afford it. imo the APIs are far better than the rest of the product - I suspect enterprise customers are strong-arming GitHub to keep them reliable. and there's always third-party CI like tekton if Actions' yaml is too annoying
Namespace fixed all of the issues I had with GitHub Actions. Ghostty uses them to build their project: https://namespace.so
Using Namespace made it clear how much cruft GitHub Actions has accumulated and how much performance they leave on the table. I regard GitHub Actions like Nix: weird configuration, largely shell-based, and the value you get out is commensurate with the investment you put in. But it works well enough.
But at the end of the day, GitHub Actions, like Nix, is just shell scripts. They're fairly portable. I like Namespace because they fixed the parts of CI that matter, like fast local caching versus GitHub's HTTP-based cache.
But I also don't hate this: I use GitHub for the pretty website and global search. Someone will mirror Zig for the search, and my terminal does not care where I clone the repository from. I think this is the new world we live in.
Someone will have to build the aggregator that indexes all repositories and makes them searchable, but that can ultimately be separate from hosting.
As the creator of one of the larger Zig projects, does this announcement undermine your confidence in Zig at all? Either with the language used or the decision in itself?
I do think the combo of not using Twitter, not using Discord, and not using GitHub does make it a bit more challenging for Zig to become a mainstream programming language. Twitter being the least important amongst those. Hard to say how much it matters in practice, as things tend to win on their strengths and not on lack of weakness
> let's zoom on this issue root cause. It is the classical developer intolerance for tool that are not "as they wish/think", which is very common among technical people, but is a POV, I mean this "tool oriented" workflow, where this little feature/customization matters so much in your life (instead of adapting a bit and do not care), that I believe is a problem in our industry
k
Prospective Zig contributors can just adapt a bit and not care about the fact that the project isn't hosted on GitHub, then.
I was happy from the sideline seeing the recent big Zig donations. But this sudden decision is a shock. Technical issues can be worked around (I wish/think), but leaving such a dominant platform? I don't know. For my small small needs Forgejo works great, but for Zig, a project which I hope has a lot of mainstream success, I'm not convinced, that Forgejo/Codeberg is the best fit (atm). Even Graphene OS which has very high standards is (still) on Github, maybe Zig could brood (brüten) a bit longer to decide if it is really time to leave?
They will spend less time on PRs from LLM spammers like you (for anyone who wonders, just Google his username and check the PRs made to OCaml/Zig/Julia), so if anything they freed up resources.
You can create fast to print objects consuming very little filament, however to have some kind of texture on the surfaces is absolutely needed for strength.
That is a neat model. It seems like unlike printables, makersworld doesn't have a 3D preview on the website (or maybe you need to be logged in, or use an app or something)? As I have a Prusa printer, I have naturally falles into using printables (and Thingyverse back before printables was launched).
I will have to download the model and take a proper look in the slicer or CAD program when I'm no longer on my mobile phone. (I will probably not print it, as I'm not currently in the need of a desk organiser, and I don't like wasting plastic.)
For the benefit of those who don't know (I assume you do): Texture absolutely helps rigidity in any part, since if the surface is already curved or creased in one direction it resists bending in other directions. (This is why a rolled up paper is stiffer than a sheet.)
Ah, I have a Mk3.9s, and definitely don't need more than one printer.
I looked at the model on printables, and have a followup question: why does the slit go all the way through? You can make the first few layers print normal and solid (in fact this is very common), so I'm slightly confused as to why you didn't (it would probably increase the strength a bit).
It was an attempt at using less plastic, in vase mode there is this absurd thing that the first few solid layers are accountable often from 30% or more of the whole object weight! However, yes, it would be more robust that way.
Your blog post made me thing that we would almost need a specialized vase mode site for models of that kind :D
Moreover, there is no reason why the top surface could not be closed with bridging. The slicers have a lot of odd limitations in the context of vase mode.
Agreed, I would like to be able to specify vase mode as a height range modifier in the slicer, so I could shift back to non-vase mode near the top.
If you want full control though, you might want to look at https://github.com/FullControlXYZ/fullcontrol (using python to directly generate gcode). Perhaps a bit over the top, but their examples are cool and show things that can't currently be done any other way. You could definitely switch back and forth between vase and normal with it.
Thanks, yep I know ControlXYZ, it's cool but far from practical, I have the feeling their contribution would be a lot more impactful if working with OrcaSlicer.
The problem is how they are fine tuned with human feedbacks that are not opinionated, so they produce some "average taste" that is very recognizable. Early models didn't have this issue, it's a paradox... Lower quality / broken images but often more interesting. Krea & Black Forest did a blog post about that some time ago.
Oh yeah, funny enough even though I’m a bit of an AI art hater I actually thought very early Midjourney looked good because of all had an impressionistic, dreamy quality.
I wonder if we'll get to the point where we train different personalities into an image model that we can bring out in the prompt and these personalities have distinct art/picture styles they produce.
Related: Redis has a keyspace notification doing something similar that is not very well known, but when it is needed, it is really needed. We are thinking of extending this mechanism in new ways. Similarly I have seen setups where the notifications arriving from Postgres/MySQL are used in order to materialize (and keep updated) a cached view in Redis. To me, it is interesting how certain teams relay on these kind of mechanisms provided by database systems, and other teams like to do things in the client side to have full control, even in the face of having to reimplement some logic.
Awesome. You'll see the little stars rotating only in the area they reach your fovea, the most sensible part of the retina. All the rest will not be able to perceive any motion.
META managed to spend a lot of money into AI to achieve inferior results. Something must change for sure, and you don't want an LLM skeptic at home, in my opinion, especially since the problem is not what LeCun is saying right now (LLMs are not the straight path to AGI), but the fact it used to say for some time that LLMs were just statistical models, stochastic parrots (and this is a precise statement, something most people do not understand. It means two things: no understanding of the prompt whatsoever in the activation states, and no internal representation of the idea/sentence the model is going to express either), which is an incredibly weak statement that high level AI scientists refused since the start just because of functional behaviors. Then he slowly changed the point of view. But this shit show and the friction he created inside META is not something to forget.
The problem is the framing. Reductionism always sounds smart and is rhetorically effective but usually just loses all nuance or meaning. I've never met a parrot (stochastic or otherwise) that could write python code or rewrite my emails so what is the point of you describing it like that besides wanting to sound smug and dismissive?
The point is that next-token prediction produces output by sampling from distributions assembled by text it has seen previously (hence stochastic). The “ding” or claim is that - like a parrot - LLMs can’t produce responses which are truly novel in concept or make logical out-of-sample leaps, only repeat from words they’ve been taught explicitly in the past.
So you think stochastic parrot is an accurate term and not an attempt to be dismissive? So if someone woke up from a coma and asked what ChatGPT is you would say "stochastic parrot" and think you've explained things?
While “stochastic parrot” is obviously an over-simplification, and the way the phrase was originally coined in context was likewise obviously intended to be dismissive, I think the analogy holds. I see them as a lossy storage system.
I think the expectation that simply continuing to scale the transformer architecture is not likely to exhibit the type of “intelligence” for which _researchers_ are looking.
For my personal taste, the most interesting development of NLP in this latest AI wave (and LLMs in general) is RAG. I also have always wondered why the tokenization process hasn’t been deemed more important historically. To me, it seems like THE MOST critical part of how Deep Learning works.
Redis does not flush pages to disk. When the RDB / AOF are generated by the saving child, it is a point-in-time operation not bound to the speed data is added in the parent.
Redis stores the magnitude of the vector and stores the vector in normalized form, so indeed we just do dot product :) But yet we can reconstruct the vector back. I totally forgot to mention this in the blog post!
reply