chrsig

stx::backtrace looks quite nice.

The documentation seems nice as well...except I can't seem to find a link to the code itself. I have to believe it's right in front of me and I'm just not seeing it.

Slackware was my first distribution! One of my sister's friends came over and installed some 7.x release and left me on my own to configure xfree86.

Needless to say, for my first time using linux, it didn't work out. But a short time later I was dual booting mandrake & slackware 8.1. Ahhh...the sweet nostalgia of gnome 1.4.

Youngin's these days don't have any challenge left. Now where's my cloud to yell at? And why are you on my lawn?!

I have a hard time recommending the book. The main character had no agency for most of it, and the plot was very unclear. It made for a good unveiling at the end, but given the size of the book...it's a lot to read for that payoff.

I won't say don't read it -- it did manage to keep my interest, after all -- I just have a hard time recommending it due to the time-investment:reward ratio.

Yes, on review, I should have made two examples instead of combining them. Thanks for persevering through my brevity and reaching understanding :)

> I'm not sure Russ's personal blog is any kind of official statement "this is what we're doing" yet?

I've found it's generally a very strong indicator.

But to your point, this isn't a new issue, there's been a good amount of discussion around it over the years.

Coroutines are one thing that i'd probably prefer language support for rather than a library.

    x := co func(){
        var z int
        for {
            z++
            yield z
        }
    }

    y := x()

    for y := range x {
        ...
    }

or something to that effect. It's cool that it can be done at all in pure go, and I can see the appeal of having a standard library package for it with an optimized runtime instead of complecting the language specification. After all, if it's possible to do in pure go, then other implementations can be quickly bootstrapped.

My $0.02, as someone that uses go at $work daily: I'd be happy to have either, but I'd prefer it baked into the language. Go's concurrency primitives have always been a strength, just lean into it.

> How long do you spend on the HN front page?

...more time than it takes to load. much, much more time.

Generics!

    func streamingApply[T any](ch channel[T], fn func(T)){ 
         for {
            select {
            case <-ctx.Done():
            break
            case item, ok = <-ch:
                if !ok {
                    break
                }
                fn(item)
            }
        }
    }

For everyone that's complained about generics being introduced to go...It really does help clean up this type of repetition.

My electric furnace needed to be urgently replaced in the beginning of the winter, I'm quite happy that my new heat pump would default to heat...Half of the year :)

This was exactly my take on it.

I'd recently been reading a bit more about zig, and even tried out using it as an easy way to compile c++ with llvm without having to fuss with system packages -- transitioning from c/c++ to zig was a major selling point

It just seems really abrupt, certainly unexpected. I'm not saying it's the right/wrong thing for the project -- just really really out of left field from my point of view

I've never personaly seen any benefit from exponential backoff... constant backoff + jitters + short timeouts has always worked well for me.

If anything, people underestimating the ramp up of exponential back off(or not capping it) has left me waiting much longer than necessary

Some thoughts:

- The general point is correct -- time is not a synchronization mechanism

- Flakey tests are bad for all the reasons listed

- Shoddy synchronization makes for flakey tests

The example chosen -- waiting for a test server to be available is probably a huge source of the issues. However, I don't think the example -- really demonstrates how to do synchronization.

My core objection is that it's really relying on the operating system to take care of the synchronization, and that winds up hiding it entirely:

- the dial will not happen until the operating system has competed the `listen` call

- the operating system is selecting a random port at the time of the `listen` call, and reports the chosen port to the user

This is the correct way to approach this problem, but it doesn't really show a proper synchronization. It shows the operating system synchronizing on behalf of the program. It's also an example that probably only shows up in test -- client and server in the same process space.

In practice, many clients and servers may start at the same time in different processes or on different hosts, meaning that the client has no signal at all that the server has become ready. The best thing that can really be done is quickly polling with low timeouts until the server reports healthy.

I'd have liked to see use of a `sync.Cond`, or channel to signal that the operation has completed, and the waiting goroutine being safe to continue. It wouldn't fit well in this example, because, well, the operating system provides those facilities.

Over, because it does come up a lot with the example used, I'm happy there is a blog posts addresses it. Hopefully I'll see less of the problem in the world. I suppose I hope the author writes a part 2, showing other ways sleeps creep in and how to remove them.

>Is math going to become more important for software engineers in general, as AI is adopted in to more and more aspects of the SDLC, even if said engineers aren't working directly on the AI systems themselves?

I'm definitely not any authority on the matter -- also self taught, but I don't think so.

Having a conceptual understanding of the math is probably a really good idea, but I imagine there's quite a bit that can be hidden behind an api that you can essentially say "does xyz by means of magic".

I imagine this winds up creating three distinct roles: - Focusing on improving the model's usefulness - Focusing on implementing the model for optimal performance - Focusing on using the model within a larger application

I say "creating", but I imagine this is also probably roughly the current status quo.

I have mixed feelings about it. if nothing else, the name..."slog" isn't exactly the word i want repeating to myself as I'm working.

I mean, just to push one onto the stack...

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

> Please don't post comments saying that HN is turning into Reddit. It's a semi-noob illusion, as old as the hills.

> Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.

I think the c++ community needs to get past the idea that people learning it are coming at it from a "c with classes!" perspective.

It's going to transition to "python with static types", "rust without a borrow checker", "java with manual memory management", etc.

I don't think that as time progresses the newcomer pipeline is going to be largely represented by people coming from C.

The curve described is what it's like to pick up any language after being proficient with another though -- nothing specific to c++. c++ is just larger and more sprawling with more footguns and other things to make you suffer.

Find similarity, be comfortable enough to be productive, gain experience and realize mistakes, get frustrated, either walk away or accept the language and ecosystem as it is and learn how to work within it.

> These days I don't write much C++ code (regressed to largely C), and when someone asks me how proficient I place myself at a 4 out of 10, and then explain how the spec has changed faster than I think most people can actually absorb it unless its their full time job to sit on the standards committee. So I don't believe anyone who gives a themselves a score over 6 unless their job actually required a deep level of standards understanding (ex: compiler developers).

I generally factor in a ~5 year adoption period for newer standards as not only compiler adoption completes, but as distributions pick up newer compiler versions and make them the default.

So right now, I'd consider c++17 the expected standard for people to generally be comfortable and competent with.

> assuming your request for more context comes out of a sincere desire to increase your understanding, I hope this helped.

I appreciate the benefit of the doubt -- I was trying to approach it with the assumption that there's probably some perspective that I wasn't aware of.

> sneak wanted OP to be less openly queer in their personal blog for their own comfort

I can see how it may be interpreted that way. To me it read more like "hey, great content, presentation of it wasn't for me" in a way to convey feedback in the event the author wanted to better capture their attention. I didn't get the sense that there was an expectation that the author change their writing style to accommodate their preferences.

re-reading this, I don't think I appreciated that it was really in defense of the readers rather than the content

> I also ask you to be more considerate and respectful of other readers who may enjoy my work

I'm surmising that the real problem statement is:

> I'm sure there are non-sexual furries but the subculture is primarily a sexual one (same as with BDSM)

which I can appreciate as a generalization, I suppose I wouldn't have personally considered furries as under the queer umbrella, but I'm certainly no voice of authority on the matter. I suppose there's also the possibility that 'furries' was a dog whistle for 'queer', and being less charitable to sneak, I could better understand finding disrespect in the post.

> I is not obligated to cater to your personal tastes or opinions, especially when I am providing my content to the world for free.

I don't believe OP asserted anything to the contrary, could you highlight where you inferred that?

> I appreciate your feedback, but I also ask you to be more considerate and respectful of other readers who may enjoy my work.

It would be helpful if you would be willing to expand on how you found the OPs statements disrespectful or inconsiderate.

> More realistically, Linux had driven them into near irrelevance in the server market and just pushed them from "extinguish" or "extend" to "embrace".

and with vscode, copilot, and wsl2 they're doing a terrifyingly good job :-/

I really hope people don't let their guard down.

> Never trust a 3rd party to do your crypto.

This strikes me as funny because software engineers are regularly told not to roll their own crypto.

is assign(x, plus(a, b, c, d)) not an option?

I think for the problem space zig is trying to fit in, it's pretty essential to have custom allocator support thoroughly baked in.

It's the sort of thing that lets a data structure be used on both a gpu and cpu, allocation out of shared memory, or ensure that no dynamic allocations are happening at all.

Most programs don't have those concerns - so zig may not be the best choice for them. For the programs that do have those concerns, forethought about allocators is pretty important. Right tool for the job, and all that.

> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list.

Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving.

> It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0

In order to get into production? yes. there are minimum requirements that must be met. those are higher now than in the past, because of lessons learned the hard way. those problems have been solved (for some value of solved) in existing ecosystems -- a new language wont change the need for them to be solved.

it shatters the dream of hacking up something on a weekend and having it turn into a hit success, but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years.

Until they have what you mentioned, the languages aren't ready for large scale use -- they need to grow into it. They can be useful prior to that -- enthusiasts and early adopters can reap what benefits are provided. That adoption is what fuels the development of things like a standard code formatter.

edit: fixed omission of a unit of time after '30'

I'd look towards stratified sampling to think more formally around the issue.

POC is homogonizing because it's reducing the space from N strata to 2: white and non-white, blending n-1 strata.

Per wikipedia:

> Stratification is the process of dividing members of the population into homogeneous subgroups before sampling. The strata should define a partition of the population. That is, it should be collectively exhaustive and mutually exclusive: every element in the population must be assigned to one and only one stratum. Then simple random sampling is applied within each stratum

Using this definition, white and non-white are mutually exclusive, while location of origin forms a different axis for comparison.

In more social sciences, you might look to intersectionality for an explanation.

[0] https://en.wikipedia.org/wiki/Stratified_sampling

[1] https://www.nasponline.org/resources-and-publications/resour...

how are you differentiating "promotional easter egg" from "ad"?

> If you’re referring to a C program or programmer just say “C”. If you’re referring to a C++ program or programmer just say “C++”. If you’re referring to both used separately say something like:

>

> C and C++

> C, C++

> C++ with C

> Etc.

>

> NOT C/C++

>

> Only if you’re using C together with C++ would it be acceptable to say C/C++.

oh ffs, stop it with the pedantry.

How long of a blog post because "c/c++" isn't "c and c++"? It's neurotic.

Were there any specific things that were making it difficult for you?

The persons reaction doesn't negate any problem with the managers behavior.

For what it's worth, I don't think there's a shortage of malice, passive aggressive, instigating behaviors that occur in the workplace that can lead up to a such reaction.

> You upset them so deeply that they respond by unleashing the incredibly vicious-yet-perceptive tirade that they’ve been stewing on since the incident, reducing you to tears. Congratulations on hiring someone in the bottom ~2% of professionalism? At least your conscience can be clean at this point I guess.

"Well your reaction was bad, so it doesn't matter what I did"

This sort of discounts what the manager did to piss the person off, and if it's a recurring thing. A tirade isn't usually the first response. Maybe consider that you've overlooked some cues leading up to it.