Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I stopped everything and started writing C again

kmx.io

Post reply on HN
Print view View original

451–460 of 475 posts

Re: I stopped everything and started writing C again

#451

Post by jpc0 »

mrheosuper wrote: post #304
jpc0 wrote: post #295

Earlier quoted context omitted.

What is your current language of choice, both C and C++ have the same problems as what you just described. Regarding ownership transfer it is even worse in C, what if you forget, after moving an object out of a variable, to set that variable to NULL, then free that variable, that's a use after free. At least in C++ you have move semantics although it is still error prone. In rust it's a compiler error. Copy and Clone…

Well, i dont use C++ much(i'm FW engineer, most of my stuff is in C). The std in C is simple and explicit. For Ex: I can make an educated guess how memcpy() work by looking at its signature. It takes pointer to src and destination, and size, so i can guess it does not allocate any new memory(or if it has, it has to be some kind of optimization reason). Another example is strstr(), it returns pointer to a piece of mem…

> It takes pointer to src and destination, and size, so i can guess it does not allocate any new memory

Does the pointer provided by src get altered in any way? Might is be NULL after calling memcpy? What happens if I pass NULL to dst? Is size in bytes or whatever the pointer is pointing to?

The moment you need to read a man page to get any of those mab pages you can read the docs for clone and get all the information you would need.

> Another example is strstr(), it returns pointer to a piece of memory i provided to it

This is not at all clear from the signature, from the signature it might allocate and return a new string entirely that you would need the deallocate, the only way to know that is to read the docs which runs into the problem again.

And again there is no indications that the pointers passed into the function are not mutated in any way other than convention and documentation.

Rust makes all of these things explicit with a compile error if you fail an invariant of the type systems.

Btw it's possible to encode the same invariants in C++ but isn't the default most of the time.

Re: I stopped everything and started writing C again

#452

Post by 59nadir »

kokada wrote: post #109
irq-1 wrote: post #105

Earlier quoted context omitted.

Odin has this too: > Odin is a manual memory management based language. This means that Odin programmers must manage their own memory, allocations, and tracking. To aid with memory management, Odin has huge support for custom allocators, especially through the implicit context system. https://odin-lang.org/docs/overview/#implicit-context-system

Interesting that I was thinking of a language that combined Zig and Scala to allocate memory using implicits and this looks exactly what I was thinking. Not that I actually think this is a good idea (I think the explicitly style of Zig is better), but it is an idea nonetheless.

A lot of our Odin procs take an allocator as a required argument specifically so they force you to choose one at the call site, because yes, often you want it to be explicit.

Re: I stopped everything and started writing C again

#453

Post by zelphirkalt »

ohgr wrote: post #188
kelnos wrote: post #146

Earlier quoted context omitted.

> I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. When I say Rust is harder to use (even after learning it decently well), what I mean is that it's still easier to write a pile of C code and get it to compile than it is to write a pile of Rust code…

I’d add that the Rust code and C code will probably have the same number of bugs. The C code will likely have some vulnerabilities on top of those. Rust doesn’t magically make the vast majority of bugs go away. Most of bugs are entirely portable!

Only about 70% of high severity bugs[1]. Quite a negligible amount.

[1]: https://www.chromium.org/Home/chromium-security/memory-safet...

Re: I stopped everything and started writing C again

#454

Post by zelphirkalt »

bsenftner wrote: post #35
lqet wrote: post #11

I fully understand that sentiment. For several years now, I have also felt the strong urge to develop something in pure C. My main language is C++, but I have noticed over and over again that I really enjoy using the old C libraries - the interfaces are just so simple and basic, there is no fluff. When I develop methods in pure C, I always enjoy that I can concentrate 100% on algorithmic aspects instead of architectu…

About 16 years ago I started working with a tech company that used "C++ as C", meaning they used a C++ compiler but wrote pretty much everything in C, with the exception of using classes, but more like Python data classes, with no polymorphism or inheritance, only composition. Their classes were not to hide, but to encapsulate. Over time, some C++ features were allowed, like lambdas, but in general we wrote data clas…

This however, is an implementation strategy, that most business/"enterprise" developers will fight to the teeth, because they believe, that OOP is the only workable way to create abstractions and that any successful project must have inheritance in it. They never learned another way.

Actually Rust goes a long way towards a similar strategy, by avoiding inheritance and instead relying on structs and traits. That already avoids a lot of BS programming. I am very glad they threw out inheritance and classes. Great design decision right there. I wish FP was made more convenient/possible in Rust though.

Re: I stopped everything and started writing C again

#455

Post by swiftcoder »

pabs3 wrote: post #350
swiftcoder wrote: post #314

Earlier quoted context omitted.

> it isn't safe to use on code you haven't written yourself Neither is cargo (nor npm, nor any other package manager, for that matter). I'm not sure what value being that paranoid is buying you in the long run.

Package managers are for running other people's code, I would not expect the same of static analysis tools, especially since they are of use while auditing other people's code before building/running it.

Cargo's threat model here is identical to that of rust analyser. If you trust your dependency tree sufficiently to run `cargo build`, then you trust it sufficiently to run rust analyser.

Re: I stopped everything and started writing C again

#456

Post by kokada »

59nadir wrote: post #452
kokada wrote: post #109

Earlier quoted context omitted.

Interesting that I was thinking of a language that combined Zig and Scala to allocate memory using implicits and this looks exactly what I was thinking. Not that I actually think this is a good idea (I think the explicitly style of Zig is better), but it is an idea nonetheless.

A lot of our Odin procs take an allocator as a required argument specifically so they force you to choose one at the call site, because yes, often you want it to be explicit.

I am thinking now a language that had the default allocator be a GC, but you could change it to something else using implicits/context and this is enfoced everywhere (e.g.: there is no way to allocate memory "from magic", you need to call the allocator, even if it is from context).

At least thinking in Scala as a base syntax here, it would mean:

    def foo(name: String)(implicit allocator: MemoryAllocator): StringBuf = {
      val buf = allocator.new(100, String)
      buf.append("Hello ")
      buf.append(name)
      buf
    }

    println(foo("John")) // implicit allocator from context, default to GC, no need to free

    implicit val allocator: MemoryAllocator = allocators.NewAllocator()
    println(foo("Alice")) // another implicit allocator, but now using the manual allocator instead of GC
    defer allocator.free()

    val explicitAllocator = allocators.NewArenaAllocator()
    foo("Marie")(explicitAllocator) // explicit allocator only for this call
    defer explicitAllocator.free()
I don't think there is any language right now that has this focus, since Odin seems to be focused in manual allocations.

Re: I stopped everything and started writing C again

#457

Post by chaotic-good »

crabbone wrote: post #177
kstrauser wrote: post #144

Earlier quoted context omitted.

I think Rust is harder to learn , but once you grok it, I don't think it's harder to use , or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. Rust's normal error messages are delightfully helpful. For example, I just wrote some bad code and got: --> src/main.rs:45:34 | 45 | actions.append(&mut func(opt.selected)); | ---- ^^^^^^^^^^^^ expe…

* Rust errors can be equally unhelpful. Also, the error you posted is hands down awful. It doesn't tell you what went wrong, and it's excessively naive to rely on compiler to offer a correct fix in all but the most trivial cases. When errors happen, it's a consequence of an impasse, a logical contradiction: two mutually exclusive arguments have been made: a file was assumed to exist, but was also assumed not to exist…

I tend to agree with this.

The code tend to be loaded with primitives that express ownership semantics or error handling. Every time something changes (for instance, you want not just read but also modify values referenced by the iterator) you have to change code in many places (you will have to invoke 'as_mut' explicitly even if you're accessing your iterator through mutable ref). This could be attributed (partially) to the lack of function overload. People believe that overload is often abused so it shouldn't be present in the "modern" language. But in languages like C++ overload also helps with const correctness and move semantics. In C++ I don't have to invoke 'as_mut' to modify value referenced by the non-const iterator because dereferencing operator has const and non-const overloads.

Async Rust is on another level of complexity compared to anything I used. The lifetimes are often necessary and everything is warpped into mutliple layers, everything is Arc>>.

Re: I stopped everything and started writing C again

#458

Post by jacksnipe »

shakna wrote: post #213
jacksnipe wrote: post #208

Earlier quoted context omitted.

Since it's underlining code you wrote, it must be "found" that is highlighted, not "expected". Much like up and down, gravity exists to ground all of us in the same direction.

I'm over here with TTS: Underlining in a terminal rarely translates to audio. It isn't the only consideration that needs to be made, when making things clear.

I hadn’t considered this use case, thank you for pointing it out!

Re: I stopped everything and started writing C again

#459

Post by igouy »

nindalf wrote: post #417
igouy wrote: post #413

Earlier quoted context omitted.

> And sure, it’s possible … Because anecdote. We can only know when the thing is designed as an experiment. (All credit to who-so-ever is working to write improved versions.)

> Because anecdote I don’t think anyone could have said something more rude or ignorant if they tried. > designed as an experiment Ha. As if you could design such an experiment. What, you’ll place two rats at a keyboard and ask them to implement grep? Bffr. I’m pointing out the obvious - no one has actually written these mythical C programs that outperform Rust, to say nothing about security and reliability. You’ve d…

The quoted text seems dictionary definition anecdote.

Re: I stopped everything and started writing C again

#460

Post by usamoi »

WalterBright wrote: post #199
kelnos wrote: post #127

I'm kinda in the opposite camp. After doing a bunch of VB in my tweens and teens, I learned Java, C, and C++ in college, settling on mostly C for personal and professional projects. I became a core developer of Xfce and worked on that for 5 years. Then I moved into backend development, where I was doing all Java, Scala, and Python. It was... dare I say... easy! Sure, these kinds of languages bring with them other pro…

> Memory leaks, NULL pointer dereferences, use-after-free I suffered writing those for many years. I finally simply learned not to do them anymore. Sort of like there's a grain of sand on the bottom of my foot and the skin just sort of entombed it in a callous.

This is actually quite easy to achieve, as long as you cannot realize your own mistakes.
Post reply on HN