Which I as a German simply fail to fathom. The quality of our Deutsche Bahn is so bad I would never drive by train. The worst thing is that they are incapable to have their trains be on time. Whenever you travel there is an extremely high chance you will not arrive at your destination in time.
It's still more punctual than going by car. I can't remember any long distance car trip where I wasn't stuck in traffic and my trip was much longer than predicted by the navigation system.
Not every trip is time sensitive, most trains do run on time, and not all trains are operated by your nemesis. If you still refuse to "ever" take a train anywhere, that's on you rather than the system
Because it is a regional problem and some areas work mostly fine. I also fail to fanthom why people drive in rush hour, queuing every day for hours. Yet people do that. And people love to complain, especially those that only take trains on public holidays. But hey, here in Sweden the trains are worse than in Germany, but people complain far less and trains are full anyways.
Prepared a presentation for months to hold in front of my entire company. Has been down since 9:21 German time. Had one of the worst nights of my live. Now we had to postpone the presentation by two weeks.
In general I agree with you, but sometimes the “live”ness of demos is essential. I’ve given quite a few presentations about LLMs over the past year and a half, often to audiences unfamiliar with or doubtful about them. Being able to have on-the-spot, unplanned interactions with an LLM has been very useful for showing listeners that they are not just preprogrammed algorithms.
But I’m giving another demonstration in a couple of weeks, and this time I will be ready to show not only ChatGPT but also Claude and Gemini. And I’ll have some previously prepared examples ready in case the Internet connection goes down.
IMHO the fact that Zig already gained a lot of track in software development does bring some responsibilities whether the devs like it or not. If you create a language that good and something that is actually taken seriously for tackling the behemoth task of being the actual predecessor for C that has been around half a century, then you CANNOT simply excuse weak points with "the language is not done, yet.".
No sorry for you guys, you made some freaking good stuff, people wanna use it in production already, deal with your success. And there aren't even many pain points with the language itself. Most of them are meta. Here are my pain points:
- Documentation: Step it up... this is a mess. I might be able to learn it because I learned many languages over the years, but many people will just give up frustrated and never turn back. And even so I am mostly OK with the docs, I still miss stuff.
One of the worst things could as well be its own point: Document the build system darn it. It is so hard to learn, that I prefer using any other build system or even creating manual zig commands.
- ZLS needs to be merged as part of the project. The fact that it is not always on par with every commit is annoying. A language server should be an inseparable part of a language nowadays.
- And now to one of the few pain points I have with the language itself: You cannot be serious about that "underscore, unused variable" solution. That is so extremely ugly and code polluting.
I know this critique was harsh, but it is because I love this language and I think it will take off so heavily :). My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase.
Considering that the language is "not done yet", I think the documentation is quite ok for now. But I'd really like a proper language specification, similar to https://go.dev/ref/spec, updated in lockstep with the implementation. I also agree that the build system needs some minimal documentation. It is a bit arcane without it.
Considering that a major goal of Zig is to build and maintain robust software, the decision of making unused variables an error is interesting and worth exploring. It works pretty well in practice when we use ZLS, which goes back to your point about making ZLS part of the standard toolchain.
> deal with your success
And how exactly should the Zig team deal with its success? That's a small team, with limited funding. Do you think they should prioritize the pain points you listed over the ones in their current roadmap?
This isn't specific to Zig. But most thing you said is a feature not a bug. Let me quote from the release note.
>This Release Contains Bugs, Zig has known bugs and even some miscompilations.
>Zig is immature. Even with Zig 0.12.0, working on a non-trivial project using Zig will likely require participating in the development process.
I dont think documentation should be priority for Zig at this stage, just read the Release Note and you will see how things are changing and breaking all the time. But I do agree certain things should be documented, as suggested in another reply is the Spec and build system.
Seems, Java/C#/C++ more to your taste where corporate behemoths behind them can put more people on documentation and assorted tooling than zig has for core development.
> My fear is that if those things are not considered that at a certain point users will be annoyed by Zig and it will lose a big amount of userbase.
They won't use much user base as that kind of users will remain committed to using corporate managed languages.
Fuck yeaahhhh murrica ...we like all kinds of sick fucked up shit but nonono don't show my kid any titties on TV or lord behold text with sexually revealing vocabulary. Laughs in European ...
Have you guys ever thought about the fact that there are nerds that like so socialize and hate working from home, because it gets f'ing lonely after a while? I want to see people. The corona pandamic where I worked almost 2 years from home drove me into a severe depression.
Yes, I have a theory based on this. I think that roughly 40%-60% of developers prefer remote, the remainder prefer in-office. So if you mandate in-office, roughly half of your developers will be unhappy. If you go full-remote, again, roughly half of your developers will be unhappy. So what do you do? I think you have to pick one and stick with it. Over time, you'll collect people who prefer remote or in-office. It won't be easy, but doing "hybrid" is absolutely the wrong decision, that makes no one happy.
The reason I like the office is mostly for the free food and events. I don't get much more out of my coworkers by being physically close to them. They don't like to be bugged (I don't either, usually). Maybe a little at lunch when I can pick their brains about random crap that doesn't warrant a meeting but not much.
On the other hand I have no interest in socializing with my colleagues, and I'm no intravert either. I have plenty of actual friends outside of work, and the nice thing about working from home is that I can catch up with my mates during the workday while still working!
Yes? And people like you have enjoyed an office environment that by default catered to you. It's not those of us who finally found productivity in a controlled, quiet environment that lack empathy, it's you, the group that can't imagine that "normal" might not be universally healthy and that for the first time are finding themselves not the default perspective.
I start taking LLVM serious when they give easy to follow documentation on how to compile LLVM completely GCC/binutils/gnu libc independent. I mean a single go to point with easy instructions.
You have to Google everything and then you find out about EXPLICIT_LIBGCC_OPT_IN and you read unofficial responses to issues that describe how to use libunwind and compilert to replace libgcc_s. But all that stuff is out of date fast and never works. Even Rene Rebe who developed T2 ranted about this in 2019 and he couldn't completely figure it out without doing a shitton of workarounds and patches. You need to be fucking Stallmann or Torvalds or whatever computer scientist genius themselves to achieve this. Or Google who did this for Android and Fuchsia. My point is it is rocket science at this point.
Fucking make that straightforward already dear LLVM project.
Regardless of whether you take LLVM seriously, it's a serious project in serious commercial use in many environments.
> Fucking make that straightforward already dear LLVM project.
Much of what you are asking for can be enabled by not-rocket-science changes to the driver. Give it a try.
The LLVM project is much more "bazaar" than other high profile Open Source projects, so I think you'd have a relatively easy time convincing folks to accept your changes provided they don't break existing tests.
It's "ok" along these axes, a bootstrap for gcc isn't all that straightforward either, the main difference being that if you've already done "apt install build-essential" or similar it just so happens that "it's done" - albeit entirely non-hermetically and the bounds of "it" is probably entirely unknown to the user. I had this discussion with a kernel engineer once who insisted gcc had almost no external dependencies, and he believed this for this reason.
The parts that make it only "ok" are largely cmake derived problems - yes there's sometimes incomplete docs and so on, but largely the confusing parts come from the multi-project split and cmake reconstitution. I'm particularly excited for a future when llvm-libc has made some more progress, at which point a very hermetic build will get quite a bit easier.
The thing is that if you're cross-building this is really the answer, cross building with the deeply intertwined gcc chains is an equally awful experience. I'll take a static clang tool build I can zip up and give to everyone (except nix, because they decided loader hell should only be played on max difficulty) over a fragile distro intertwined mess any day.
> I start taking LLVM serious when they give easy to follow documentation on how to compile LLVM completely GCC/binutils/gnu libc independent. I mean a single go to point with easy instructions.
That's a very niche use-cases. Most people don't care about being "completely GCC/binutils/gnu libc independent".
It's fine to care about your niche use case, but to claim a project is not "serious" because this one thing isn't supported is ridiculous.
macOS LLVM is a bit of a special distribution. It's nice that there's a mostly well built LLVM distribution there, but the pain in the ass is that they ship a custom linker and _don't ship lld_, which means you can't readily use their distribution for a lot of common cross build targets - you need to go build at least an lld to get over the line.
reply