Hacker News: SilentLambda

New comment by SilentLambda in "CobaltC – The Successor to C?"

SilentLambda — Mon, 31 Aug 2026 05:14:31 +0000

Yes, but remember is the last appendix to a book, and book provides the context for this appendix. So yes, in that sense, it's just another one attempting to address the memory-safety issues of C. At least this one uses C like syntax and doesn't require C programmers to learn some alien syntax. Of course, this is just a spec, Rust is well and truly live in the environment. The book is more interesting than the spec.

CobaltC – The Successor to C?

SilentLambda — Mon, 31 Aug 2026 02:26:09 +0000

Article URL: https://strawberry9.github.io/the-wrong-memory/Appendix_06.html

Comments URL: https://news.ycombinator.com/item?id=49504922

Points: 13

# Comments: 19

A theory for decades of C vulnerabilities

SilentLambda — Mon, 17 Aug 2026 10:32:21 +0000

Article URL: https://strawberry9.github.io/the-wrong-memory/Appendix_02.html

Comments URL: https://news.ycombinator.com/item?id=49328812

Points: 36

# Comments: 21

OpenD has private(this), so why won't D even consider it?

SilentLambda — Fri, 04 Jul 2025 10:29:42 +0000

Article URL: https://lists.puremagic.com/pipermail/dip.ideas/2025-July/001538.html

Comments URL: https://news.ycombinator.com/item?id=44463218

Points: 2

# Comments: 0

New comment by SilentLambda in "[dead]"

SilentLambda — Sun, 01 Jun 2025 01:34:56 +0000

alert, inform, notify, announce ..... that's what HN does.

How about refocusing your attention on the actual matter at hand.

That is, Linus calling out Kees for being actively malicous.

Personally, I would have contacted Konstantin privately to lock (at least temporarily) Kees account. Then I would have sought an explanation from Kees (on the mailing list), and waited for his response. And I would have done this before calling him out as being guilty of active maliciousness.

Of course Linus love drama (especially drama that he creates.).

New comment by SilentLambda in "[dead]"

SilentLambda — Sun, 01 Jun 2025 00:15:53 +0000

I think the HN title was completely appropriate.

Linus was not jusy yelling - (i.e.): "You seem to have actively maliciously modified your tree completely." - Linus Torvalds.

Linus didn't even use the word 'potentially' - yet the HN title did.

So get off the back of the person who created the HN alert!

New comment by SilentLambda in "OpenD Merges Private(this)"

SilentLambda — Mon, 05 Feb 2024 21:38:51 +0000

openD (a fork of the D programming language) makes class private members inside a module a reality for programmers. In the meantime, the D programming lanaguage forum bans any further discussion of private(this).

OpenD Merges Private(this)

SilentLambda — Mon, 05 Feb 2024 21:38:50 +0000

Article URL: https://forum.dlang.org/post/jiarvufaqppihpvvbbgh@forum.dlang.org

Comments URL: https://news.ycombinator.com/item?id=39267599

Points: 2

# Comments: 1

New comment by SilentLambda in "Futuer of the D Programming Language depends on finding the elusive self"

SilentLambda — Tue, 23 May 2023 09:10:17 +0000

Members of the D programming language spend 14 weeks searching for the elusive 'self'. Did they all find it though? And what about the 'non-self'? Did they go looking for that as well?

Futuer of the D Programming Language depends on finding the elusive self

SilentLambda — Tue, 23 May 2023 09:10:17 +0000

Article URL: https://digitalmars.com/d/archives/digitalmars/D/D_Language_Foundation_Weekly_Planning_Session_Update_368740.html

Comments URL: https://news.ycombinator.com/item?id=36041761

Points: 2

# Comments: 1

New comment by SilentLambda in "Encapsulation – Where is the perimeter of a class type?"

SilentLambda — Sat, 26 Nov 2022 23:44:00 +0000

This D programming blog argues that C++ friend breaks encapsulation. I reject that argument, and say that C++ friend puts a door in the wall, and a guard at that door, and therefore encpasulation both remains, but is also extended (in the same way entangled particles are both encapsulated in themselves, but also in their encapsulated partner particle(s).

The article also argues that D's approach to allowing all code within a D module to be within the perimeter of any class type within that module, at all times, enhances encapsulation. I propose, that such an approach can only break encapsulation of a class type, and that it cannot possibly enhance it.

Encapsulation – Where is the perimeter of a class type?

SilentLambda — Sat, 26 Nov 2022 23:43:59 +0000

Article URL: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

Comments URL: https://news.ycombinator.com/item?id=33758222

Points: 1

# Comments: 1

New comment by SilentLambda in "Porting 58k lines of D and C++ to Jai"

SilentLambda — Sat, 26 Nov 2022 23:29:15 +0000

..and in the context of a module.. not even used as a type at all.

New comment by SilentLambda in "Porting 58k lines of D and C++ to Jai"

SilentLambda — Thu, 24 Nov 2022 09:47:58 +0000

Would have been much better in my opinion, if D had maintained a C like struct (not a C++ like struct), and a C++ like class. That would have solved the problem you identified, while still allowing for the class to be what it was designed to be. The mistake C++ made was the mistake you identified. But the solution you provided in D is its own mistake.

New comment by SilentLambda in "Porting 58k lines of D and C++ to Jai"

SilentLambda — Thu, 24 Nov 2022 04:39:35 +0000

Yes, we can agree that D is not like C++ - not at all.

The reason C++ programmers are usually disappointed, is because D gets marketed as such (it's the bait you need to get them to look at D afterall).

In fact, even on the basic class type, C++ and D are really miles apart. Make no mistake about this - they are miles apart, even on this one construct (the same contruct for there being a C++ in the first place).

It is clear when you use D, that it wasn't designed to be like C++.

D does have a subset that is C like, and that's primarly because it is, in essence, C.

So D is D.

D is not at all like C++.

A subset of D is like C (cause it is - more or less - C).

New comment by SilentLambda in "Porting 58k lines of D and C++ to Jai"

SilentLambda — Thu, 24 Nov 2022 04:29:30 +0000

D is not at all like C++.

D is D.

You only need to compare how C++ and D treat a class type, and you know straight away they are miles apart (I prefer C++ in this regard).

D has a subset, and that subset is more like C - pretty much cause that subset is C. That can be interesting to use, since it's like C with modules.

But don't be fooled. D is not like C++.

I wish people would stop saying as such, cause it's not at all true.

New comment by SilentLambda in "Porting 58k lines of D and C++ to Jai"

SilentLambda — Thu, 24 Nov 2022 04:17:37 +0000

.. you forgot to mention also, that (in the context of a D module) D stops treating a user-defined class-type as real type. Additionally, a D class is a reference type. Whereas in C++, a class type is a real type (treated as any built-in type), and is a value type (by default).

Nor does D have a concept of C++ friend.

So even when it comes to classes, C++ and D are miles apart.

New comment by SilentLambda in "Porting 58k lines of D and C++ to Jai"

SilentLambda — Thu, 24 Nov 2022 04:06:26 +0000

"That said, D definitely has some advantages over C++, like more powerful metaprogramming, no need for headers, no uninitialized values and more. But unfortunately, these upsides are outweighed by the downsides."

Yes, after working with D for far too long, I have decided to delete it off my computer and I'm going back to C++, where a class is still a first-class 'type', and a 'value' type at that (at least by default).

In D, a class is a reference type only and worse, the D language has no means of declaring, let alone enforcing at compile time, a perimeter around such a type, within the so called 'D module'. The entire D module is within the perimeter of your class type, at all times!