HN Theater @HNTheaterMonth

As a huge fan of Julia i got to fully agree. Although i would probably not "no longer recommend Julia" but "give huge caveats when mentioning Julia". Organisations (that includes those who maintain programming language) have values Bryan Cantrill has an excellent talk on this https://youtu.be/2wZ1pCpJUIM and i got to agree with the author that correctness (especially correctness under arbitary composability) is not a value that Julia teaches and instills in its users. Some Julia users care about this, some core maintainers do to (as the Pkg3 demonstrates). However there are many invocations (SafeTestSets vs Test) and stumbling blocks. I am aware of no efforts to do formal verification on Julia code. There are no good ways to move certain Run-Time to compile errors. Correctness is not a value of the Julia language. Here is the good thing though, as Bryan demonstrates in his talk, you can hire for values.

I guess the Cantrill talk you are referring to must be 'Software as a reflection of values' from 2018:

https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=128s

Bryan Cantrill has an interesting talk that discusses various languages in terms of their values that you might finding interesting: https://www.youtube.com/watch?v=2wZ1pCpJUIM

No, I'm not. Or at least, not as I see it.

How would you describe javascript's values, compared to other languages? This is a great chart / explanation of this kind of thinking from Bryan Cantrill:

https://www.youtube.com/watch?v=2wZ1pCpJUIM

⬐ tonyedgecombe

No integers. What's the difference between == and ===. Why do I need to learn two ways to declare a class. What module system should I use and why are they all different. Why isn't there much of a standard library. WTF is Grunt, NPM, etc. Just explain 'this' to me again. What is the distinction between null and undefined. What is the difference between for/of and for/in.

JavaScript is far from accessible to new users neither is it simple.

⬐ coolgeek

I agree with most of your points. But the distinction between null and undefined is an important one. Its absence is a legitimate complaint about SQL.

⬐ josephg

You're arguing that javascript doesn't succeed at being accessible to new programmers. I'm not arguing that. I'm saying that javascript nominally values about being accessible to new programmers. There are way more novice programmers using javascript than (almost?) any other language. This isn't an accident.

⬐ tonyedgecombe

>This isn't an accident.

No, it's because it's effectively the only option in the browser. If you are going to write front end code then you will end up writing JavaScript in some form or another.

And being popular doesn't necessarily mean it is accessible nor simple. If it had been I doubt we would have seen Python becoming the dominant language in education.

⬐ josephg

Yep. Python is a dominant language because it also cares a great deal about being easy to learn and accessible to newcomers.

In comparison, C++ does not optimize to be accessible to newcomers. C++ cares a lot more about compiled code running efficiently - as is evident from its insanely complex / powerful templating system. Its hard to learn, but its very powerful. Javascript and Python have nothing like that because that wouldn't align with the values of those languages.

Python values simple code that runs fast enough over complex code that runs super fast. C++ values code running fast enough, even if the code needs to be more difficult to write to achieve that speed.

The struggle here is that in software, sometimes hedgehog thinking is correct. The discernment challenge isn't in spotting hedgehog thinking and choosing fox thinking instead. The challenge is in figuring out in what domains hedgehogs are right and in which domains foxes are right. Unlike in the arena of politics, in software hedgehogs reap the benefits of deep expertise.

When are hedgehogs right? In the "obvious" stuff:

- You should always use correct indentation in your code

- Document your architecture decisions. Have conversations in your team to get feedback and buy in.

- When practical, try and keep down the number of languages and databases you use. It'll make onboarding easier and it allow the team to build deeper expertise

And so on.

The "relational database advocate" usually isn't making an argument that relational databases are better all the time. They're making an argument that relational databases are the right default, and this particular use case isn't weird enough to justify the cost of learning and deploying something else. They might be right - its extremely difficult to know without taking into account the task at hand and the skills of the team.

My personal take is to think about the values of a piece of software before writing it. How much should your project care about maintainability, or scalability, or accessibility (ie onboarding)? Then make your technology choices with that in mind. If actually, short term team velocity is the most important thing, skip automated UI testing. If your team's ability to hire developers in 5 years is really important, use React and not the javascript framework of the week.

Bryan Cantrill gave an excellent talk on this a few years ago, talking through the values different and systems encapsulate. Its an excellent talk:

https://www.youtube.com/watch?v=2wZ1pCpJUIM

Bryan Cantrill explains a very interesting thought about that here: https://youtu.be/2wZ1pCpJUIM?t=1420

I'm sure there are many other factors that play into this (just look at Gary Bernhardt's "WAT" talk), but essentially, I agree that this has to be a big part of the problem. If you've been developing backend systems and asked to hold up robustness and stability guarantees for multiple years and then run into Javascript, you will likely run into situations where you have to make up for its deficiencies in that regard.

That doesn't make it a bad language per se -- that's the case with any language in some aspects -- but since JS will be a new language to you, you're much less likely to accept that situation as a given.

The real cost to my client was that for months or years their system had been crashing, and they could do nothing about it. They just had to live with it, rerunning jobs that had crashed. Maybe the compile times would have been unfortunate, but I think they would have come out ahead. On the other hand, they probably wouldn’t have had to hire me.

Speed isn’t everything: https://www.youtube.com/watch?v=2wZ1pCpJUIM

⬐ ncmncm

I watched it (at 2x, 17 mins): The enthusiasm of the convert.

Values are in tension, but time is fungible. When you add up hundreds of hours waiting for very, very, very slow builds, you should wonder if maybe those hundreds of hours would be better spent elsewhere. If you have traded them for two hours of debugging, have you come out ahead?

(Is there any objective reason for the Rust compiler to be two orders of magnitude slower than a normal compiler? Maybe an alternative implementation strategy would help?)

It was telling when he posted his "values" of C++. Suffice to say, when you need to lie to make your case, the argument is already lost.

Your client lived with crashes because they couldn't be bothered to use valgrind, to use the address sanitizer, to use the UB sanitizer, to set a watchpoint in gdb? They didn't need rr.

There is no substitute for competence. If they had been competent to (re-?)write it in Rust, they would be more than competent to spend 0.1% as much time just fixing it, or (better) not coding the bug in the first place. But who could they hire to code it in Rust? There are orders of magnitude too few Rust coders for that to work.

Rust might be a way not to code bugs in the first place, but modern C++ is another way. It doesn't pretend to make bugs impossible, as Rust pretends, but it does remove temptation to bugs: bug-prone code is ugly, and better ways are equally fast. And, modern C++ is mature, fun, fast building, and can "#include" C headers for essential libraries unchanged.

⬐ db48x

People frequently overstate the slowness of the Rust compiler. Sometimes it’s slower than you’d like, but when you investigate you find that you are doing specific things that are really hurting your compile times. Rust’s procedural macros are powerful, but can turn out to be surprisingly expensive. Breaking your code up into smaller crates can have an unexpectedly large beneficial effect on compile times as well. Etc.

Contrast this with C and C++ where the compile time for a large project is often dominated not by the compiler itself, but by running the linker at the end. For the project I mention here, a full rebuild took over an hour, with the linker taking a few minutes of that. A partial build, when you have changed only one file, took several minutes. Running the compiler on the one file that you changed took just a second or two, but running the linker takes the same amount of time in either case.

But yes, they certainly could have saved time and money if their builds had been faster.

> It was telling when he posted his "values" of C++. Suffice to say, when you need to lie to make your case, the argument is already lost.

Which value or values of C++ do you think he got wrong?

> There is no substitute for competence.

This is true, but I suspect that we disagree on the definition of competence. In my experience, using any of these tools, ever, puts you in a better situation than most programmers. Of course, programmers that use safe languages never need to run Valgrind, UBSan, or similar tools (because the language takes care of memory safety for them), so they’re ahead of the pack as well. But I would bet that 90% of programmers have never used a profiler either. I don’t think that we can call 90% of programmers incompetent simply because they’ve never used a profiler.

You might even say that even the existence of tools like Valgrind and UBSan is a pretty strong condemnation of C and C++.

The reason I recommend learning rr is not merely because it can help you find memory safety bugs in your C++ programs. If all you want to do is that, then there are other more specialized tools that will do the job.

rr is a _general purpose_ tool. It is a debugging system that has powerful features that can be used to debug _any_ problem your program exhibits. I did not at the time know that this bug was due to memory corruption. (Obviously since it was an intermittent crash in a C++ program, it was pretty high on my list of suspects.) I didn’t know that they had never run valgrind on the thing either. But because rr is a general purpose tool, I didn’t need any more information about the nature of the problem in order to find the bug and fix it.

I think that these powerful features should and eventually will be available in every debugger. Do you use pdb to debug your Python code? Then pdb should be able to record a Python program and replay that recording for debugging. Do you use your browser’s dev tools to debug Javascript? Then you should be able to trace the data flow of a value backwards in time to where it originated. Do you use desed to debug your sed scripts? Bashdb? Edebug? All of them will gain these features eventually. In the mean time, people should learn rr.

⬐ ncmncm

The need for valgrind etc. is indeed a black eye for C. But, as I said, I have not found occasion to use it on C++ code.

Certainly there is plenty of C code, and also plenty of bad and un-modern C++ code, that could benefit from these tools. There is not much Rust code in existence. Imagine running the Rust compiler just once over an amount of Rust code commensurate with those bodies. How many core-millennia would that take? The mind boggles.

Familiarity with essential tools is certainly a prerequisite for competence. One who has not used a profiler might never have been asked to make a program faster. One who has not used valgrind uses some other means to discover the causes of problems; if they spend notably more time than using valgrind or other tools would have needed, that would mark incompetence.

It seems like rr could save many people a great deal of time. It would not have saved me much, this past decade, because it could save no more time than I did spend tracking down proximate causes of trouble.

In general, it is always much better to achieve correctness by construction, using tools that only produce correct or, at worst, easily diagnosed results. Such a toolset might include a compiler alone, but I have found a powerful language that enables good libraries, and such good libraries, yield the same benefit. You need good libraries anyway.

> Which value or values of C++ do you think he got wrong?

Srsly?

I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job.

Admittedly I've never done serious work with mypy (or typescript), so I'm approaching the value proposition of dynamic typing at face value rather than experience. However, it seems like the primary benefit of these languages was ease and flexibility, ableit at the cost of structure. Or said differently, adding mypy feels like trying to get out of a trade-off decision.

This situation reminds me of a talk Bryan Cantrill gave on platform core values, and as examples he gave his interpretation of the platform core values of languages like C, Awk, and Scala: https://youtu.be/2wZ1pCpJUIM?t=349

For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with.

⬐ mixmastamyk

Projects tend to change over their lifetime. What might have been yesterday's freewheeling experimental prototype is tomorrow's boring mission-critical geriatric legacy. Sometimes this is (or should be) known in advance, but often not.

⬐ lmm

Which is why recent language design has converged on sound typing augmented by powerful type inference, so that you can use the same language at any scale. I've worked on ten-line database migration scripts and million-line applications in the same Scala.

⬐ mixmastamyk

As I have in Python. It has issues at the high end, but with tooling they can mostly be overcome. It could be better, but I'm not complaining.

On the other had we have: https://news.ycombinator.com/item?id=26539508

Sounds like not everything in Scalaland is sunshine and roses.

⬐ konschubert

Sometimes you know in advance, but you still want to optimize for starting and not for maintaining.

⬐ coldtea

>I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job.

Static typing is not a job though. It's a language feature. The job is solving technical/business problems.

And Python is a tool, but it's not a tool to do dynamic typing or static typing with, it's a tool to solve problems with.

So, the comment "if you want static typing, you're better off recognizing that python is not the right tool for the job" doesn't quite sit right.

You could instead better say that it's not a good fit for Python.

But why would that be?

Especially since one could easily have said the same for Javacript, but Typescript exists as basically Javascript + types, and people seem to love it.

So there's that.

⬐ gostsamo

Javascript has no real competition. People have accepted its existence as a given so every improvement over it is celebrated. On the other hand, many languages want to be the new python and their fans will try to bring it down at every opportunity.

Note: I'm a python dev, yet even I can agree that the python ecosystem is broken and if not maintained, the language will decline over time.

⬐ lmm

Typescript a) is just plain a lot better than mypy b) is still a poor experience compared to using a first-class typed language.

The extent to which a) is due to implementation decisions made by typescript/mypy vs being due to inherent differences between Javascript and Python is arguable. Certainly there are things that look like unforced design errors in mypy, and the fact that Dart existed (and largely failed) before Typescript shows that it's not just about what language you're based on. But there are also idioms and aspects of the Python object model that seem inherently hard to type nicely, and are sadly too entrenched in the ecosystem to change.

⬐ egeozcan

> Typescript (...) is still a poor experience compared to using a first-class typed language.

I personally don't agree. I have coded in C# and TS extensively, and while first-class types available in runtime (especially with generics <cough>though not in java</cough>) is super nice, I think the benefits of looseness of TS overweight the costs. Also, you can always go crazy and use zod or io-ts, but in that road there's always the danger of just writing types and not doing any work because "typing is fun"(c).

⬐ lmm

I spent a couple of days trying to make an app work in typescript before thinking "I'll just give Scala.js a quick try, not going to spend a lot of time on it", and to my surprise everything just worked perfectly.

⬐ egeozcan

I'm happy to hear that, even though I'd personally refrain from getting myself into a Scala codebase again :) (IMHO, it goes further in the "typing for typing's sake" direction). Because of my existing skills I'd probably use Blazor, if I'm going that way.

⬐ freeone3000

What's the equivalent for numpy? Tensorflow? Pytorch? The python library support is simply unmatched: regardless of what the base language has as features, the proper choice for many projects is python.

⬐ scudd

I think that consideration of libraries is a good point, I didn't initially consider, and especially relevant for Python.

I think the one connection I'd make back to my original point is that perhaps python becoming the defacto interface for certain libraries is still a reflection of its core values.

This is especially evident with libraries like Tensorflow, which have interfaces for a breadth of languages, and which the core is implemented in C++. The reason people tend to reach for python to call into Tensorflow is still the core platform values of ease of use, rapid prototyping (imo).

⬐ dragonwriter

> I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job.

If the one and only thing you want is static typing, sure.

That's, like, never the case in programming, so it's not really meaningful, though.

In real world programming scenarios, you are always dealing with balancing multiple dimensional problems and “python, with some degree of static typing” is a reasonable component of the solution for lots of them.

> Or said differently, adding mypy feels like trying to get out of a trade-off decision.

No, considering python’s available static type checking (whether mypy, pyright, or whatever, or even a combination) is turning a big coarse trade-off decision into one with finer-grained options, not avoiding it.

> For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with.

IME using Python’s typing, usually incrementally added, it's not particularly. In fact, it's an enhancer to velocity as the code base evolves.

⬐ SatvikBeri

Python is one of my least favorite languages, but it is a language I absolutely have to use for data work – it would be impractical to rewrite everything in Julia.

Type annotations help a lot. They're not perfect, but for long-running jobs it's a huge help to catch something when PyCharm highlights it instead of 30 minutes into the job.

⬐ dreamer7

I'm curious to know what makes it one of your least favourite languages. Could you elaborate?

The reason I'm interested is because I love python and would like to hear differing opinions

⬐ SatvikBeri

Sure! Broadly speaking, I think Python emphasizes a combination of features that lead to code that isn't very composable or decoupled, but without the error-checking benefits you might get in a language like Scala.

For example, consider implementing complex rational numbers. If you have a complex number type, and a rational number type, it should be relatively easy to combine them. Julia does this with literally 11 lines of code in Rational.jl, and 0 lines of code in Complex.jl . In Python, this is extremely difficult, to the point that nobody does it – you would need to restructure the class hierarchy, and you can't do that without access to both.

Another example is the lack of extension methods. For example, if you want to add a bit of functionality to a string or a sqlalchemy engine, you can either add functions (which have a different syntax) or inherit and follow the awful "MyString" pattern.

Python chose to emphasize list comprehensions over map + filter. The problem with that is that you now have syntax that doesn't generalize to other collections, especially custom collections.

Some patterns like async/await, decorators, and with syntax encourage hardcoding decisions when writing a function, as opposed to when using it. This makes your functions less flexible and means you have to write more of them. E.g. consider Julia's do-block syntax[1], which is very similar to Python's with but based on function composition and far more general as a result. Or compare Julia's @spawn to Python's async/await.

[1]: https://docs.julialang.org/en/v1/manual/functions/#Do-Block-...

⬐ dragonwriter

> For example, consider implementing complex rational numbers. If you have a complex number type, and a rational number type, it should be relatively easy to combine them. Julia does this with literally 11 lines of code in Rational.jl, and 0 lines of code in Complex.jl . In Python, this is extremely difficult, to the point that nobody does it

It's really not difficult; yes, it's more verbose, sure.

> Python chose to emphasize list comprehensions over map + filter. The problem with that is that you now have syntax that doesn't generalize to other collections, especially custom collections.

Python has map/filter/reduce and they work fine. Comprehensions (and genexps) are more concise and cleae for 95% of use cases, I find, so I think the right choice was made there, though I do think people do tend to reach for them sometimes when map, filter, and friends are more appropriate.

> consider Julia’s do-block syntax[1], which is very similar to Python's with

It's more similar to Ruby’s block notation than Python with; it constructs an anonymous function and passes it to another function being called. It is true that with multiline lambdas at all, much less a convenience notation for passing them to other functions, with notation would be superfluous.

> Or compare Julia’s @spawn to Python’s async/await.

Why? They solve different problems. @spawn is equivalent to Python’s concurrent.futures.submit, and it’s buddy fetch() is concurrent.futures.Future.result(). Python has had those longer than it has async/await.

⬐ SatvikBeri

> It's really not difficult; yes, it's more verbose, sure.

Can you point to a case where it's actually been done? I don't even see how you would do it in Python without modifying the standard library or reimplementing significant chunks of cmath.py or fractions.py . In languages like Julia or Haskell this is possible (and relatively easy) as a third party who's just importing the two types.

> Python has map/filter/reduce and they work fine.

Python's map has a few problems, e.g. crippled lambdas make it less useful and it returns a map object instead of the same type as the original collection. It's better than nothing, but it's noticeably weaker than map in other languages.

> Comprehensions (and genexps) are more concise and cleae for 95% of use cases, I find, so I think the right choice was made there, though I do think people do tend to reach for them sometimes when map, filter, and friends are more appropriate.

One big use case where it doesn't apply is numpy arrays or pytorch tensors. It's very common, at least in my domain, for people to initially write code with lists and then switch to arrays for performance. But despite the fact that they should have mostly the same interface, this requires lots of little syntax changes and it's easy to introduce a bug.

Haskell has this issue too to some extent, linked lists are the default data structure and `map` doesn't work with others, you need `fmap`.

> It's more similar to Ruby’s block notation than Python with; it constructs an anonymous function and passes it to another function being called. It is true that with multiline lambdas at all, much less a convenience notation for passing them to other functions, with notation would be superfluous.

Good point.

> Why? They solve different problems. @spawn is equivalent to Pythons submit from concurrent.futures, and it's buddy fetch() is Future.result(). Python has had that longer than async/await.

I do like concurrent.futures, but most blog posts, documentation etc. recommend using asyncio when either one would work, and the majority of libraries at this point use asyncio. I don't think it's really possible to avoid asyncio at this point.

⬐ dragonwriter

> I don’t even see how you would do it in Python without modifying the standard library or reimplementing significant chunks of cmath.py or fractions.py

If I understand the problem correctly, and you are trying to implement Gaussian Rationals, you’d inherit from numbers.Complex, storing the real and imaginary parts as instances of numbers.Rational (you could use the concrete fractions.Fraction, but I don’t think you actually would need to reference the concrete type to do the implementation.)

There’s a bit of boilerplate isinstance-stuff implementing the operations, which is somewhat tedious, but not difficult (I think its less involved than the custom integral class used as an example in the numbers module documentation, because you should be able to get by only handling same-class, Rational, and Complex cases for most ops.

> One big use case where it doesn’t apply is numpy arrays or pytorch tensors.

Good point. It is not one I’ve hit a lot because of the stuff most of python code use is on doesn’t hit those, but I’ve seen that.

> I do like concurrent.futures, but most blog posts, documentation etc. recommend using asyncio when either one would work, and the majority of libraries at this point use asyncio. I don’t think it’s really possible to avoid asyncio at this point.

⬐ bryanrasmussen

When programmers have learned a particular language really well and they encounter a problem the language does not handle well it is usual for them to want to add some capability to the language to handle their problem rather than going off and learning a new language, often because the constraints of time does not let them learn the new language.

There is a tendency to think of pragmatism as throwing away core values in order to solve a problem, although generally this is in the use of the word pragmatism in the domains of business or politics and not in the domain of programming language extensibility.

⬐ strken

I can't talk about python, but it's convenient to be able to cast something to any in typescript and get all the flexibility of javascript, but also have the rest of your code type checked if you want it. Statically typed languages usually don't let you mix-and-match static typing with duck typing.

⬐ seanmclo

At this point, another big benefit of Python is its huge number of libraries. This is really attractive to lots of people who also want static type checking.

Oftentimes, the benefits of using Python in a code base that would benefit from static typing outweigh the costs. Especially when tools like MyPy exist, which aren't perfect but help tremendously.

⬐ nradov

Java also has a huge number of libraries, plus static type checking.

⬐ fiedzia

It has many. But I know several companies that move from Java to Python because that's what developers, data engineers and ML/AI experts use.

⬐ nonameiguess

This can't be emphasized enough. I'm presently pushing mypy and type hints hard in a Python project (passing static analysis and type checks is required to get through the CI pipeline) and it's just a compromise. Honestly, I don't want a dynamic duck-typed language at all, but it is what it is. Right now, the single most important factor determining whether we have any future at all is speed to market, not the increased reliability you get from type safety. And Python just has libraries for basically everything. It's enabled us to spin up brand new services that do exactly what we need to do from scratch in a matter of hours sometimes.

With competing priorities like that, this is the best we can do right now. The other factor is the rest of the team is already familiar with Python. They're mostly infrastructure developers. They're more likely to do everything in Bash if given the choice. I'm not going to teach them Scala or Haskell or Rust in the next three weeks before we need to deliver something. But I can at least teach them Python's optional type hints and mypy.

> I can't recall which exact presentation it was, but Bryan Cantrill had a brilliant segment on this in one of them. Perhaps others around here can remember?

I think that's his discussion of language values in "Rust and Other Interesting Things" at Scale By The Bay 2018. https://www.youtube.com/watch?v=2wZ1pCpJUIM

[edit: This talk is also titled "Platform values, Rust, and implications for systems software". I'm not sure which title is preferred.]

⬐ Quekid5

Yup, sounds about right. That was an excellent insight from him.

⬐ brohee

Slides: https://www.slideshare.net/bcantrill/platform-values-rust-an...