You would fix the seed once in the beginning before sampling.
Also you would need to sample exactly N-times as there no rejection required. as the points will all be within the circle by construction and will have uniform distribution
The problem was stated in the beginning as 'Consider the problem of generating N points on a disk of diameter D. The function must be deterministic and the points somewhat uniformly spread around on the disk. Importantly, I want to generate exactly N points, for any integer value of N.' Then the author decided to do it through concentric rings.
Google also uses a completely different protocol stack to actually send Stubby/Protobuf/gRPC around, including protocols on the wire and bypassing the kernel (according to open access papers about PonyExpress etc)
Something is still not right for me. The scrolling is extremely janky. I'm on mobile so can't check devtools right now, but I would open up Chrome's Rendering tab in devtools and check for excessive layout recalculations and such. Maybe also do some performance profiling
I bet it's working as intended. The $ symbol is probably a special feature of the console and is not intended to be a property of window. Inside setInterval, the function is no longer being executed in the special console environment, which has access to that symbol.
Yes, I guess there could be some intention behind that, presumably some security precautions, but still: the fact that you can see $ in the globalThis (as a non-enumerable prop), and that globalThis you see from inside the timeout-ed function is strictly equal to globalThis seen directly from the console, that makes it somewhat spooky.
And it (`setTimeout(()=>{console.log(typeof $==="function")},0)`) works in Firefox. (Interestingly, you cannot get $'s descriptor in there, but you have it always available in timeout.)
Removal of setuptools in 3.12 broke a ton of legacy builds. Basically created a wall of forced package upgrades for a huge amount of packages in PypI where end users have to bump a bunch of stuff if they want to migrate from < 3.12 to 3.12+
setuptools was never part of Python's standard library. I think you're thinking of distutils which was removed from Python in the 3.12 release. You can easily access distutils again by installing a package from PyPI.
This comment thread is a microcosm of the problems with python packaging :D I appreciate the work the ecosystem does on it and everyone is doing their best, but its still a hard problem that doesn't feel solved
Every release removes / breaks stuff in the standard library and has been for a while. That's because prior to ~3.2 or so, deprecations were basically never followed up on, but now deprecation means it's going to be removed.
E.g. Python 3.12 has deprecated datetime.utcnow(). So it will probably be removed in Python 3.14 or 3.15.
For all intents and purposes, "Python 3" is now the brand and "Python 3.x" releases are major, breaking releases.
One that I ran into at previous job: 3.10 removes the ability to implicit cast floats to ints in a bunch of places. That was very much a breaking change for a bunch of code out there.
Comparing ints and floats sounds like a pretty high nono in basically any language ever. Why more python projects should use MyPy and not freely switch float to int to decimal. They aren’t the same thing.
Some seldom used standard modules have been deprecated and later removed. Like recently I revisited a project I initially made using v3.6, but it broke on v3.13 due to an indirect dependency no longer present in the stdlib. It was a simple fix though as a quick search identified the issue and pointed to the removed module in a package on PyPI.
Python 3.6 is from 2016 and 3.13 is from 2024. Similar things happen on most platforms on this timescale, eg on the Java side[1], you'd be going from Java 8 to Java 23.
Clojure is pretty good even on that timescale though.
I often see people recommending Python as a replacement for Bash scripts (utilizing common Unix tools like grep and awk). I'm pretty sure a script from 2016 will still be working fine now.
> I'm pretty sure a bash script from 2016 will still be working fine now.
In some environments, yes. A bunch of platforms have started using bash-compatible (but not actually bash) shells like fish to help with startup performance. Apple has upgraded from a truly ancient version of bash to a somewhat-modern one in that time (and then gone all-in on zsh instead). Things change on the scale of a decade.
And yet, if the script is written to POSIX sh standards and has the #!/bin/sh shebang line, none of that breaks.
Yes, of course, things do change incompatibly in a decade, probably including some of the nonstandard platform-specific commands called by the script regardless of which dialect of shell. But people who use a nonstandard shell dialect - however common it might be at the time of writing - should be prepared for that shell to become uncommon, absent by default, installed at a different path, incompatibly changed, or otherwise unusable a decade later to an extent that people writing to the standard do not.
Yeah, it's nothing crazy, but it makes upgrades a lot more unpredictable. It's harder to communicate to management why the 3.x update took a day and the 3.y upgrade took a whole quarter.
It's harder to upgrade services in a central way with any amount of leverage, and generally requires more coordination overhead, and moving more carefully.
Compare with, say, golang, where it's pretty much a non-issue. My experience with Ruby was a lot better too, until Ruby 3, but hey, that was a major version bump!
They have been removing features every release for the past few years. Code that was working fine on 3.10 may break on 3.13 just because it was using a feature they didn't like.
This behavior seems difficult to actually implement in practice, no? Your application has to be careful not to accidentally cache any configuration state, as well as any state derived from the configuration, otherwise it will go out of sync. Maybe easy for trivial apps but most apps requiring configuration files are non trivial.
No, it's a way of writing a better language while using Go libraries extensively. The same way Kotlin is a way of writing a better language while using Java libraries extensively.
No, but that isn't what Rob Pike meant, that was the Go design team accepting they alone weren't capable to implement generics in Go, without help from those PhD folks.
Java compiles to native code for two decades now, it has always been a matter of how much one was willing to pay for a commercial JDK.
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
> our programmers are Googlers ... They’re not capable of understanding a brilliant language
Sounds pretty damning, I'd say. This of course illustrates why Go is called "systems PHP".
> how much one was willing to pay for a commercial JDK.
I strongly prefer open-source tools at the base of my stack. Not as much because of the money but more because of the level of trust. Things should be inspectable.
That's what .NET is for (both C# and F#) - it has no private implementations (Unity does not count :P). Much more competent compiler too and smaller native binaries. Something you could confidently use in production.
.NET still doesn't have any real time GC, zero pauses GC, bare metal implementations, cloud JIT, a compiler development framework, has lost the mobile OS wars.
So I would slow down on the whole Java versus .NET flamewars, regarding who's more competent.
I use both ecosystems, because both have plus and minus, and complement themselves.
- .Net devs (they are almost as annoying as us Java/Kotlin devs)
- a language and ecosystem that consistently sacrifice backwards compatibility (contrary to us who have features sacrificed for backwards compatibility at every single step)
- you have to live without the JVM ecosystem (on this I have no self deprecating comment, C# is a better language, but the ecosystem, from libraries to build system to IDEs is something I always miss when I work in .Net.)
“Contrary to us”? I can’t agree with this attitude.
.NET maintains excellent backwards compatibility, C# and F# even more so. The changes either affect frameworks and libraries, which you can often update independently or are easily addressed. Most projects since .NET 5 only ever had to bump the target version and rebuild to move forward (notable exception: in .NET 6 ASP.NET Core introduced simplified API for application setup which required changes).
Neither JVM nor Go have the degree of low-level capabilities .NET provides first-class support for. And F# integrates in an easier way into existing C# solutions than Kotlin does into Java ones.
It is the GC-based Rust alternative many are looking for but are overlooking due to bias from the past.
Yes, I'm talking about the platform, not the syntax.
It is my feeling that .Net developers with some years of experience get wide eyed when I tell them how I can use any old library that I need together with the newest JVM and my platform upgrades have mostly consisted of bumping numbers.
I don't know which developers you talked to. Honestly I should just flag this reply probably.
It's nothing surprising in .NET land. If you target netstandard2.0 the library will work on any version from .NET Framework 4.6.1 and upwards. For many newer features there are compat and polyfill pacakges too - that's one of the strengths to be able to use them even on the older targets.
All newer targets are forward compatible anyway. Wherever the notion of otherwise comes from it is likely a misunderstanding or trolling.
You can't make a serious argument when comparing baseline experience where .NET confidently places next to Cargo and Golang's user experience with the level of productivity it provides for setting up and managing projects and dependencies, building them and distributing them. JVM ecosystem still does not offer capability to properly and easily package the applications into a single binary except using very restrictive GraalVMs Native Image which does not have as wide ecosystem support as NativeAOT enjoys, and where it does not work .NET still gives you the ability to bundle managed assemblies into an executable together with runtime, apply trimming and get relatively compact result.
Contrary to Native AOT, Java tools have always found a way to deal with reflection, instead of asking the ecosystem to rewrite their libraries.
Yes there are AOT friendly frameworks, however JVM agents have also provided a way to gather the necessary data for a AOT compilation, since the Exelcisor JET days.
"We hire working-class college graduates from the normal population, and not ivy league graduates who have the time to waste on unproductive academic research languages that see no industrial use."
Is this what is so damning about Go? The constant reposting of this quote as some sort of attack on Go's validity and reputation reeks of nothing but classism.
Google is famous for tough interviews and accepting a small fraction of applicants. I was impressed with everyone I met, and Pike's "incapable" statement was baseless and insulting.
Intellectually capable to do what? Orchestrate some of the largest distributed network systems in the world? I bet you all the best functional programmers wouldn't be able to create something as big as Google if you got them in a room together. Nor would they be able to create anything as important as UNIX, like one of Go's creators did. Nor UTF-8. Nor the JVM HotSpot machine. I could go on. What have you done that Ken Thompson couldn't?
The fact that none of these highly accomplished individuals want anything FP-related in Go says far more than what typical Go-haters want to think it does.
> The fact that none of these highly accomplished individuals want anything FP-related in Go says far more than what typical Go-haters want to think it does.
Does it?
I'm not a Go hater but just because they were involved in making the things you listed doesn't mean they would do it again with Go. It just means they don't trust others with different languages.
I don't think what you said refutes people's perception of Go, which is its a fairly limited language that is good for keeping people on rails (like fresh grads). That might make sense for a large business hiring lots of people but maybe not for small companies.
Also there is a world of difference between FP features and the basic features people asked for in Go (like generics).
This is a horrifically obtuse and offensive comment just because Go isn't Lisp-y or Haskell-y enough for you. Golang powers large swathes of distributed services and systems all over the world whether you like it or not, because it was designed with a very specific purpose in mind by people far more professional and accomplished than you ever will be.
I think that comment might actually have been because of this quote from one of Go's creators, which was posted further up in the thread:
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
It's a huge and dishonest leap to jump from
"our programmers are Googlers, not researchers."
to
"Rob Pike admitted anyone who uses Go is stupid and if they were smart they would be using Scheme instead."
And the problem with that is? Honestly, the more experienced a developer is, the more their code naturally seems to look like what Go shepherds you towards.
It's not a perfect language, but it's a pretty good language for building shit and shipping stuff.
I've written a ton of Go, for fun and professionally.
And it starts getting to you, because a lot of problems just don't have nice solutions in the language because of its limitations. So you start accumulating kludges, which lowers the bar for quality in the entire code base.
There are PLENTY of techniques and abstractions that are VERY useful yet not expressible in a sane way in Go.
It's a nice enough language for beginners, but acting like it's the end all of programming just makes you look like a fool.
I like to use pv as a quick and dirty operations per second counter. Sometimes I will write a program or script that does a bunch of things in parallel (e.g. RPCs to a service I'm working on), and prints one line of output for every operation completed. Then I pipe that output to pv using the --lines option to count only lines. It shows how many lines are being printed per second, which roughly counts operations per second. (IIRC, also need to pipe to /dev/null to prevent pv's fancy output from clobbering the tool's output).
Fun stuff! Especially when combined with GNU parallel, in cases where the thing I'm measuring isn't already parallelized, and I want to be lazy.
reply