skysight-inc/HackerNews huggingface dataset:
> I've also never personally experienced the tech trope of being in high demand, getting multiple great offers or amazing salary/perks. It seems a lot more uphill than the experiences that other people share online.

Interviewing people over the past 25 years, not at FAANG level, but Fortune 1000 down to VC funded startups, I can put people into three buckets. Bucket one is people who clearly don't make the cut. Bucket two is people who seem to have basic skills and knowledge, but when you drill down they don't understand things in depth. Bucket three are people clearly head and shoulders above the other two groups. I would say if interviewing six people, one winds up in bucket one, one winds up in bucket three, and the rest wind up in bucket two.

Bucket two people are interchangeable - you see they have been working for a while, you feel they can handle the simple tickets needed - but what about the more complex ones?

That is one problem with being in this group - of the last six interviews, four others were just like you. Unless they have a recommendation, there is no incentive to hire them. Because out of every six interviews, you usually find someone who can answer almost every question in more depth than the five others.

I think this is the model to have in your head. If your manager's manager has 36 Javascript developers under him, if you're not in the top 6, you're not going to be a "high demand, getting multiple great offers or amazing salary/perks".

Of course the times have an effect on these things to, the bar is lowered and raised. Some people used to make six figures doing stuff in Adobe Flash, and then demand for that dries up and the smart ones have jumped onto the new thing. Things can go both ways at once. Your local job market may have dried up some, but the country might be more willing to hire remote-for-the-next-few-months right now. Although that could have good and bad effects.

The wrong approach is to go on an interview and think you passed or failed some bar. The correct approach is to imagine five people like you, all working your job, four of whom can get basic things done and have basic knowledge. You have to clearly have a better depth of knowledge than all of them, your code samples have to be more up to date and complete and better than theirs, your 30 minute code solutions have to be better etc. You're competing with five other people, four of whom have basic competence, and you have to clearly distinguish yourself from them. That is how you reach the "high demand, getting multiple great offers or amazing salary/perks" category.
If all you’re doing is submitting a form with Ajax, sure, jQuery would be fine. But I’ll venture that most frontend apps are at least somewhat more complicated than that.

My side project is a web app that lets you create music visualizer videos. There’s a ton of UI, state, complex interaction between parts, etc. If I weren’t using React, I’d be using something — but it would surely be another full-on framework, not a simple library like jQuery.
A little late but I would like to chime in with mine

https://emailalerts.net
No...

>I think this is why a lot of crazy big startups come from younger people,

"crazy big startups"
That's what Scala and Kotlin are, fixes for the original Java flavor. Then again, more alternatives are good for competition; and incubating and sharing new designs that aren't possible in a very old language.
Use create-react-app and don’t eject or add any fancy custom tooling. Nest.js is pretty good on the backend.
There are actually named member functions for those; they're append and concat. Can you guess which is which? I can't. append is actually "append with directory separator", which is weird, because I'd expect append to be a string-like append to match the append function on std::string. Instead concat is a string-like append despite the fact std::string doesn't have a concat member.

OTOH / is an instant mnemonic cue for "append with separator", and + matches the + on std::string.
Knex.JS http://knexjs.org/ ?
I have written at least 10 apps in TS with dozens of libraries, including some server-only stuff.

All the problems I've had were with JS and npm. TS has been amazing and worked flawlessly. I just can't understand your experience at all.
It's a well known data point. In general, women don't like to marry down, and men have less of an issue marrying down. Think of the classic "doctor marries nurse".

If you Google, you should find a lot of articles about it, as it is an important sociological issue. Now that more women are having a career, in fact, more women than men are having an academic career, it is becoming difficult for women to find adequate men.

Also women marrying up was historically the MOST important mechanism of social mobility (people moving up in status/wealth). Too bad that feminism does not allow it anymore, as any man who marries a less wealthy women is considered to be "abusing his power".

The other claim, women being attracted to men with more money, I am less sure about. I am sure you can find studies analyzing data from dating platforms yielding that result, but I don't know how well they generalize to dating in general.

Edit: perhaps a starting point, but in general, Google should be able to help https://en.wikipedia.org/wiki/Hypergamy
Survivorship bias isn't a negative, it's just a fact.

People bringing it up aren't naysayers, they're just being realistic.
When you have that many users, their yearly dues is no longer as valuable to the company and its partners, as user data.
Improving a dominant (but broken) language is called "innovation" and "improvement". There's no reason all your magic bells and whistles couldn't have been added into Java. Creating new languages just made life worse for everyone.
It's one of the reasons I both love and hate interpreted languages: they're by far the fastest edit-test cycle available so they are super fast to get started but after a while and when your program becomes larger you always end up wishing you had more goodies to keep you from messing up.
The ATC union is a monopoly, which is just as bad as a business that has a monopoly. They can hold the entire aviation system in the US hostage. This is why it is illegal for them to strike.

They knew when they took the job that striking was illegal. Reagan reminded them of that, and said he'd fire them if they broke the law. They did anyway, and Reagan wasn't bluffing. Reagan could have also prosecuted them, but (wisely) chose not to.
The point that we only know something non-trivial _may_ be happening is definitely fair :) I'll leave the original comment as-is since you've already responded.

While we're nit-picking, a wide vector type implemented with SIMD intrinsics would still have a non-trivial addition as far as Zig is concerned; your specific example really only holds for sufficiently primitive vectors.
Let me try too :)

Reactor - exactly 0kb (zero) ReactJS alternative built-in into Sciter.JS :)

This https://github.com/c-smile/sciter-js-sdk/blob/main/samples.s...
works in Sciter.JS as it is - without any external frameworks.

`JSX` and `element.patch(jsx)` are built-in into Sciter.JS.
And it uses ES2020 so no Babel step is required.
valid point

I'm not denying talent, just stating that in this context (rare advances) I don't think it's the main limiting factor.
Why would it be a big emotional sacrifice to marry into money? Especially if (as some studies suggest) money is a big part of what makes men attractive, odds should be high for actual love being involved in the decision.
You clearly have never ever worked in domain renewals before. Many people only renew once dns stops resolving. I've seen govt agencies use this as their reminder to renew.

And yes, many scammers out there send postcards to businesses offering to assist for $1,000 on the renewals - and many people pay. So people do send out "alerts" the way you ask - most commonly exploitive and at least I give the advice to ignore ALL such renewal alerts. If you are telling people to respond to those you are sending people down scam ally.
It's definitely a thing in places like China where you have a much larger population of men, and it is harder and harder to find a woman (so much that some people buy their wives online from other poorer countries).
A New Model Performs Human Re-Rendering from a Single Image
I think the closest thing to "Rust plus green threads" isn't Go, but Haskell. If you try to switch from Rust to Go, you're going to find yourself missing the type system, ADTs, traits, etc.

I wrote this back in 2014 comparing (early) Rust, Go, and Haskell, but I think it's still more or less accurate. https://yager.io/programming/go.html
Personally I find gesture support annoying and its functions are better done with keyboard shortcuts - if you want to show the desktop pressing windows-D is much quicker and easier. The first thing I do on a new laptop is find the touchpad settings and turn everything off.

I find it ironic that Apple used to push the one button mice narrative as 2 buttons were overwhelming, yet now you are supposed to contort your fingers into doing a million different gestures on a touch pad.
i mean, my Fedora system will be on ext4 for a while since I don't wipe anew with every upgrade...
Ah yeah, I have similar feelings.

BumbleBee was promising at one time:

https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ

But seems kind of dead now.

https://www.bumblebee-project.org/
I don’t think DSLs are good. Just use a nice Typescript api.
If you could feel something before it harms you then you could do something about it. If you can't, like with radiation, then you can't.

You can feel heat before you die of heat stroke.
Non obvious test?

If the patent was never invented and filed, would a child be able to come up with and communicate the idea patented?

If one click to buy didn’t exist today, how many children would be able to simply state the obvious solution of one click purchasing?
It'd be great to include some information about the awesome cross-compilation support!

Thanks for all of your work, it's great.
Yes, person on a lisp-powered hackers forum, tell us more about how languages lacking native sum types are unusable.
Apple fights consumer surveillance well. This is a distinction that seems to get lost; it's not all forms.
> nevermind it's not even grammatical

Neither is proper English ;)
Add Poly Bridge 1/2 to the list :)
Shouldn’t malware be detectable even if the binary is entirely a black box? In other words, I would expect certain patterns of system calls to be flagged as malware, regardless of the program.

I’m curious what additional information is derived from static analysis of a program that helps identify it as malware.
To be successful over the course of a career requires the application and accumulation of expertise. This assumes that for any given undertaking you either provide expertise or you are just a bystander. It’s the experts that are the drivers — an expertise that is gained from a curiosity, and a mindset of treating one’s craft very seriously.
A startup is by nature a crash course in developing expertise. What makes startups unique is the sheer dearth of resources. This dearth of resources forces founders to rapidly adapt their skills to meet the demands of the project.
‘I didn’t know how to do x, so I just had to figure it out.’ This is what I regularly hear from successful founders, whereas ‘I couldn’t find someone to do X, so I had to reconsider whether to pursue it at all’ is a common refrain from unsuccessful founders.
Dude, we’d writing in COBOL if anyone followed your logic.
"I have to carefully make sure that each resource has been freed/closed (but not too soon!)"

You can use defer keyword to free right after allocating and it won't be called until the function/program completes. You can use debug or testing allocators to ensure no memory is left unfree'd or double free'd. The std lib has a large selection of custom allocators that you can use depending on your needs. One great one is an "Arena Allocator" which is just a linked-list of allocations that can be free'd at one time, versus tracking all these individual allocations. And if none of these allocators fit your needs, the interface to define one is pretty easy to implement.
https://ziglang.org/documentation/0.7.1/#Choosing-an-Allocat...

"I'm not mutating or holding onto anything I'm not meant to"

Not really sure Zig can help you with this one. With great power comes great responsibility, or something like that.

"that I've accounted for every exception that I can result from a given call"

Zig does not have exceptions, but it does have error types which functions can return. From the function definition you usually can determine all the errors that can possibly be returned, unless the function definer use'd the catch all ! error type. Regardless, it is still much better than regular exceptions because

- you know by the function def that an error could be thrown, the compiler forces the caller to account for a possible error by "unwrapping" the return value

- an error happening just passes back a different type to the caller and in combination with the above, you can never "miss" an error
https://ziglang.org/documentation/0.7.1/#Errors

Also Zig switch statements without an else ensure you handle every possible value so if you forget to handle one possible error (based on the type), it will throw a compile error.
https://ziglang.org/documentation/0.7.1/#toc-Exhaustive-Swit...
My dislike for Java aside, you fail to realise there have been hundreds of programming languages created before Java too.

The same would be true if all the car companies in the world just cooperated on a single car model to rule them all, right?
You sound like you have a hammer, and so every problem looks like a nail.

Sum types can be useful. Other aspects of languages can be useful, too. Why fixate on that one? And if you're going to say that it's a minimum bar, well, some of the other features are missing in most languages that have sum types.

Pick the language that has the total set of features that makes it easiest to write whatever program you're trying to write. Don't get locked in to focusing on only one feature.
This sounds far-fetched to me, partly because of the nontrivial technical differences between Java and Go and partly because of the politics surrounding Oracle’s ownership of Java and the way Oracle quashes community efforts.

Value types, interior pointers, multiple levels of pointers, slices, and radically different indirect dispatch semantics are just a few things that Go has that Java doesn’t. These aren’t things that you can staple to Java. Java is more than syntax, it’s the semantics of the JVM and its object system, which should only be extended in a backwards-compatible way.

So I’m gonna say that the reason Go exists is exactly because the creators didn’t want to burn down Java and start over. It turns out that you can create a new language without burning anything down. There is also C# and the various nontrivial differences between C# and Java, like value types and type erasure in generics.

There are plenty of languages which exist side-by-side with Java in the JVM: Clojure, Kotlin, and Scala to name three. These all have their differences but they’re all designed specifically with the JVM in mind. Go isn’t.
Boston is huge in life sciences. Every pharma, lots of biotech, and MIT. MIT's president is really pushing biological engineering.
> If you want to feel good and feel empowered to build your own start up from OP's post, then I don't know what to think of your risk appetite.

You're attacking a strawman here. My point was merely that cynicism (which your post conveyed in spades), much like solipsism, is an unproductive dead-end. Feel free to make your case, but I'm fairly confident I'm correct.
And yet, there’s no other platform where you can go from an idea to something easily accessible by anyone in the world — in a span of minutes.
> Whatever people find unacceptable about Java could've been fixed.

It's been DECADES. Plenty of time to fix things but nope. I don't know what Java's developers were interested in but improving things for other developers was not one of them.

C# is literally a better Java already. And Kotlin.
Agreed - trying out nest.js the first time gave me hope that we'd see something like Django for typescript/javascript. Especially paired with nx workspaces, with shared code between front & backend... so nice.
> If give someone enough constraints almost any patent will seem obvious.

That seems like a strawperson. The parent said that just given the very rough idea or (I would add) even just the term "1 click buy", somebody could have created a comparable experience without any reference to the patent. That's not "give someone enough constraints". That's "let somebody overhear a customer mention the feature in passing".

Suggesting that Amazon wouldn't have invented 1-click buy without patents seems incompatible with good business practices. All my conversations with other developers mentioned a single reason for patenting "random" features at this point: As a way to defend against other people's patents. The only reason _not_ to create a novel feature was that it may be too close to something patented and a lucky lawyer may have argued that it was too close. If anything, software patents actively discourage innovation.

I've never heard of anybody implementing a feature by using a patent. I've never heard of somebody developing a novel feature to get a patent. Which means as "patents", they are useless.
Oh God, it's Bhattacharya again. He's chosen the hill he will die on and nothing is going to change his mind. The "herd immunity" guy is once again shooting for herd immunity.
HP until recently didn't use precision touch drivers.

When looking for a new laptop it should be the first thing you check in the reviews - if it doesn't have precision touch drivers it goes in the do not buy list.
> I think it depends more on the patent itself. If the patent is very clever and something that people are unlikely to discover themselves then it makes sense to exist and be enforceable.

Not really, not if the holder isn't actively exploiting it. The whole point of patents is to encourage expensive innovation so you don't come up with something and then have it stolen after doing the hard work.

But if you did the hard word and aren't exploiting it, then it shouldn't be withheld from society. Let someone else exploit it.

If you did the research but can't mass market it, then you should be forced to sell the patent, so that society can benefit from your invention.

At the end of the day, the patent system is supposed to benefit society, not the inventor.
I'm not aware of better ones, though I wish I was. There are very few places online where Republicans and Democrats actually talk politics.
> what seem to be pretty clear trends

Clojure is a Lisp. Lispers simply failed to convince the younger generation of programmers how powerful and versatile Lisp can be. Any Lisp dialect these days gets rather automatically rejected. Of course, Clojure (or any other Lisp dialect) currently would struggle to gain momentum and compete with other non-lispy languages.

But if you look at the stuff that Lispers are capable of incubating, you'd be amazed. Today Clojurists figuring out interop with Python, Julia and R. They've built Clojure-like PLs for other language ecosystems: Golang, Lua, Erlang, etc. They are pushing Clojurescript on microcontrollers. They're building neural networks, graph databases, and mobile apps. They're borrowing good ideas from other languages, frameworks, and tools.

This isn't a sprint, it's a marathon. Look at the bigger picture. Notice things like Idris, which uses Chez Scheme for its backend. Chez Scheme is almost 40 years old!

And within various Lisps, Clojure is undoubtedly a resounding success. If anything at this point truly could de-throne Clojure, it won't be something like Elixir. It would be a better, faster, perhaps more efficient fork of Clojure.

What's keeping it from achieving growth in adoption is not something internal to Clojure. Or something that Clojurists can turn around. It's the fact that it is a Lisp. And that's not going to change. In fact, before Clojure, Lisps seemed to be getting out of fashion. Clojure made Lisp (somewhat) popular again.
Probably true for you and your team. Definitely not true if you fully grok all the advantages of the BEAM. Elixir is much faster to prototype modern web apps than alternatives and then also naturally seques into scaling if the need happens to arise.
Doesn’t the appeals system make every case federal in theory, if not necessarily so in practice?
You really have to go out of your way to get memory safety wrong in modern C++.
>don’t eject or add any fancy custom tooling

Doesn't React require the latest and greatest in build tooling to make it work?
Its good business, that is how Marshall, Texas, city of 20000 got its Samsung Ice Skating Rink, Samsung Holiday Celebration Show and a steer champion called TiVo.
The way I see it is that among those, they haven't actually been able to form a leftist worldview free of economic liberalism. It's normal, because modern opposing alternatives are basically completely absent from the mainstream.
That's again the classic power games bullshit. "You could never understand me", "It's impossible for me to understand you" and so on. That's overly dramatic and self-aggrandizing. And in the case of the person who is sick, also inducing unnecessary loneliness.
I have read this EWD several times now, I think he makes a solid case for:

a <= x < b

over the other three forms in the general case. But he fails to make an argument for the special case of 0-based indexing vs 1-based.

When restricted to just the discussion of 1-based and 0-based:

1. The experience report doesn't seem to apply as it's about the general notation advantage, not the specific cases of 0- or 1-based indexes. We would need additional experience reports about those (which I suspect would tend to favor 0-based).

2. We don't need to worry about calculating the range size, because it's obvious for both cases. Yes, (a) is better if you're using 0-based indexes and it's awkward if you're using 1-based. But (c) is better if you're using 1-based and awkward if you're using 0-based. (a) leaves the range size of a 0-based index in the range description, and (c) leaves the range size of a 1-based index in the range description. The argument becomes a wash, neither is obviously better than the other on this basis.

3. The argument that (a) is better because you can see if two ranges is a persuasive one. But how do you have two adjacent ranges when they both have the same starting position? It's irrelevant to the case for either 0-based or 1-based arrays.

His final argument is that:

1 <= x < n+1

is more awkward than

0 <= x < n

But he doesn't even present the alternative:

1 <= x <= n

is less awkward than:

0 <= x <= n-1

Again, a non-argument because it assumes the outcome he wants, that 0-based is fundamentally better.

Now, all that said 0-based has other advantages. But Dijkstra fails to address those other advantages. Ultimately, though, as I said in the other discussion, your language shouldn't restrict your range description options to either.

> You really should accept his argument though. It's quite persuasive.

I don't think anyone should accept the argument because it is not persuasive. There are much better arguments for 0-based indexing than this EWD. We should scrap flawed arguments when we have much better ones available. The best part of the EWD is the description of which range notation is "better", but not the part about 0-based indexing.