Readit News logoReadit News
tristanstcyr commented on Apple Silicon M1 Chips and Docker   docker.com/blog/apple-sil... · Posted by u/austinprete
vbezhenar · 5 years ago
What the point of docker if you can't just run single binary everywhere? That was its promise, right?
tristanstcyr · 5 years ago
I don't think that doing so across architectures is a major goal.
tristanstcyr commented on Announcing TypeScript 3.9   devblogs.microsoft.com/ty... · Posted by u/munchor
kuschku · 6 years ago
Half of the changes are due to the language server implementing refactoring and other similar stuff.

This shows clearly why the language server protocol is such a bad design decision and so broken — every language has to implement it itself, and there are no shared features or functionality across languages.

Coming from IDEA, where the exact same refactoring functionality and features work no matter if using typescript, kotlin, Rust, C#, golang or dart, exactly identical in all ways, this has been a huge issue for myself.

Languages Servers should just expose a clean standardized AST format, representing standardized nodes, and this should in turn allow the IDE to act upon this (which would immediately be represented in changed source).

tristanstcyr · 6 years ago
Language servers could still do this by reusing AST manipulation libraries behind the scenes.
tristanstcyr commented on We are not mostly empty space   medium.com/starts-with-a-... · Posted by u/yusufk
sporkologist · 6 years ago
> Inside your body, you aren’t mostly empty space. You’re mostly a series of electron clouds, all bound together by the quantum rules that govern the entire Universe.

So we are mostly electron clouds... and clouds by definition are mostly empty space.

tristanstcyr · 6 years ago
From what I understand, the idea of "empty" no longer makes sense at that level. All you have are fields. There, everything is made out of fields and fields are everywhere. There is therefore no "empty" really anywhere, including inside yourself.
tristanstcyr commented on Ride down into JavaScript dependency hell   blog.appsignal.com/2020/0... · Posted by u/nikolalsvk
dmitriid · 6 years ago
I'm not buying the narrative of "js dependency hell what are they thinking" anymore.

Try installing a package for Rust. Or Go. Or ... any language, really.

tristanstcyr · 6 years ago
I agree that this isn't totally specific to JavaScript. It's just that the ecosystem is very extensive and so there are a lot of packages, because you don't need to write your own code for a lot of existing problems.

There is perhaps a something about the JavaScript audience tending to attract less advanced implementers. So you end up with a lot of otherwise considered trivial and low-quality utilities being published and pulled down from the registry.

Rust and Go tend to be for more advanced scenarios where things like performance, security and support matters tremendously.

tristanstcyr commented on Ride down into JavaScript dependency hell   blog.appsignal.com/2020/0... · Posted by u/nikolalsvk
parhamn · 6 years ago
What’s worse is that the whole installing multiple versions of the same package for different sub dependencies doesn’t make any sense when when the language supports singletons and module level variables with has no way of specifying which version to import.

I was shocked this behavior exists when a site broke by upgrading a sub dependency. Turned out they both installed react so they used a different “creatContext” and now there were two context instances instead of one.

tristanstcyr · 6 years ago
React would normally be a peerDependency and so you shouldn't run into this problem if dependencies are specified properly.

If not, NPM module flattening should take care of it.

Then worst case, you can also tell webpack to bundle a specific installation.

There are some ways to solve these problems...

tristanstcyr commented on How porting to TypeScript solved our API woes   executeprogram.com/blog/p... · Posted by u/mrbbk
jjeaff · 6 years ago
That's not true. There are plenty of cases where certain pieces of software is cordoned off and/or non-critical that would not affect the rest of your stack if they fail.
tristanstcyr · 6 years ago
If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.
tristanstcyr commented on How porting to TypeScript solved our API woes   executeprogram.com/blog/p... · Posted by u/mrbbk
lmm · 6 years ago
Does Typescript actually add runtime checks, even for e.g. container types? I'd be very surprised if it did, because that would mean a lot of overhead.
tristanstcyr · 6 years ago
It does not.
tristanstcyr commented on Java 14 Feature Spotlight: Records   infoq.com/articles/java-1... · Posted by u/chhum
fctorial · 6 years ago
At first I thought it was project valhalla merging into mainline java. Apparently this is a java language feature. Java is starting to move away from being the C of jvm. Java constructs are no longer direct mappings of jvm constructs.
tristanstcyr · 6 years ago
I think that this ship has sailed quite some time ago. For example, inner classes which were introduced in Java 4 (if my memory serves right).
tristanstcyr commented on The real world is mutable – consequences for system design   utcc.utoronto.ca/~cks/spa... · Posted by u/ash
virgilp · 6 years ago
> The first is that sometimes people make mistakes and publish things that they very strongly wish and need to change or retract. Pretending that they do not is ignoring reality.

Really? I'd say regardless what their wishes might be, pretending that they can is ignoring reality (at least in some cases). You change or retract things as you do in accounting - by issuing amendments. Not by pretending you never published something, but by updating what you published (i.e. publishing a new version).

> Beyond that, things in the real world are almost always mutable and removable because lawyers can show up on your doorstep with a court order to make them so, [...] If the court says 'stop serving that', you had better do so.

How does that have anything to do with immutability? Immutability is not "The president is Obama", it is "At 01 Feb 2020 my belief was that at 01 Feb 2016 the president was Obama". You can trivially say that "At 01 Feb 2020 my belief was that at 01 Feb 2020 the president was Trump" without contradicting the previous statement. You can even forget what your belief was at 01 Feb 2020. And if the ministry of truth knocks on the door, you might end up to believe, at 01 Feb 2025, that at 01 Feb 2016 the president was Trump. This way, you satisfy the ministry's desires, without violating immutability in any way.

tristanstcyr · 6 years ago
That's an idealistic argument. Sometimes you just need to delete things and there's no negotiation possible.

Whether that makes sense to you or not as an engineer or scientist doesn't matter much. There are tons of things that humans want that "don't make sense" but that you need to conform to regardless. A great example of this is typically the law.

tristanstcyr commented on Writing Safe Shell Scripts (2019)   sipb.mit.edu/doc/safe-she... · Posted by u/rrampage
kick · 6 years ago
Shell scripts are readable by just about anyone, they're available on every UNIX system, not just the Red Hat/Debian-derivatives of the last twenty years, they're fast as long as you're not doing stupid things, they're easily maintainable, they don't handle dependencies terribly (unlike Python), and so forth.

There's a reason AT&T used to run ads that showed their secretaries, managers, and so on using and writing shell scripts and there's never been a Python ad claiming that just anyone could write it.

tristanstcyr · 6 years ago
Is this because both languages are from different eras? When did you last see a consumer ad about scripting?

u/tristanstcyr

KarmaCake day90April 17, 2016View Original