thanks, i enjoyed reading it (though a bit lengthy).
what gets me personally is what you describe at https://github.com/little-book-of/c/blob/main/articles/zig-i... - zig is made to feel easy and modern for people who don't know any better, and it does this well. But as soon as you actually need to do complex stuff, it gets in the way moreso than C and it's current environment/ecosystem will.
And to be fair, as much as I enjoyed writing in C in my younger years - I only use C when I actually need C. And asm when I actually need asm. Most of my code now uses higher level languages - this puts zig into such a niche.. it feels like golang to me: the cool language that isn't really solving as much of a need as you'd think.
I don't think zig is that much more complex than golang, with a (currently) crappier standard library. The bonus being you leave no performance on the table. I wonder if it would work with devops, where both c++ and rust fails.
And I want to clarify again, these are just personal notes written with some help from LLMs. They may contain mistakes, so please read them with curiosity, or feel free to skip them altogether.
I mean, if you embed Zig in a larger C++, Rust, or Python project, coordinating the build systems can be difficult. Zig prefers to manage the entire pipeline itself, so mixing it with other compilers and dependency managers can require workarounds. In my opinion, the only practical way to do this is by exposing C interfaces.
It might have been a bit harder in the past, but with recent versions of neovim (>=0.11) it's less than 20 lines of configuration. I have quite a few keybindings to jump back and forth through errors and the default keybidings already include things like renaming, go to definition or listing references.
I'd be more than happy to help you configuring it to your needs.
FWIW, in my (emacs, C++) experience, writing the editor config is a relatively minor part of the yak-shaving required to have jump-to-definition on an actual work codebase.
I had to get my project to emit compile_commands.json, get clangd, figure out which things about our build process clangd was not understanding from compile_commands.json and add them in .clangd. All to achieve a level of functionality significantly jankier than just opening the damn .sln file in Visual Studio.
Once I did all that it was, as you say, very little actual stuff written in my .spacemacs. And probably could have been less if I had felt like figuring out how to get my windows emacs to find clangd on the path instead of giving up and just specifying full paths to everything.
I only persevered because emacs (unlike Visual Studio) gives you all the necessary access to its internals to build LLM Tools around its LSP functionality.
Whatever vim is in rhel 8 supports ale. Ale with rust has been great. Go to definition is flawless, all my conpile and clippy errors are underlined as I type and binding a key to ALECodeAction will apply the auto fix if it has one. Usually that is to import whatever I just used, which vscode would do automatically, but still its nice and having vscode use clippy as well as check bogs it down. And ale runs cargo-fmt on save. So yeah, nothing I'd wish different from it.
Edit: upon further thought, I don't like having to move my hand to the arrow keys to select from the auto complete list, even if there is only one thing and then hit enter, rather than hitting tab to pick whatever is left.
> I had to get my project to emit compile_commands.json,
> get clangd, figure out which things about our build
> process clangd was not understanding from
> compile_commands.json and add them in .clangd
That sounds rough. This is anecdotal, but in
my Linux corner of the world, ccls has been
an easier user experience as a C and C++ LSP
since I've never had to resort to messing with
flags in the generated file.
I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.
By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.
The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:
My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.
I did actually try CCLS first, but this was several years ago so it's possible that it may work better (something about our codebase was causing it to crash) - I should try it again.
Lacking LSP didn't stop me from using spacemacs, though. Oh, no. emacs has an auto-complete mode that just chooses from a pool of symbols already present in open files and that turns out to be Good Enough for me to prefer editing code there vs Visual Studio, IntelliSense be damned.
My employer furnished me with a beefy enough workstation that I can have Visual Studio open (to semantic search the whole codebase for stuff I don't already known where to find and to build/run/debug) alongside emacs (for editing and general code browsing when I know where definitions live).
Same. I love vim and have no plans to leave, but I have no interest in being on the upgrade treadmill when my current system isn't broken. I've also had plugin updates break stuff, and it's a simple rollback in git back to a working state. I'm not sure how hard that is with these various plugin managers, but it's quite simple with git and I don't have to learn yet another tool/way of doing things.
This was an interesting read and very educational in my case, but each time I read an article criticizing a programming language it's written by someone who hasn't done anything better.
It's a shame because it is just as effective as pissing in the wind.
If you're saying someone can't credibly criticize a language without having designed a language themselves, I'll ask that you present your body of work of programming language criticisms so I know if you have "produced something better" in the programming language criticism space.
Of course, by your reasoning this also means you yourself have designed a language.
I'll leave out repeating your colorful language if you haven't done any of these things.
> If you're saying someone can't credibly criticize a language without having designed a language themselves
Actually I think that's a reasonable argument. I've not designed a language myself (other than toy experiments) so I'm hesitant to denigrate other people's design choices because even with my limited experience I'm aware that there are always compromises.
Similarly, I'm not impressed by literary critics whose own writing is unimpressive.
Who would be qualified to judge their those critics’ writing as good or bad? Critics already qualified as good writers? Who vetted them, then? It’d have to be a stream of certified good authors all the way back.
No, I stick by my position. I may not be able to do any better, but I can tell when something’s not good.
(I have no opinion on Go. I’ve barely used it. This is only on the general principle of being able to judge something you couldn’t do yourself. I mean, the Olympics have gymnastic judges who are not gold medalists.)
I’ve never been a rock star, but I think Creed sucks.
I really don’t like your logic. I’m not a Michelin chef, but I’m qualified to say that a restaurant ruined my dessert. While I probably couldn’t make a crème brûlée any better than theirs, I can still tell that they screwed it up compared to their competitor next door.
For example, I love Python, but it’s going to be inherently slow in places because `sum(list)` has to check the type of every single item to see what __add__ function to call. Doesn’t matter if they’re all integers; there’s no way to prove to the interpreter that a string couldn’t have sneaked in there, so the interpreter has to check each and every time.
See? I’ve never written a language, let alone one as popular as Python, but I’m still qualified to point out its shortcomings compared to other languages.
> See? I’ve never written a language, let alone one as popular as Python, but I’m still qualified to point out its shortcomings compared to other languages.
You kind of undermine your argument here, because someone experienced in building languages wouldn't identify this as a shortcoming of Python compared to other languages, but rather a design choice that was made to support other features; designing a language is all about making these tradeoffs to achieve specific design goals. It's one thing to keep boxed values around and be slow because of it -- it's another to do so because you want to support a dynamic type system.
This might be what the other poster was getting at when they said they don't want to listen to non-experts here, because the criticisms are usually shallow and based on personal programming preferences rather than an actual critique of language design.
Anyone would identify that as a shortcoming, albeit one deemed worthwhile giving the flexibility it brings to the table. It’s certainly not an advantage of the language to have to do that slow check on every operation. It’s just a downside to all the dynamism we enjoy.
Also, I said I didn’t write a language. I never said that I didn’t maintain my own local fork so I could play with the VM and add opcodes to it and see what happens if I try experiments like “assume that all(type(_) is type(list[0])) for _ in list[i..])”, which I’ve done just for fun to see how it’d explode when that assumption fails.
But no, I haven’t written a language of my own, I apparently I’m not qualified to have an opinion.
I don't identify that as a shortcoming, because it enables the dynamism. A "worthwhile shortcoming" is just another way of saying "tradeoff".
You might as well say C++'s performance is a shortcoming because it's a result of static typing, which is hard to write compared to dynamic languages. Or Rust's safety is a shortcoming because it has worse compile times compared to Go. Or Java's JVM is a shortcoming because it doesn't compile to machine code like C.
Just because a language doesn't have the same features as another doesn't mean it suffers a shortcoming. A shortcoming only exists in the context of your own use case, which is different from everyone else's. What you label a "shortcoming" is the feature others are looking for in their language.
> But no, I haven’t written a language of my own, I apparently I’m not qualified to have an opinion.
Your opinion is fine, the OP was just saying that they would like to hear a qualified opinion because they are left wondering how a language designer might change Go for the better.
But you should try designing and implementing your own language, it's a lot of fun and a worthy exercise for any dev.
As someone living in Spain, this is the only time of the year when I'm happy to go to the office. Yet, I think people need a tutorial on how to use the AC: it's 38ºC outside, but in my cubicle it's about 19ºC - I would be OK with 26ºC.
Had to study this at school a while back, it was one of the first books (after Candide by Voltaire) that I found interesting at the time, and still have in my little library.
> GLSL is dead end, Khronos is on the record they aren't going to develop it further, even for Vulkan, HLSL and now slang, are the way forward.
I've been seeing more comments like yours saying GLSL is a dead end, and it’s making me question whether I should keep learning it.
But at the same time, it’s still very accessible, well-documented, and used in OpenGL demos and educational content. Would you say there's still a case for GLSL in hobby projects, demoscene work, or rapid prototyping? Or is it really time to move on even in those contexts?
