[HN Gopher] Why aren't there C conferences? (2018)
       ___________________________________________________________________
        
       Why aren't there C conferences? (2018)
        
       Author : optimalsolver
       Score  : 110 points
       Date   : 2022-08-26 12:31 UTC (10 hours ago)
        
 (HTM) web link (nullprogram.com)
 (TXT) w3m dump (nullprogram.com)
        
       | rjsw wrote:
       | There will be ISO/IEC JTC 1/SC 22/WG 14 meetings as well as those
       | for national mirror committees like ANSI X3J11, there isn't much
       | point in having a conference outside this standardization
       | process.
        
       | matt_heimer wrote:
       | No interesting in paying for pointers.
        
       | mhh__ wrote:
       | Excited programmers who want to go to conferences don't care
       | about C anymore, IMO
        
         | marginalia_nu wrote:
         | I'd love to go to a C conference, not gonna lie. But I've been
         | a graybeard ever since I was a child.
        
           | ungamedplayer wrote:
           | lBorn with a manual in one hand and a PDP11 in the other.
        
             | sgt wrote:
             | I don't know, PDP11's are pretty heavy. That'd be one flat
             | hand.
        
             | marginalia_nu wrote:
             | Couldn't get to sleep without hugging my K&R.
        
             | pklausler wrote:
             | You kids with your shiny PDP-11s.
             | 
             | Me, I had to start out with a machine that didn't even have
             | load or store instructions (CDC 6600).
        
               | drivers99 wrote:
               | Out of curiosity, I checked wikipedia which says "In the
               | 6600, loading the value from memory would require one
               | instruction, and adding it would require a second one" so
               | I'm curious what the distinction is if it's not a load
               | instruction
        
         | omgmajk wrote:
         | Some of us fall under that category. But I guess we're not that
         | many.
        
         | lionkor wrote:
         | thats a very measured response, im sure you're right and thats
         | not just a really biased view /s
        
       | jjtheblunt wrote:
       | > Why aren't there C conferences?
       | 
       | seems a question that could give birth to Chuck Norris style
       | jokes.
        
       | hnthrowaway0328 wrote:
       | TBH I always wonder why do we need conferences at all? Anyone who
       | wants to share something can always pull up a youtube video. If a
       | committee wants to discuss something they can always pull up a
       | Zoom meeting. I'm not sure why they exist at all except for
       | people who want to travel and sell things/ideas.
       | 
       | But since I have never attended any conference, I must missing
       | something important here.
        
         | yoyohello13 wrote:
         | The valuable thing about conferences is the "hallway" chats and
         | networking opportunities. If you just want to listen to talks
         | then you can pretty much get that online, but running into
         | other like minded people and grabbing a beer together is a fun
         | experience.
        
       | treeman79 wrote:
       | Been noticing a trend where conferences have gone highly woke.
       | Last one I attended had a young woman was berating all the men
       | and demanding we apologize for things others have done.
       | Complaining about it got one person banned.
       | 
       | DHH Being banned by Ruby Conference is another example.
       | 
       | I went to be part of cool tech, not radical politics. I Haven't
       | done another conference since.
        
         | JonChesterfield wrote:
         | To spare others a search, 'DHH' appears to be the person
         | credited with creating ruby on rails
        
           | falcrist wrote:
           | And being "banned" appears to mean "he wasn't invited to do
           | the keynote presentation this year".
           | 
           | > Hi David,
           | 
           | > Hope you've been well.
           | 
           | > With you having been mostly offline the last year, the
           | program committee has decided it would be valuable for the
           | community to start sharing the opening keynote stage with
           | other contributors. We have a few in mind but if you have any
           | suggestions of people who have been impactful this year,
           | please share them.
           | 
           | > If you have any questions, please let me know.
           | 
           | > - Evan
        
         | Demonsult wrote:
         | I wonder if anyone can provide an example where collective
         | guilt was meaningful or productive in any way.
        
           | RhysU wrote:
           | The guilt of original sin driving individuals towards
           | redemption via organized religion thereby allowing
           | increasingly large, stable civil structures in Europe.
        
             | Demonsult wrote:
             | I hadn't thought in terms of collective guilt including
             | everyone
        
             | californiadreem wrote:
             | Augustine and a clear exposition of original sin was in the
             | late 4th-early 5th century, about four hundred years after
             | the Roman Empire had already effectively integrated quite a
             | bit of Europe and Asia into a diverse and sophisticated
             | civilization that wouldn't be seen again for another
             | millenia.
             | 
             | Around six hundred years after Augustine, Europe had
             | William the Conquerer and the Holy Roman Empire, I guess?
             | Five hundred years after that, Europe had the Renaissance
             | based in a reclamation of the heritage of the ancient
             | world.
             | 
             | I don't think original sin did a very good job of achieving
             | the integration of anyone.
        
               | RhysU wrote:
               | https://en.m.wikipedia.org/wiki/Original_sin says "The
               | belief began to emerge in the 3rd century..." which is
               | early enough to establish mild causality for Emperor
               | Constantine. Remember, he didn't have to believe it only
               | to suspect that it would be useful.
               | 
               | The whole thing was meant to be tongue in cheek. :)
        
         | immibis wrote:
        
         | gspr wrote:
        
         | jmconfuzeus wrote:
         | Conferences aren't worth it.
         | 
         | You can learn anything for free on the Internet.
         | 
         | If you're going there for networking with others then stop. You
         | can't network with blue haired women with daddy issues or men
         | who never graduated from kindergarten.
        
       | belter wrote:
       | All these talk about C
       | 
       | * https://startupstash.com/c-cpp-conferences/
       | 
       | Always felt like the ACCU, was the closest to a C Conference,
       | something that, as many mentioned here, does not really exist.
        
         | IshKebab wrote:
         | I don't think I saw a single C talk at the few years I've been
         | to the ACCU conference.
         | 
         | I think there's just rarely anything new to say about C since
         | it's so old and stable.
        
           | belter wrote:
           | "Modern C and What We Can Learn From It - Luca Sas [ ACCU
           | 2021 ]" - https://youtu.be/QpAhX-gsHMs
           | 
           | "Linux User/Kernel ABI: the realities of how C and C++
           | programs really talk to the OS - Greg Law" -
           | https://youtu.be/4CdmGxc5BpU
        
       | dang wrote:
       | Related:
       | 
       |  _Why Aren 't There C Conferences?_ -
       | https://news.ycombinator.com/item?id=18504879 - Nov 2018 (372
       | comments)
        
       | vmilner wrote:
       | Probably the closest there is:
       | 
       | https://accu.org/conf-main/main/
        
       | gjadi wrote:
       | Lots of interesting links to talks related to C at the end of the
       | articles!
        
       | arianvanp wrote:
       | I'd argue though not directly C conferences there _are_
       | definitely conferences where C developers come together.
       | 
       | * https://lpc.events/ * https://fosdem.org/ * https://all-
       | systems-go.io/
        
         | spaceywilly wrote:
         | There's plenty of conferences for embedded developers as well.
         | I would argue that having a conference around a _job function_
         | makes a lot more sense than having a conference around a _tool_
         | , which is what a programming language is.
        
       | rebolek wrote:
       | People using C don't have a time for conferences because they
       | have a work to do.
        
         | fredrikholm wrote:
         | I can't decide if this is a statement or a joke. I agree with
         | both.
        
           | agentultra wrote:
           | Undefined behaviour detected.
        
             | alyandon wrote:
             | Since it is UB, I'm going to rewrite the parent comment to
             | say "I like cabbage!".
        
       | sys_64738 wrote:
       | They call them security conferences nowadays.
        
       | bluetomcat wrote:
       | For the same reason that carpenters do not have conferences about
       | saws and hammers. It's an old tool with well-known deficiencies
       | and it doesn't attract an idealistic, evangelical crowd that can
       | write manifestos and narratives about it.
        
         | kjellsbells wrote:
         | Well, they both have vices, and offer plenty of opportunities
         | to leak memory or blood, so I guess there's that.
        
         | casion wrote:
         | We absolutely do have those conferences! I've been to dozens.
         | 
         | Lots of idealists and evangelicals in the woodworking world as
         | well, probably more so than any other world I've been in. Makes
         | technology look fairly tame.
        
           | agumonkey wrote:
           | Never saw handtools confs but surely the mechanical woodwork
           | confs have surprisingly large and numerous amount of new
           | tools to show.
           | 
           | For hand tools I mostly saw japanese woodworker competitions.
        
           | chrisseaton wrote:
           | > I've been to dozens.
           | 
           | Something like 'The 393rd International Conference on
           | Hammers'? With people presenting about the latest
           | developments in hammers and how they're using hammers in new
           | ways? You've been to dozens of those?
           | 
           | Not sure I believe you.
        
             | casion wrote:
             | The OP said saws and hammers, and there are conferences on
             | hand tools which largely focus on saws, hammers and hand
             | planes.
             | 
             | If we want to be literal then I don't know of anything on
             | _just_ saws and hammers, but in the quite adjacent space
             | (one or two hand carpentry tools also a focus) - yes.
        
               | chrisseaton wrote:
               | Well yeah we do have general conferences on programming
               | languages. But the point is we don't have a specific
               | conference on C, like you wouldn't have a specific
               | conference on a simple hammer.
        
               | kryptiskt wrote:
               | Comparing programming languages to a specific tool is not
               | the right analogy. A programmer can specialize in C, no
               | carpenter specializes in hammering.
        
               | phlipski wrote:
               | John Henry specialized in hammering... He was a steel
               | driving man!
        
               | adamdusty wrote:
               | But tech also has conferences on specific languages.
               | Seems like a JS, C#, C++, Java, python, etc. conference
               | could be analogous to hand tools for carpentry.
        
               | chrisseaton wrote:
               | Exactly - and there isn't one for C. That's the whole
               | point of the thread.
        
           | SeanLuke wrote:
           | You've been to dozens of conferences about hammers?
        
             | SomeBoolshit wrote:
             | They're about to release Hammer 2, it's gonna be a
             | subscription.
        
               | Forge36 wrote:
               | We have so many handles. Wood, metal, plastic. A variety
               | of heads! Sand-filled (dead-blow), brass, plastic,
               | hardened metal, soft metal.
               | 
               | A subscription to deal with the wear-and-tear is probably
               | only needed for the larger shops.
        
               | brudgers wrote:
               | Did you mean "an AI powered cloud based subscription in
               | Rust?"
               | 
               | OK, maybe Rust isn't such a good idea here.
        
             | galangalalgol wrote:
             | They have hand held precision cnc machines that use
             | computer vision to register to the work piece and
             | compensate for human error and execute the file.
             | 
             | I can't wait for people to start asking stable diffusion or
             | dall-e for ideas. "unusual danish modern canopy bed 85mm"
             | 
             | I'm sure they won't run out of advances to talk about. And
             | people keep reviving old techniques that got ignored too,
             | or ones from other cultures.
        
             | IgorPartola wrote:
             | A conference about hammers is closer to a conference on
             | arrays. But a conference on carpentry is closer to a
             | conference on novel algorithms and memory structures.
        
               | SeanLuke wrote:
               | But we're talking about neither. We're talking about a
               | conference on C.
        
               | catach wrote:
               | Seems like this particular branch is talking about the
               | suitability of using woodworking for the analogy.
        
               | EddySchauHai wrote:
               | And this is why I love HN so much haha
        
           | vitaminCPP wrote:
           | Can you share more details? This is a world I know nothing
           | about.
        
             | casion wrote:
             | Sure, here's one of the larger ones: https://handworks.co/
             | 
             | There are many which are less modernly advertised (usually
             | paper/newsgroup/email) that will draw 100+ people easily.
             | 
             | Including planned events with participants in the dozens,
             | Id say you could count at least 100 a year. I'd consider
             | that since that's the population of smaller tech
             | conferences.
        
               | arinlen wrote:
               | > _Sure, here 's one of the larger ones:
               | https://handworks.co/_
               | 
               | Not to rain on anyone's parade, but that event is about
               | hammers just as much as embedded programming is about C.
        
         | asdfasgasdgasdg wrote:
         | https://www.ulanetwork.com/calendar/association-of-wall-ceil...
         | 
         | Carpenters do have conferences. Even groups of carpenters as
         | small as those in NY apparently!
        
           | MontyCarloHall wrote:
           | Conferences about carpentry in general != conferences solely
           | about hammers.
           | 
           | There are plenty of systems programming conferences where the
           | majority of work being presented is written in C. That is
           | very different from a conference about C itself.
        
         | dc-programmer wrote:
         | I'd assume the average practitioner who attends systems
         | conferences uses C as one of their primary languages. It seems
         | like it would be redundant to have a language specific
         | conference when it would overlap so much in form and audience
         | with the systems oriented ones
        
         | ducktective wrote:
         | wow...the first comment from the last time this was posted is
         | similar to this. He even mentioned hammer.
         | 
         | https://news.ycombinator.com/item?id=18505081
         | 
         | It seems like even HN comments could be estimated by an AI.
        
           | avgcorrection wrote:
           | The HN NPC.
        
           | Uehreka wrote:
           | I remember back in 2012 or so someone made a really clever
           | karma-farming bot on Reddit. Here's how I (foggily) remember
           | it working:
           | 
           | - It subscribed to subreddits like /r/pics and /r/funny that
           | largely consisted of posting links (not text posts)
           | 
           | - When it calculated that a post was rocketing toward the
           | front page, it would look at all the past times the URL had
           | been submitted.
           | 
           | - If none of those had made it to the front page, it would
           | find the most upvoted top-level comment, copy the text
           | verbatim, and make the same comment on the post that would
           | end up on the front page.
           | 
           | For the longest time, everyone just thought that this account
           | was some super-interesting, super-funny person who always had
           | the perfect joke or perfect comment for any given situation.
           | Sure it was a bit odd that they never replied to anyone, but
           | that also just felt like part of their mystique.
           | 
           | Then someone got the receipts and outed the account as a bot
           | and the show was all over. I wouldn't be shocked to see
           | someone on HN do the same thing, but I also think HN isn't
           | big enough for a grift like that to pass by unnoticed.
        
             | ducktective wrote:
             | There was a blog post that reached first page here on HN a
             | few months ago. IIRC, only one commentator alluded that
             | "the post is so nonsensical as if it was written by GPT-3,
             | no solid arguments just mishmash of phrases"...surprise, it
             | was written by GPT-3.
             | 
             | (BTW, I'm not suggesting anyone here is a bot, obviously)
        
               | EddySchauHai wrote:
               | I used GPT-3 to generate responses to someone who argued
               | a post is GPT-3 generated on an old account. It was
               | pretty funny - it fooled them, but smaller text is
               | usually harder to detect as bot-generated.
        
           | pjc50 wrote:
           | I'd be very surprised if there wasn't at least one GPT bot
           | practicing in the comments through a series of accounts being
           | trained on upvotes.
        
           | shrimp_emoji wrote:
           | Not just HN comments.
           | 
           | We are all sets of the same memes, recurring over and over.
           | 
           | (A cool and weird experiment: try playing several shows all
           | at the same time. There'll be eerie moments when the audio
           | syncs up, or one show surreally reacts to another.)
        
             | bobthepanda wrote:
             | That just seems like the birthday paradox rather than
             | anything truly eerie: as you add more shows, the odds that
             | two won't have something going on at the same second
             | decreases.
             | 
             | (Also, ad breaks represent somewhat standard points at
             | which shows would break up programming.)
        
         | EddySchauHai wrote:
         | Even old well known tools can be optimized and reimagined; just
         | take the Plumbus and it's recently upgraded Plumbus X!
         | 
         | https://youtu.be/JGaBU5cKluU
        
         | kevinmgranger wrote:
         | There's definitely manifestos and narratives about it, but it's
         | lumped under manifestos / narratives about "simplicity" and
         | "the unix way". As for evangelicalism, you're probably right
         | about its absence.
        
         | Cupertino95014 wrote:
         | I'm SO enjoying all the comments about "yes, there _are_ saw
         | and hammer conferences. " I'll have to ask my HVAC technician
         | neighbor if he's ever been to one.
        
           | someweirdperson wrote:
           | I doubt it is a good idea to work on an HVAC with a hammer.
        
             | Cupertino95014 wrote:
             | Another pedantipoint for you. Save 'em, collect 'em, trade
             | 'em.
        
         | mhh__ wrote:
         | Saws and hammers probably aren't the best example. We complain
         | about our trusty old tools far more than I'd imagine most
         | carpenters complain about an old chisel for example.
        
       | locke3891 wrote:
       | Because it would take years to prepare for but would be run and
       | completed in seconds?
        
       | jonahx wrote:
       | I'm not the one to give it, but I'd like to see an answer based
       | on pure economics, because I think that's what drives most
       | conferences.
        
       | sylware wrote:
       | Even if I think the C syntax is already too rich, in the end, it
       | is absurdely simple compared to other abysmaly complex syntaxes,
       | like c++... yeah, probably not worth the conference.
        
         | smeyer wrote:
         | If you look at the talk schedule for something like PyCon[0],
         | not much of it is about updates to the language syntax and
         | things of that nature. Most of the time is discussing
         | applications of the language, packages, et cetera.
         | 
         | [0] https://us.pycon.org/2022/schedule/talks/
        
       | janmarsal wrote:
       | There are no low hanging fruits to talk about in such a mature
       | and well made language.
        
         | renox wrote:
         | In case you're serious: A discussion about strncpy/strlcpy.. on
         | LWN: https://lwn.net/SubscriberLink/905777/a6dba1b2ed54f04f/
        
         | defrost wrote:
         | Aside from the preprocessor and the C std library ... but
         | they're the obvious less well made bits of fruit.
        
         | PaulHoule wrote:
         | I think C puts the C in Cthulhu.
         | 
         | The C spec is a half generation behind the Common LISP spec
         | which set the standard for how you specify languages like Java
         | and Python. The K&R book is poorly organized and the language
         | contains various mistakes, such as the way the parser needs
         | access to the symbol table that deform the C++ language today.
         | 
         | It was minimal, it was viable, and it was in the right place at
         | the right time so it was available on old microcomputers, 8-bit
         | micros, MS DOS, 32/64-bit, web assembly. It competes and wins
         | against assembly code on the AVR-8 (where it boggles my mind
         | how many cycles C wastes following calling conventions in my
         | simple Arduino programs) because I can compile a C program for
         | a much better performing board.
         | 
         | So it is with us more than FORTRAN, PASCAL, COBOL, assembler,
         | etc.
        
         | Banana699 wrote:
         | What a marvel of a well made language it is, with all its well
         | made security holes and its exquisite null corruptions, truly a
         | thing of beauty.
        
           | janmarsal wrote:
           | imperfection is the key to perfection
        
       | Koshkin wrote:
       | Coming out of the third work meeting since 7AM I am starting to
       | think: Yes, we need more of those! The more the merrier!
        
       | synergy20 wrote:
       | Can someone start one? I'd love to go.
       | 
       | I used c++, golang, python, javascript over the years, even tried
       | Rust briefly. Turns out I'm most productive in C, I can get stuff
       | done the fastest way in C and one month later I can still
       | understand the code.
       | 
       | Posix C with all its libraries can do so many wonders, many of
       | the traps and pitfalls are well known, fuzzing test can further
       | secure the code, and, it's just that unbeatable-ly fast.
       | 
       | Adding a little practical OOD into C if your code base is large,
       | even with dtor|ctor|RAIIs(a bit tricky, but manageable). I call
       | this my C+ style.
        
         | WalterBright wrote:
         | > just that unbeatable-ly fast
         | 
         | Counterpoints:
         | 
         | 1. 0-terminated C strings are slow. There's the constant need
         | to scan the string to determine its length. Taking substrings
         | requires making a copy. Yes, you can manually do length
         | delineated strings in C, but there's no support for it in the
         | language, it's error-prone, and doesn't interface with anybody
         | else's C code.
         | 
         | 2. One thing I've noticed over decades of using C is that it's
         | very brittle. What that means is, once an algorithm is
         | selected, it is never changed because it's too hard to refactor
         | the code. (For example, changing a reference type to a value
         | type means changing all the -> operators to .) This means C
         | programs tend to get stuck in a local optimum of inefficient
         | data structures and algorithms.
         | 
         | 3. No array bounds checking, leading to a lot of time lost
         | debugging the #1 programming bug in shipped C programs.
         | 
         | If you're doing RAII in C, you're more than ready to move to a
         | more powerful language.
        
           | IChooseY0u wrote:
           | There is nothing stopping you from storing size of the
           | string. See: UNICODE_STRING
           | 
           | This is a silly argument.
        
           | pitched wrote:
           | I was under the impression that C strings were inherently
           | very fast because of how incredibly cache-friendly they are.
           | You should not ever have to count all the bytes (memoize
           | that!) but if you do, this is the best format there is for
           | it.
        
             | Thiez wrote:
             | What makes you say that? Besides C strings (pointer to
             | characters, null-terminated) we have Pascal strings
             | (pointer to length, followed by the characters), and then
             | there is the variant that I'm not sure what it's called,
             | that consists of a pair of (pointer, length). The last
             | variant is my favorite, an is _much_ nicer to use: you can
             | take substrings without making a copy, you never have to
             | iterate a string to find out its length, and your strings
             | _can_ contain the NULL character (which happens to be a
             | perfectly normal unicode character).
        
               | WalterBright wrote:
               | I'm not sure what it's called
               | 
               | In D we call them dynamic arrays. They could be called
               | length-delineated strings.
        
               | Thiez wrote:
               | It seems that Wikipedia refers to them as "Strings as
               | records"[1], which I suppose fits quite well. I suppose
               | that C strings _could_ be considered  "the most" cache
               | friendly since it has only 1 byte overhead instead of
               | however many bytes would be required for the length
               | (probably 4 or 8 bytes on most modern systems). That
               | said, I would be extremely surprised for this difference
               | of a few bytes per string to have a measurable
               | performance improvement in anything but an unrealistic
               | microbenchmark involving many tiny strings.
               | 
               | 1: https://en.wikipedia.org/wiki/String_(computer_science
               | )#Stri...
        
               | WalterBright wrote:
               | 0 terminated strings make sense for extremely tight
               | memory cases, like 64Kb computers, and CPUs that don't
               | cache memory. But they're a clear loser for 32 bit
               | machines.
        
               | mek6800d2 wrote:
               | VAX/VMS called them "descriptors", which had IIRC 16 bits
               | of flags, a 16-bit length, and a 32-bit pointer --
               | descriptors could be used for different object types, not
               | just strings. The 64k length limit and 32-bit address
               | were not a big issue back in 1982 when I first used them.
               | 
               | I used (Wirth's standard) Pascal in our compiler class in
               | college. String handling was actually pleasant in
               | Fortran-77 on VMS, so I figured pure Pascal had the worst
               | string handling of any language -- until I started
               | programming in C. I finally made peace with C strings,
               | but a couple of decades later, Forth said to me, "Here,
               | hold my beer." I wrote some Forth-word equivalents of
               | some of the C Library string functions to make my life a
               | little easier! :)
        
           | pipeline_peak wrote:
           | > 0-terminated C strings are slow. There's the constant need
           | to scan the string to determine its length.
           | 
           | Just record it once
        
             | WalterBright wrote:
             | Record it where? Hence lie the bugs as C doesn't offer a
             | reliable way to associate the two.
             | 
             | I made a proposal to fix this in C, but it went nowhere:
             | 
             | https://www.digitalmars.com/articles/C-biggest-mistake.html
        
               | pipeline_peak wrote:
               | Not trying to be a troll, but is this benefit anything
               | more than having to carry two variables? As in, is this
               | about getting the length without having to use str Len
               | even once?
        
               | WalterBright wrote:
               | If it's part of the type, then the compiler can
               | automatically insert bounds checks. If not, then you'll
               | have to insert the checks manually, which we both know
               | won't happen.
               | 
               | Another trouble with two variables is there's no obvious
               | connection between them. One can be modified without the
               | other, etc.
        
               | nomel wrote:
               | Obviously, a struct is one option. The problem is that
               | you then need to make a whole string library. Thankfully,
               | many exist, so this is a non issue, unless there's a
               | requirement that you write all the code yourself.
        
           | synergy20 wrote:
           | All good points, which are part of the reasons I used other
           | languages, but I'm back to C after weighing in those pros and
           | cons.
           | 
           | There is no perfect language, C just seems the best for me to
           | get job done.
        
             | WalterBright wrote:
             | As long as one understands the tradeoffs, no problem.
        
         | pipeline_peak wrote:
         | C forces you to either reinvent the wheel or use third part
         | libraries. While that's fun and all, I wouldn't say it makes
         | you more productive. How is that any better than using C++ with
         | its STL?
        
           | edgyquant wrote:
           | The best libraries win out where with C++ you have a huge
           | stdlib but are stuck with it
        
         | didip wrote:
         | Even compared to Golang where you can download a bunch of
         | modules without writing it yourself?
        
           | synergy20 wrote:
           | so far finding well-established c 'modules'(libraries, e.g.
           | glibc, musl, openssl, curl,etc) has not been a problem for
           | me, there are probably more good quality c 'modules' than
           | other languages, they're just not put together with some
           | package manager like go|rust provide.
           | 
           | conan(or even the light weight tool called clib) could be of
           | help but I have not tried them, as I don't feel the need yet.
        
         | jstimpfle wrote:
         | I feel the same. I'm tired of languages, can't even muster the
         | energy anymore to give Rust a serious try - although I'm
         | considering I'll have to do it in the future anyway, given that
         | the hype hasn't ebbed away.
         | 
         | To me, C is almost entirely a non-language. It's a culture
         | where you focus on what you want the computer to do (and
         | optimize that), instead of optimizing what you write (and
         | ending up with something convoluted that will be hard to read
         | in 1 month).
         | 
         | I refuse to do things that many don't even give a second
         | thought - such as, do I really need to implement the Into<T>
         | trait and use x.into() to do a conversion? Isn't it better if I
         | just write the function that I'm using explicitly? That way it
         | will be easier to see what function is used, and the likelyhood
         | that I'll have to change that code later I deem comparatively
         | small.
         | 
         | C has its flaws but I know them quite well by know and have
         | learned to walk around them. And it has some "flaws" that are
         | misunderstood strengths to a degree.
         | 
         | More and more "humble" languages have been started in the
         | recent years, but there is little incentive for me to try and
         | switch. And even of those, almost all add some clever things
         | that I'm nervous might be _too_ clever.
        
           | ilovecaching wrote:
           | Language fatigue and settling on C seems to be a thing, as
           | I've encountered several people with the same opinion. I
           | wonder what the physiology is behind it.
           | 
           | For me, C is the lingua franca. With C I can read kernel
           | source, I can read systemd source, I can read firmware, boot
           | loader, etc. I want to specialize in the language that gets
           | me the most bang for my buck. Rust is a compelling future,
           | but it's still the future and not the present, and the
           | present doesn't seem to be going anywhere fast.
        
             | jstimpfle wrote:
             | I tried Rust very briefly, a couple times building some
             | random projects. Each would download and build around 500
             | (!) dependencies. A few of them failed to build on my
             | machine.
             | 
             | Another time I decided to try and get OpenGL running on
             | Win32 with Rust in an evening. I failed to find a
             | satisfying way (free of boilerplate and magic incantations)
             | to do it. Probably interfacing with the system isn't that
             | easy and/or you're supposed to use specific wrapper crates.
             | Don't remember the details anymore, but it's definitely
             | true that existing infrastructure has a lot of inertia.
             | What Zig is doing in that space is a smart move - it has a
             | C compiler built in, and if I understand correctly it lets
             | you interface with C system headers pretty seamlessly.
        
           | nivenkos wrote:
           | I'd rather lose an hour to dealing with the borrow checker
           | and type safe design than spend weeks debugging an
           | intermittent segfault.
        
             | jstimpfle wrote:
             | Me too (of course), but the last time I had a segfault that
             | took me longer to fix than at most a couple minutes must
             | have been years ago. The last time I got a segfault at all
             | is probably months ago.
             | 
             | It's a matter of the more global design - factoring out the
             | nitty-gritty things in some central places removes many
             | bugs without you having to think about it. A lot of "usage"
             | code then looks very simple, almost python-like. Variables
             | and function calls. A few ifs and elses, a little bit of
             | arithmetic.
             | 
             | Look at the Linux kernel for example. It is superficially
             | not pretty, but you have to walk around quite a bit for
             | example to see explicit locks and unlocks. It's a matter of
             | factoring out the hard stuff in central places. This is a
             | skill that is totally unrelated to the language you're
             | using.
             | 
             | Yes, bugs happen to everyone, and more so in C than some
             | other languages. Yes, there are security problems that come
             | from lack of memory safety. But simply in terms of
             | productivity, I feel that C is a very good tradeoff for me.
        
           | pizza234 wrote:
           | I've worked on porting a program written in C to a memory-
           | safe language.
           | 
           | On the very first run of the port, immediately, I've found a
           | bug due to C weak typing. After a few days, I've found a few
           | buffer overruns.
           | 
           | My take is that there are two types of programmers: those who
           | admit they can't avoid making memory safety mistakes, and
           | real programmers, who don't make such mistakes, and happily
           | keep programming in C/++.
           | 
           | EDIT: Just for fun, I've randomly picked up another C
           | program, written in C17/C18. Immediately found a bunch of
           | problems (not sure if there is any impactful, or not),
           | including inconsistent function prototypes.
        
             | jstimpfle wrote:
             | Mind sharing what is the project that you picked?
        
             | copperx wrote:
             | > My take is that there are two types of programmers: those
             | who admit they can't avoid making memory safety mistakes,
             | and real programmers, who don't make such mistakes, and
             | happily keep programming in C/++.
             | 
             | I absolutely agree. There's a class of programmers that
             | would rarely if ever make such mistakes (e.g., Torvalds),
             | and to them, C is freeing.
             | 
             | For the rest of us lesser programmers, the handrails of a
             | borrow checker are necessary.
        
           | at_compile_time wrote:
           | >do I really need to implement the Into<T> trait and use
           | x.into() to do a conversion? Isn't it better if I just write
           | the function that I'm using explicitly?
           | 
           | Firstly, you would implement From rather than Into. Into is
           | blanket-derived for From. So if B implements From<A>, then A
           | also implements Into<B>.
           | 
           | And no, you don't have to do this. If the function is never
           | going to be generic, there's no sense in writing it that way.
           | Solve the problem at hand, you can always go back and add
           | abstraction later.
           | 
           | I really like Rust. I hear people say that it's hard, but I
           | don't think it's harder than the problems it solves.
        
           | outworlder wrote:
           | > I feel the same. I'm tired of languages, can't even muster
           | the energy anymore to give Rust a serious try - although I'm
           | considering I'll have to do it in the future anyway, given
           | that the hype hasn't ebbed away.
           | 
           | At this point, it probably won't die out. The time to die was
           | in the beginning, when they set to do overly ambitious things
           | that had a high chance of not working. People have been
           | wanting what it offers for quite a long time.
        
             | EddySchauHai wrote:
             | I want to work on boring languages that let me focus on
             | domains, not tools, and even so I work with Rust and have
             | done in my last 3 or 4 roles. If you do systems programming
             | in a startup, Rust will be there.
        
           | api wrote:
           | > can't even muster the energy anymore to give Rust a serious
           | try - although I'm considering I'll have to do it in the
           | future anyway, given that the hype hasn't ebbed away.
           | 
           | I'm in the same boat. I've been in this industry for a long
           | time and generally good at spotting hype. I try to avoid the
           | endless wheel reinvention that goes on.
           | 
           | That being said... I hate to be the Rust evangelism strike
           | force, but give it a try. The hype is not ebbing away because
           | there's substance there.
           | 
           | IMHO it's the first real alternative to C and C++ that brings
           | a beneficial paradigm shift without sacrificing performance
           | or the ability to code close to the metal. You can write
           | systems code that is provably safe in terms of catastrophic
           | memory errors and is orders of magnitude less likely to have
           | threading bugs. (It's still possible to leak memory or have a
           | deadlock, but it's harder to do and easier to diagnose. More
           | importantly neither of these errors are likely to lead to
           | catastrophic security vulnerabilities.)
           | 
           | As with C there is definitely a learning curve. New C
           | programmers get crashes all over the place until they get it.
           | New Rust programmers get beat up by the borrow checker and
           | other type system stuff until they get it. Luckily they've
           | put a massive amount of work into making the compiler's
           | errors comprehensible.
           | 
           | After getting good with Rust I am now more productive in it
           | than C and C++. It's the first attempt at a C replacement I
           | can say that about, and I've tried a few. The only other
           | languages that are more productive than C are higher level
           | languages with fat runtimes not "close to the metal"
           | languages.
           | 
           | Edit: the part of Rust that garners the most complaints is
           | async, and I'm still a bit on the fence about it. It's usable
           | but needs work in the standard library to solve the "async
           | runtime lock-in" and dependency hell problems. Also needs
           | some better libraries in general. Most of the issues with
           | async are in the libraries (or lack thereof) not the
           | language. It was a mistake not to have the async runtime in
           | "std."
           | 
           | But honestly the fact that you can do async this way safely
           | in a bare metal language is impressive, and the only way to
           | do that much better is fibers (a.k.a. coroutines, go-
           | routines) and that generally requires a fat runtime. Go just
           | compiles a fat runtime into all your binaries to get
           | goroutines.
        
       | effnorwood wrote:
        
       | sparcpile wrote:
       | There is no money in a C/C++ Conference. Conferences are held so
       | that the organizers can make a profit from tickets and booth
       | fees.
        
         | Mimmy wrote:
         | C++ at least has their flagship CppCon no?
        
           | sparcpile wrote:
           | Yes, C++ has CppCon, so that conference is making money for
           | the organizers.
        
             | boris wrote:
             | CppCon is organized by the Standard C++ Foundation (and a
             | ton of volunteers), which is a non-profit organization.
             | When I was involved quite a few years ago, I believe they
             | were making a modest "profit" on the conference which I am
             | pretty sure was all wiped out during COVID due to the hotel
             | commitments they enter into.
        
           | pjc50 wrote:
           | The C++ conference has .. problems.
           | https://twitter.com/pati_gallardo/status/1560539777300037632
        
         | yreg wrote:
         | Not necessarily, companies sometimes organize a conference at
         | break-even (or at a loss) with motivation to build a name,
         | attract clients, for hiring, etc.
        
         | IshKebab wrote:
         | There are plenty of C++ conferences though.
        
       | jeffrallen wrote:
       | C programmers are anti-social. :)
        
       | Cupertino95014 wrote:
       | > Second, C has a tendency to be conservative, changing and
       | growing very slowly. This is a feature.
       | 
       | That's it. I can pick up K&R and still be writing useful programs
       | in a very short time.
       | 
       | Of course, in a lot of shops there are libraries that you have to
       | use other than the standard one. I can imagine a conference about
       | _those_. A boring conference.
        
       | rr808 wrote:
       | I haven't been to a conference in 10 years now. Online talks seem
       | much more convenient. Are in person conferences back after covid?
        
       | rffn wrote:
       | The Embedded Systems conference used to be a C conference to some
       | extend.
        
       | vitaminCPP wrote:
       | While the title may say otherwise, the article is worth a read
       | just for the talks recommandation.
        
       ___________________________________________________________________
       (page generated 2022-08-26 23:01 UTC)