l_theanine

I’ve trained hundreds of people across many roles for thirty years.

I have two things I’d like to add:

- A mistake you are willing to learn from is not just a mistake. It’s a lesson. It can yield as much reward as you’d like, depending on the effort you spend to reflect and change things.

- Most advice like this, when it comes to things someone learned after moving up a rank in some org chart, is not as portable as we might like to think. Teams are always different shapes. In the end, if business functions are being executed well and if the people doing those things are paid well and happy to stick around, then you’ll find over time it really just doesn’t matter what the process looks like or the permutations of productivity-fu you put on it.

Anyhow, this is a nice article. I enjoy reading stories about career progression like this. I wish I had read more twenty years ago to learn this stuff, I made a lot of “mistakes” then.

Keep it up!

Luckily, I wasn’t replying to you? Weirdo.

Not the person you’re replying to, but a little common sense would imply warnings along the line of “if you don’t do this properly, a crew of innocent people fall out of the sky and fucking die whilst screaming all the way down”

I’m talking about code organization, not types. In Julia, methods are grouped together by type dispatch, mostly. There are times when code reuse comes into play where it’s helpful, but mostly it just confuses the issue and introduces ambiguity into the structure of the program in the big picture sense.

My mistake, I saw your name was xiaodai and assumed.

My point is, Julia is not suited for general software, and it’s questionable as a tool for technical computing as well.

For running simulations and models where the code can be written and never looked at again, maybe it’s okay to use. But for anything else, Python is a lot nicer, and a lot more practical to write proper software in.

Jesus. This is the most tasteful, flexed out but not over the top landing page I’ve ever seen.

I love it. I’ve no use for something like this, but I’m in absolute awe at the design on display. Marvelous. I hope Apple or somebody makes this person obscenely wealthy.

C++ is a beaut', compared to Perl. It's ugly too, don't get me wrong. I'll be the last one to hold up C++ or PHP as beautiful, but Rust is just too gross to look at, I have NO idea how people program in it.

I think the only thing Rust has really brought to the table is the idea that alternative memory schemes like ownership can be valuable. That idea will slowly disseminate into Python/Ruby, and other languages from there, and those of us who appreciate beauty will continue to program with proper tools.

I'm actually looking into Ocaml lately. The 5.0 release is really interesting, and the next release of OPAM will have proper Windows support and everything. Rust takes a lot from Ocaml, as I understand the original compiler was written in it, and inspired by it.

I think mutable shared state is bad, as you do, but I think so less because of the advantage that a tool like Rust or Erlang brings to the table in handling that state, and moreso because of the programming practices it brings about regardless of the language. Treating a session as stateful, or really treating any io-capable object as mutable is definitely a big mistake. That much is clear. I think as the years go on, more languages will embrace this wisdom and replace Rust's incredibly rigid and unfriendly experience with things like proper object capability systems, effect handling, and whatever instruments would be useful from formal verification methodology.

And again, all of that could conceivably land in Python/Ruby eventually, or as extensions, whatever.

I guess what I'm saying is that over a long enough timespan, it would seem that ideas are always going to win out and language designers will slowly advance towards that front, while retaining beautiful code.

It's interesting that you mention Clojure, because a lot of really cool ideas bouncing around the Ruby/Python sphere originated or at least came to widespread popularity in Clojure. I'd put Erlang up there as equally influential as well. Clojure also shares the feature of highly-writable and highly-readable code, which qualifies it for beautiful, imo. How often do you come across a Clojure function that's just cluttered with {}{}<T><T><<T>RefCell>(); bullshit, to the point where it's not immediately clear what is happening? Now, compare that with Clojure. If ever there's a complicated Clojure function, I'd wager that it either a) deals with Java interop, which, God bless you. or b) is just a highly abstracted function, and can be grokked by walking backwards up the calls one-by-one. Terseness can be daunting, but it's almost always a simple case of gathering context to understand those functions ending in )))))})).

Anyhow, I've wasted too many bytes here.

Since you've a decade in Ruby, have you tried Crystal at all? I heard about it last year sometime, but was turned off by no Windows support.

I haven't used asyncio that much, certainly not in any serious sense, but wouldn't ContextVar lookups be a major factor of performance in serious asyncio code? Using tasks for things that aren't io-bound seems likely to give a false sense of performance superiority when doing basically nothing.

I'd definitely be more apt to have this as part of production system instead of the Rust one.

Rust has got to be the ugliest, most unfriendly programming language I've ever laid my eyes on. And I wrote Perl for 10+ years, so that's really quite a feat of aesthetics failure.

Anyhow, I'm pretty impressed with the performance thus far, I like the idea of having multiple JITs available for a single-language ecosystem, regardless of how disgusting the language used to implement them. I think having competition means that there will be a race to the bottom and towards the "center" of general work. It's already really cool to see how the different approaches have clear preferences of the tasks they excel at and where they fall short.

This is hugely valuable because it pushes Ruby forward for everybody, and will hopefully result in not only a faster Ruby for X, but a faster Ruby for everything, which is just an objectively good thing.

Python is in a weird spot in this arena, because it is very clearly and very strongly orienting itself to continue to dominate practical data science work, and that means the need for JITs to handle regular jobs like text munging and whatnot fall by the side in order for the latest NumPy and Jax stuff, whatever is the current hot shit in the AIverse. Ruby doesn't suffer from that because it's pretty solidly lodged in the web development sphere, while also having a capable presence in netsec tools, application scripting, and probably a few more areas that I'm not aware of.

If you're interested in some of cutting edge Python stuff, I'd recommend taking a look at exaloop/Codon. Codon will soon be able to output Python extensions that are compatible with Python's setuptools, so it will soon be possible to just include some .codon files with your project, use setup.py, and have decorators that can (literally) 100x your hot loops.