Why do you say it needs more time in the oven? I’ve had zero issues with it as a drop-in replacement for Pip in a large commercial project, which is an extremely impressive achievement. (And it was 10x faster.)
I tried Poetry once and it failed to resolve dependencies on the first thing I tried it on. If anything Poetry needs more time in the oven. It also wasn’t 10x faster.
I don’t think libuv is really that popular, nor is it that confusing.
But I do agree it’s not a very good name. “Rye” is a much better name. Probably too late anyway.
Yes it’s terrible. The only hope on the horizon is uv. It’s significantly better than all the other tooling (Poetry, pip, pipenv, etc.) so I think it has a good chance of reducing the options to just Pip or uv at least.
But I fully expect the Python Devs to ignore it, and maybe even make life deliberately difficult for it like they did for static analysers. They have some strange priorities sometimes.
There’s also CPC/Farnell but none of those are in the same league as McMaster Carr. Much smaller ranges, worse prices, worse websites, missing CAD models, etc.
Another option is Misumi but they have even worse prices and don’t even sell to individuals.
I’d recommend going to McMaster Carr just to see what we are missing out on.
I wish we had something like McMaster Carr in the UK. I don’t even care if it’s fast! You guys had better appreciate how good you’ve got it.
Well they still have runtimes, but yes they can be pretty minimal.
You’re still shipping a load of libraries that come for free with JS though, e.g. with Rust WASM string formatting and unicode support always ends up being annoyingly huge, and that’s built in to JS engines. There’s also collections (Map, Set), etc.
I don’t think so - Javascript doesn’t have to ship its language runtime so it will always have a size advantage.
The is operator is for identity, not equality. Your example is just using it weirdly in a way that most people wouldn’t do.
The + operator is for numbers or strings, not arrays. Your example is just using it weirdly in a way that most people wouldn’t do.
I’m not defending Javascript’s obviously terrible behaviour there. Just pointing out that Python has obviously terrible behaviours too. In both cases the solution is “don’t do that, and use static analysis to make sure you don’t do it accidentally”.
Sometimes I meet junior developers who have only ever used javascript, and it’s like (to borrow another contentious nerd topic) like meeting someone who’s only ever played D&D talking about game design.
Yeah I think you can generalise that to “have only ever used one language”. I would say Python and Javascript are pretty close on the “noob level”. By which I mean if you meet someone who has only ever written C++, Java, or Rust or whatever they’re going to be a class above someone who has only ever written Python or Javascript.
Why would you use the is operator like that?
Why would you add two arrays like that?
Do you not use containers when you deploy
No because I am not using Python to make a web app. That’s not the only thing people write you know…
JavaScript is so bad you’ve resorted to using a whole other language: Typescript
Well yeah. Typescript isn’t really a new language. It’s just type annotations for JavaScript (except for enums; long story). But yes JavaScript is pretty bad without Typescript.
But Typescript isn’t a cop-out like Docker is.
But the language it’s built on top of it is extremely warty. Maybe we agree on that.
Yeah definitely. You need to ban the warts but Typescript & ESLint do a pretty good job of that.
I mean I would still much rather write Dart or Rust but if I had to pick between Typescript and Python there’s absolutely no way I’d pick Python (unless it was for AI).
Well, indeed. Unfortunately there are still a fair number of them. The situation is definitely improving at least.
In fairness that approach hasn’t really worked in other languages. It was so unpopular in C++ that they actually removed the feature, which is almost unheard of. Java supports it too but it’s pretty rarely used in my experience. The only place I’ve seen it used is in Android. It’s unpopular enough there that Kotlin doesn’t support it.
I have never seen a single C++ codebase do that. It helps but it’s not a practical full solution.
I dunno if you’re being deliberately obtuse, but just in case you really did miss his point: the fact that type hints are optional (and not especially popular) means many libraries don’t have them. It’s much more painful to use a library without type hints because you lose all of their many benefits.
This obviously isn’t a problem in languages that require static types (Go, Rust, Java, etc…) and it isn’t a problem with Typescript because static types are far more popular in JavaScript/Typescript land so it’s fairly rare to run into a library that doesn’t have them.
And yeah you can just not use the library at all but that’s just ignoring the problem.
A sane language, you say.
Yes:
Operator '+' cannot be applied to types 'number[]' and 'number[]'.
We’re talking about Typescript here. Also I did say that it has some big warts, but you can mostly avoid them with ESLint (and Typescript of course).
Let’s not pretend Python doesn’t have similar warts:
>>> x = -5
>>> y = -5
>>> x is y
True
>>> x = -6
>>> y = -6
>>> x is y
False
>>> x = -6; y = -6; x is y
True
>>> isinstance(False, int)
True
>>> [f() for f in [lambda: i for i in range(10)]]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
There’s a whole very long list here. Don’t get be wrong, Python does a decent job of not being crazy. But so does Typescript+ESLint.
I’ve worked professionally in python for several years and I don’t think it’s ever caused a serious problem. Everything’s in docker so you don’t even use venv.
“It’s so bad I have resorted to using Docker whenever I use Python.”
Well == is a question or a query rather than a declaration of the state of things because it isn’t necessarily true.
You can write
a = (3 == 4)
which is perfectly valid code; it will just set a to be false, because the answer to the question “does 3 equal 4?” is no.
I think you’ve got it anyway.
Ok after reading the article this is bullshit. It’s only because they are counting JavaScript and Typescript separately.
Typescript is far nicer than Python though. Well I will give Python one point: arbitrary precision integers was absolutely the right decision. Dealing with u64s in Typescript is a right pain.
But apart from that it’s difficult to see a single point on which Python is clearly better than Typescript:
uv is a shining beacon of light here but I have little hope that the upstream Python devs will recognise that they need to immediately ditch pip in favour of officially endorsing uv. No. They’ll keep it on the sidelines until the uv devs run out of hope and money and give up.They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.
Yeah it’s confusing because in maths they are the same and use the same symbol but they are 100% not the same in programming, yet they confusingly used the same symbol. In fact they even used the mathematical equality symbol (=) for the thing that is least like equality (i.e. assignment).
To be fair not all languages made that mistake. There are a fair few where assignment is like
x := 20
Or
x <- 20
which is probably the most logical option because it really conveys the “store 20 in x” meaning.
Anyway on to your actual question… They definitely aren’t the same in programming. Probably the simplest way to think of it is that assignment is a command: make these things equal! and equality is a question: are these things equal?
So for example equality will never mutate it’s arguments. x == y will never change x or y because you’re just asking “are they equal?”. The value of that equality expression is a bool (true or false) so you can do something like:
a = (x == y)
x == y asks if they are equal and becomes a bool with the answer, and then the = stores that answer inside a.
In contrast = always mutates something. You can do this:
a = 3
a = 4
print(a)
And it will print 4. If you do this:
a = 3
a == 4
print(a)
It will (if the language doesn’t complain at you for this mistake) print 3 because the == doesn’t actually change a.
It does still have a traditional assignment operator. You can assign values to mutable variables.
Also I would say let-binds are still pretty much assignment; they just support destructuring. Plenty of languages support that to some extent (JavaScript for example) and you wouldn’t say they don’t have assignment.
I don’t think it affects the ability to overload = anyway. I think there aren’t any situations in Rust where it would be ambiguous which one you meant. Certainly none of the examples you gave compile with both = and ==. Maybe there’s some obscure case we haven’t thought of.
Totally depends what you end up working on as a programmer. If it’s web apps, you’ll be totally fine. All you need is basic arithmetic. Writing a game engine? You’ll need to know some basic to moderate matrix maths…
If you’re doing formal verification using unbounded model checking… good fucking luck.
On average I would say most programming tasks need very little maths. If you can add and multiply you’ll be fine. Definitely sounds like you’ll be ok.