Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.
> Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features.
This is very true and my original post was short sighted. You could, of course, make most upstream dependencies without modern language features. However, their complex jobs get much easier with these features.
Downstream, business logic is much easier to implement without these features compared to complex, low level functionality.
For sure! In a basic API endpoint, I don’t need advanced typescript features.
But if I’m writing a module that a lot of other consumers in the codebase will use, and I want to make their lives easy, I might use a lot of advanced TS features to make sure than type safety & inference works perfectly within the module. Whoever consumes it can then rely on that safety, but also the convenience. The module could have some convoluted types just to provide really clean and correct auto-complete in a certain method. But most people don’t need to worry about how that works
Yeah I was confused by this point as well. Especially because many of the recent Typescript releases are just improving performance or handling more cases (without needing to learn new syntax).
I never said it's required. The typings are really useful if you want to use these libraries "with TypeScript" as I said in my first comment... The typings are the whole point - that's where the advanced type features are used, and every user benefits - their own code can be much simpler and safer thanks to it.
"Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it."
I think your model of how people use modules is flawed.
I doubt most people using those modules are using typescript to mostly interact with them, because of the perceived subjective benefit you see of typing everything.
For example, I use many typescript-written modules without using typescript in the code that uses them, and am better off for it. Because I and my R&D work does not want the advanced features of typescript. We can switch to it, or a OOP server language if that is useful later.
Exposing types to me usefully in libraries to use "with Typescript" as you claim means my own code has to be typescript. In that case, to avoid compile errors and a wall of "any" types, I reasonably have to switch my own code to use Typescript classes etc, even where this is just bloat etc. Another reason I have libraries is to do things without ever interacting with them other than input props (e.g. a drag'n'drop library with JSX components). In that case, the type (JSX Component) is irrelevant to me to include, and for experienced developers, approximately 0% are going to give something other than a JSX component as an input to a drag'n'drop library, etc.
In other words - I derive benefit from them using Typescript without having to use it myself. Pushing Typescript as "necessary" because popular libraries have interfaces is exactly the kind of thing that slows down R&D and fast processes.
I have used many languages with types for many years. I understand their value. However, much of the value is code coherence, working with other people, and domain models being embedded in the code. These benefits are not always useful in small web applications.
Typing is one of those things... you love it to make your life learning code easier and for big projects, and for certainty when you are coding boring things. For other things in life, there's more to life than writing type definitions and overloading methods. You can be much more productive just using primitives in some scenarios and make research discoveries faster and with more flexibility.
What I have seen is every generation of coders, a new type-heavy language/framework becomes popular (.NET, Java, Typescript), then it becomes "uncool" because people realize how bulky and useless most of it is - especially for anything small/research-y, then it loses adoption and is replaced by another.
That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.
I think programmer vs software engineer is one of those semantic things that might sound witty but ultimately has little utility or shared agreement. Job listings use them interchangeably. I call myself a programmer in casual conversation because it's easier and I'd feel kind of pompous saying "software engineer", even though I'm firmly on the "software engineer" side at this point.
And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.
> And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE.
Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal)
I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week.
On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with.
It was meant to be mostly a joke, I agree it's vague and I do the same as you do. Though the point stands - very senior or principal engineers/developers/architects are not there to write code.
A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence.
A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.
Many people forget that laws, as long are not the laws of physics, are man-made. And as such, they can be changed at will to fit whatever scenario is convenient.
Nobody (important) wanted that, though. It was done only because the cloud wasn't available, the moment it became available every big company migrated.
Self-hosting JIRA and Confluence was a double edged sword:
Done badly it meant you suffocated the application server with too little resources giving dreaded "super slow JIRA" effect.
Done well it meant you didn't have to deal with Atlassian underprovisioning resources in the cloud or having rigid maintenance times that didn't fit with your company needs.
I’ve never seen or worked with a company using the cloud version of any of their products. I worked at a place with one of the largest bitbucket installs in the world, so they weren’t little shops.
Not true. I‘ve been at several companies that self host Jira. With the amount of critical data and processes in Jira, it can be comforting to have it on-prem with no one else being able to access the server.
Are you sure they're not just "preparing for the migration" and plan to stay on premise? I also worked at many places that had it on premise - all of them planned to migrate ASAP (where asap is sometimes years).
>That's the job of a government, and why would people fund it through taxes if it doesn't do its job?
Regulation and protection go hand in hand, if you don't want the regulation, you shouldn't be able to ask for the protection that goes along with it. If you want to gamble your real money by converting it to fake digital tokens, that's fine, but you shouldn't ask the government to use taxpayer money bail you out afterwards. If you want government protection for investments, you should invest in schemes that are regulated by the government instead.
It can be registered in Europe, many countries allow individual car import from the US. I have seen a few around; not on public streets (car shows), but with local plates.
You also won't have any issue getting third-party damage insurance in Europe, as the insurance companies are required to make an offer.
I'm aware of single/custom car special procedures, but last I checked the Cybertruck can't get a type approval in any EU country. Individual registering them vs. not being able to register them doesn't really make a difference for the argument, does it?
Honestly I might even have bought a nice electric truck, but that weird box on wheels just ain't it :(
Where do you check if it can get a type approval? I don't think that's something you can easily determine just by looking at it and saying "yeah too big, doesn't look right, not european enough". There are very weird things with type approvals in Europe. Don't mistake it for some super rational land. Note that even mega-trucks can be street legal in Europe, and most traditional American big pickups like Dodge RAM are type approved - why not a Cybertruck then?
Europe will type approve anything that proves it's safe and follows basic conventions. That will most likely include the Cybertruck, as the question really isn't "is this car a good idea?" - even bad products that nobody needs or wants get type approved, and Cybertruck really will not be the worst thing that happened to European roads.
Tesla knows very well how to get a US car type approved in EU with minimal adjustments. It was very curious to watch with previous models. They are quick, too.
> Where do you check if it can get a type approval?
There's an abundance of news articles about Tesla's VP of Vehicle Engineering, Lars Moravy, saying they can't get it due to some 3.2mm exterior radius requirement that is impossible to do on the 1.4mm stainless steel they use:
Well you can have a look at the rules and see for yourself, they are not that weird but very complicated. But I assume that if it would be possible, Tesla would try to get it approved.
> most of the traditional American big pickups like Dodge RAM are type approved - why not a Cybertruck then?
I'd guess pedestrian safety would be one of the main issues.
I know the rules very well, special cars are kind of my hobby. There is nothing that couldn't be minimally adjusted to meet European regulations. Pedestrian safety is definitely not an issue. There are much more unsafe vehicles than Cybertruck in that regard.
Every model Tesla introduced was US only first few years. People individually imported the first hundreds of cars during these initial years. Tesla then introduced an European version of the car with technically minimal adjustments.
Have you been able to find safety statistics for pedestrian collisions? I tried looking them up, but was unable to find any.
Naive comparisons like "the hood is lower" are not enough to make this kind of statement, as the remaining differences (sharp angles and a very different material) are too large to make this determination without actual testing.
Try to look into national government statistics agencies, these might track it. European-wide aggregate that you could trust is probably available only for money.
I haven't been able to find any. What absolutely shocked me is that even in America, apparently there has been no such test done by anyone besides Tesla.
How did you come to your earlier assessment? Did you ignore the differences in material and sharp angles? I'm not well-versed in the area, but it seems more than reasonable that they have an impact on the outcome of pedestrian collisions.
> Pedestrian safety is definitely not an issue. There are much more unsafe vehicles than Cybertruck in that regard.
Purely out of curiosity — can you name one or two such vehicles? I'm really interested how they are so unsafe, or rather, which byzantine (non-?)regulation deems them so unsafe :D
My point is that there is no such regulation. But anything that used to be military and sold to civilian usage would qualify. Very common in Eastern Europe, though most of the vehicles of the Cold War have rusted by now.
Are you sure there is no such regulation? We are talking about type approval, not individual registration, and the EU Reg 2019/2144 says:
Regulation (EC) No 78/2009 of the European Parliament and of the Council (9) sets out requirements for the protection of pedestrians, cyclists and other vulnerable road users in the form of compliance tests and limit values for the type-approval of vehicles with regard to their front structure and for the type-approval of frontal protection systems (for example, bull-bars). Since the adoption of Regulation (EC) No 78/2009, technical requirements and test procedures for vehicles have developed further at UN level to take account of technical progress. UN Regulation No 127 laying down uniform provisions concerning the approval of motor vehicles with regard to their pedestrian safety performance (‘UN Regulation No 127’) currently also applies in the Union in respect to type-approval of motor vehicles.
As you are fully aware, it does not imply any bull bars can be type approved (and there are a lot less such new cars as there were in the 90's and 00's in our country).
So:
1) the regulation you said does not exist does in fact exist,
2) it may be one of the reasons the Cybertruck is not yet type approved.
Time will tell, if and when Tesla manages to register it, possibly with some changes to the construction. Or it will deem the EU market too small for that.
What do you mean, by now? The only one who can do so is Tesla. Cybertruck is barely being sold in the US. It always took a few years before Tesla introduced an European version of a car. It's way too early to tell.
Yeah, Sorry, I worded that poorly. Can you give an example of a car that is more unsafe (by some generic reasoning) than the Cybertruck, but still type approved?
If the car model has CoC number, it has been type approved. EU keeps approval register. The CoC is not limited to EU It works in every European country.
Tesla has announced that they are in process of making Cybertruck version that complies with EU regulation, but Cybertruck is hard to adjust. Lack of crumple zones is a big issue.
Getting it approved as commercial vehicle should not be a problem, but nobody wants that. Not Tesla, and not the consumers.
I actually would consider an EV pickup truck. My uses for a truck are almost entirely local, so range concerns would be much less. EVs are still too expensive for me however. For now when I need to haul something that won't fit in my car, I rent a trailer.
Rivian’s are kind of nice, but I don’t know if they will survive as a company. Ford EV trucks are fine as well, I’ve driven both. I personally own a hybrid plug-in SUV which lets me go as far as I like on vacation while also letting me be pure EV for all my local driving which is probably 90% of it and I really don’t drive that much tbh
Some countries effectively have exactly that: There are "baby boxes" on the public facing walls of hospitals where you can put a newborn (sometimes older children too) and walk away, no questions asked. The child is assigned a name and put into social care together with other people who have no parents or other guardians.
Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.