On the other hand, if you write a substantial amount of code in a niche languages, the LLMs will pick up your coding style as it's in a sizable chunk of the training corpus.

If anything is shocking it is how modern readers have to be spoon fed bullet points and can't handle the slightest complexity of composition.

It might be that modern readers have other things they can read/do with their time. In pre internet times it wasn't so much the case - you'd buy a mag or book and then read it but now there are many alternatives a click away.

Pros and cons but often in the old days it was spun out to fill some volume the the printing press was set for like 400 pages in a book. I did Great Expectations at school which had about ten chapters with the main story and then about 60 chapters of irrelevant stuff because Dickens was paid weekly by the chapter.

But in a typical FOSS scenario, your decision to open source the code and Tyson Foods decision to use it are decoupled. You don't know who all the potential users are when you open source it, so you can't consider all the concrete cases and make sure that the license reflects them. In the same way Tyson Foods isn't going to contact all the creators of libraries they want to use and ask if their concrete use case is in line with the creator's ethics.

Agreed. This would be a logistical nightmare on both ends. Especially if the licenses can be revoked if and when Tyson Foods decides to change some of their policies and/or the author decides to change their political views.

I believe that this would effectively make sure that nobody uses these licenses.

> I have never seen a case where it mattered which vendor my JVM was coming from

As I understand it, Oracle's JVMs only get free updates for a limited time. If you keep using them after that you risk getting caught in a license audit.

It’s okay to use them for development and testing, just not in production. But yes, you don’t get LTS updates.

But that is an unanswerable question which depends on how the data structure is used. The reasonable thing is to calculate the cost for the operations separately and let whoever uses the algorithms figure out what that means for their use case.

Math isn't concerned with what exists or not, circles doesn't exist in reality either. And infinity is useful, if we didn't have it we would need to reinvent it in a clumsier form, like "the limit if x goes to a very, very big number, bigger than anything you could name".

Google doesn't care about right and wrong, only what they can get away with. They don't deserve to be treated as a moral subject by you, because they will not reciprocate. You're free to be as shameless as they are in your interactions with them if you can get away with it, you're just playing the game at the same level as they are.

I'm paying for Youtube Premium, but its a plain utilitarian decision after they started hassling me with captchas and intimidations that someone at my IP address was using an ad blocker. So yeah, I'm paying protection money. But I don't feel in the least good about it.

what do you think of people making videos, they deserve to be paid right?

Yes, but ultimately it is not my responsibility to make their business model viable. That's between them and Google - not me.

I am not Google's accountant. They can figure it out.

Google does not make me do it, I am free to mute the ad and look away. I don't have to watch ads, that is my choice.

If you want to be pedantic: "Google adds video pre-roll ad during which you are likely to see it"

It's not pedantic at all: if I look away and mute, which is perfectly allowed, versus use an ad blocker, what's the difference?

The outcome for me is identical. I don't see an ad, and I won't buy something.

It's the same reason why DVR recording was never piracy. It's the same thing as if I watched the show, except the DVR does it.

> if I look away and mute, which is perfectly allowed, versus use an ad blocker, what's the difference?

The difference is you still see the beginning of the ad and some people see a big part of it because they don't have the habit of muting and looking away out of fear of missing the beginning of the video for example.

> The outcome for me is identical. I don't see an ad, and I won't buy something.

You still see the beginning of the ad. Whether you buy something or not is not always what the ad is trying to do sometimes it's just raising awareness

> Otherwise they can't pay creators

> In 2024 the company made a revenue of $350.01 Billion USD

YouTube made THAT much money? Cool tho I want to know sources.

Now assuming that let's check how much it costs to host/recode/stream stuff. How dare companies want to profit right?

just wanted to show they don't need you to watch ads to pay them

then you didn't did you?

I did by showing that Google has plenty which they can use for payment.

By that logic Apple should give away iphones for free. This is not how things work in capitalism

No by that logic Apple could give IPhones away for free

If they want to eventually fold yes doing things for free is great

> if they don't get paid then you don't get content

[citation needed]

You're saying no content would be created if there were no payments?

Have you never met a real artist?

Yes, real artists need time, supplies, space to work, etc. If you don’t pay them, they’ll have less of everything they need to make the art you like.

Have you seen a well produced YouTube video? It can take days sometimes months and a lot of costs.

Why is it automatically assumed that just because you post a video on youtube that you deserve to be paid? None of my videos made me any money and I’m fine with that.

I'm knee deep in clang at the moment and I'm so fed up with real compiler engineering. Give me Chez Scheme and the nanopass compiler any day. That is so much better than the big ball of mud that goes into a "real" compiler.

..... Yes that's exactly my point that these cutesy books give a completely inaccurate picture of what the job is really like.

To me it looks like simple, clear examples of potential issues. It's unfortunate to frame that as "crapping on Go", how are new Go programmers going to learn about the pitfalls if all discussion of them are seen as hostility?

Like, rightly or wrongly, Go chose pervasive mutability and shared memory, it inevitably comes with drawbacks. Pretending they don't exist doesn't make them go away.

Go famously summed up their preferred approach to shared state:

> Don't communicate by sharing memory; share memory by communicating.

Which they then failed to follow, especially since goroutines share memory with each other.

Go is a bit more of a low level language compared to actor languages where the language enforces that programming model. I think the point of the slogan is that you want to make the shared memory access an implementation detail of your larger system.

Threads share the same memory by definition, though. When you isolate these threads from a memory PoV, they become processes.

Moreover, threads are arguably useless without shared memory anyway. A thread is invoked to work on the same data structure with multiple "affectors". Coordination of these affectors is up to you. Atomics, locks, queues... The tools are many.

In fact, processes are just threads which are isolated from each other, and this isolation is enforced by the processor.

Goroutines aren't posix threads. They could've lacked shared memory by default, which could be enforced by a combination of the compiler and runtime like with Erlang.

Who is "they"? This isn't Rust. It's still up to the developer to follow the advice.

Anyway, I would stop short of saying "Go chose shared memory". They've always been clear that that's plan B.

Go's creators said "Don't communicate by sharing memory", but then designed goroutines to do exactly that. It's quite hard to not share memory by accident, actually.

It's not like it's a disaster, but it's certainly inconsistent.

I don't think allowing developers to use their discretion to share state is "certainly inconsistent". Not sure what your threshold is for "quite hard" but it seems pretty low to me.

Goroutines could've lacked shared memory by default, requiring you to explicitly pass in pointers to shared things. That would've significantly encouraged sharing memory by communicating.

The opposite default encourages the opposite behaviour.

You are completely dismissing language design.

Also, these are minimal reproducers, the exact same mistakes can trivially happen in larger codebases across multiple files, where you wouldn't notice them immediately.

The whole point of not using C is that such pitfalls shouldn't compile in other languages.

> Using a tool knowing its modus operandi is not "pretending the problems don't exist".

I said that in response to the hostility ("crap on Go") towards the article. If such articles aren't written, how will newbies learn about the pitfalls in the first place?

While I agree with you in principle, there is a small but important caveat about large codebases with hundreds of contributors or more. It only takes 1 bad apple to ruin the bunch.

I'll always love a greenfield C project, though!

The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.

While reading the release notes, I was also surprised, that they finally have this kind of multi-threading. I knew about places, but they were kind of inflexible, as you couldn't easily send a lambda in Racket, and serializable-lambda was infectious, so one ended up having to pre-define all logic and at runtime only sending data not functions to other places, which was a shame. One could not really build a thing that distributes work via multiple places with that. Or at least no one managed to do that and no one could tell me how to do it. I hope that with the new concurrency stuff this is now possible, even if it may not be as conceptually clean as places were supposed to be.

Ultimately, multi-threading is one reason, why I mostly used GNU Guile, instead of Racket in recent years. Guile's story of using multiple cores is much more solid, using its futures and possibly fibers via a library. I have used futures, which are backed by a pool of threads underneath, to implement a toy parallelized decision tree algorithm/model, that had linear (or close to) speedup.

What kinds of things do you write in Racket? I’m a clojure dev and so I’m a big fan of lisp. I’m just curious what kinds of projects you would use Racket for

I'd say anything you use Clojure for except for Clojurescript.

And I guess expect for stuff where you really want Java integration?

There's a Java interface. I've never used it though.

https://docs.racket-lang.org/jni/index.html

i'm also curious.. do you use clojure because of jvm? i want to learn some kinda lisp, but there are so many choices. why not just common lisp or the one with emacs.

personal case -

clojure works on the jvm, or without (babashka, technically graalvm i think), or in the browser (clojurescript). i think there is a .net implementation, not sure.

then you get clojure inspired languages that are quick to learn if you know clojure (janet, C runtime, fennel on the Lua platform).

And soon a clojure optimized for integration with C++ (Jank).

Bonus, clojure is relatively simple language. (it's a small language where most things are immutable, with a small-ish set of functions operating on a small-ish set of provided data structures).

common lisp is cool but looks way (waaay) more complex. so you will need to invest way more to learn it (might be worth it, dont know). i technically "learned" it but never felt the impetus to use it.

i occasionally do some stuff in emacs lisp. but i'll mainly be running clojure & babashka (and rust). currently refreshing my ocaml, and learning ada (this thing is great, should have learned it a long time ago). also nim.

There is a .NET version, but hardly gets much love, it is already a challenge for F#, and the Iron languages are gone as well.

Unfortunely the CLR seems to have changed meaning from Common Language Runtime to C# Language Runtime, regarding Microsoft focus on the ecosystem.

I personally use Clojure because I got a job doing it, I hadn’t touched it before my current position. I would pick it now over Common Lisp and Elisp because I prefer the syntax (I like the brackets in addition to parentheses) but also the Java integration and build tooling make things easier to get going.

I use clojure over common lisp because I find the ecosystem (libraries) a bit more approachable (feels like there is more web oriented stuff in clojure, plus gui support with javafx.) That said, the actual experience of working in common lisp is better (bit better repl/recompilation, conditions, native compilation.) Personally, I don't find scheme as practical for writing programs as either of these two options (too fragmented and/or niche.)

It's not at all strange, Python and OCaml are mature and polished and they still have tackled the same issue very recently.

This is addressed in the blog post linked from the release announcement: https://blog.racket-lang.org/2025/11/parallel-threads.html

How rewriting something internally makes Racket not mature? Sounds like refactoring to me and with an extensive test suite there's nothing to be hysterical about.

Maybe I just have a different working definition of these words. To me "mature" means "fully developed" and "polished" means "achieved a high level of refinement". To me, rewriting it all to introduce a major feature that fills in a longstanding hole in the language doesn't say "mature and polished". Because often times many bugs are introduced into a codebase on a major rewrite despite extensive test suites, especially at the interfaces between features. Typically people might prefer a mature codebase to one that's just been rewritten precisely because it hasn't been vetted over years. "mature rewrite" sounds like an oxymoron to me, and I guess no one else agrees but I find it strange. That is all.

I think they don't always communicate well with industry practitioners, and your reactions are great evidence of that.

Racket is lead by professors, and (as is sometimes the case in systems research) some of them are very highly skilled software developers, well above HN average. But they have not been working in industry, and some have never worked in industry, so they don't always know what notes to hit, and they don't always know current subtleties of practice.

My best example of this is when someone kept saying the platform was "batteries included". My reaction was, my god, no, please don't say that: the first time the wrong person sees that, invests time with that expectation, and finds all the ways that is absolutely not true by industry convention, they will rip the ecosystem a new one.

Set expectations properly, and you attract the right people, who will love it, and they will also disproportionately be great programmers.

That said, the software engineering quality situation is much better than the impression you seem to have. They've done a very solid job of rehosting Racket internals, and of generally maintaining backward-compatibility over the years. Much better than Python, for example. (Also, Racket docs are usually much better than most ecosystems I have used in recent years.)

The rewrite started in 2017.

Fears about refactoring introducing bugs are fine and valid - but after eight years, haven't really happened. Seems the extensive test suite did its job.

This isn't a case of Python 2 v 3. Packages weren't broken en masse. The API remained stable.

If anything, the rewrite has proved that it is mature. Because they could perform a refactor without breaking everyone's everyday.

I agree. I remember very few bugs caused by the rewrite, but I don't remember recent ones.

For example, I found a bug running the tests of the r7rs package, it was simplified to a bug in "plain" Racket and later fixed, 3 days after the initial report. It was in June 2019 https://github.com/racket/racket/issues/2675 Note that at that time, the default version of Racket was he old one (before the rewrite).

Nobody would consider Chrome or Firefox to be immature or lacking polish because they have replaced entire compilers several times over the past few years? I don't have an exact count, but they probably do this every 3-5 years which puts them way ahead of Racket.

I'd also note that Chez Scheme was a commercial implementation bought and open-sourced by Cisco. It wasn't something they threw together. Because it is a complete scheme v6 implementation they are building on instead of rolling their own implementation in C. Coding against a stable Scheme API has to be easier and less buggy than what they had before (not to mention Chez being much faster at a lot of stuff).

I think you should read the old posts as to why Racket transitioned it's guts from primarily C to Chez Scheme. It would save a lot of time in the discussion here if you became familiar with that transition.

The short story is the same as anything written in C: it's an unwieldy language.

They might be making a distinction between the language and the current implementation. In fact I would call going through multiple different fundamental implementations without changing the semantics, an argument in favor of the maturity of the language.

Wait til you hear about NodeJS not supporting parallel threads until version 12...