Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
jjnoakes
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
55 ms
·
751.
▲
by
jjnoakes
9y ago
> in dynamic languages given they're more of a necessity Sounds like you came around. > No Not everyone agrees that dynamic languages lead to faster velocity. Velocity is a function of many things (environment, culture, tooling,
752.
▲
by
jjnoakes
9y ago
> Tests are essential to software quality and static typing does not absolve you from writing tests. No one said they did. You have to write fewer tests with static typing, not zero tests. > My proposition was that dynamic languages o
753.
▲
by
jjnoakes
9y ago
> Your comments are full of snide comments against dynamic languages They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue. Half or more of
754.
▲
by
jjnoakes
9y ago
> Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality. What I suggested, if you go back and read my initial comme
755.
▲
by
jjnoakes
9y ago
> I've not once mentioned my preference. That's fine, no one was talking about you specifically. > I'm not naive enough to think everyone would be better off developing in C# That's good. Neither am I, so I'm
756.
▲
by
jjnoakes
9y ago
> other developers have their own language and tooling preferences Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type e
757.
▲
by
jjnoakes
9y ago
Mose developers are average developers. If I have an average developer writing my mvp or adding user-defined features, I'd rather have a static type system to save them time. Otherwise they have to write more tests or fly by the seat o
758.
▲
by
jjnoakes
9y ago
A static language is less likely to throw a runtime type error, or coerce some value incorrectly, than a dynamic language. That does correlate with being unstable and offline. Servers don't drain battery, but they cost money, so ineffi
759.
▲
by
jjnoakes
9y ago
End users absolutely care when the program or service is slow, unstable, drains your battery, is constantly offline, or has major security flaws. Now there is no guarantee that a dynamic language will have those issues more than a static la
760.
▲
by
jjnoakes
9y ago
If you want a job at McDonald's, you should be aware that they don't serve whoppers :)
761.
▲
by
jjnoakes
9y ago
I don't think "people will pay for <thing>" is justification for "any university that doesn't do <thing> is horrible".
762.
▲
by
jjnoakes
9y ago
In your example, he was charging for the service, which was against the terms of use of the web site he was scraping. So in general, do be sure to not violate a site's terms, but I don't see what that point has to do with your fin
763.
▲
by
jjnoakes
9y ago
I don't follow. If I configure me.example.com to accept emails matching the pattern "me<anything>mail42@me.example.com", then I can generate as many on-the-fly unique emails as I want, without maintaining any lists, and
764.
▲
by
jjnoakes
9y ago
Glad to hear there's work in progress. Last time I tried to configure gcc + gdc on AIX on PowerPC, I found out it was explicitly disabled in the configure script, and I didn't dig any deeper to find out why or the potential work i
765.
▲
by
jjnoakes
9y ago
Yes, understood. What I don't know is how much D-specific work is needed in the gcc backend per-target-triple. If it's a small amount of work, and the only thing really preventing it is wider adoption, this news may be the kick t
766.
▲
by
jjnoakes
9y ago
https://dlang.org/spec/cpp_interface.html
767.
▲
by
jjnoakes
9y ago
Does this mean D-via-GCC will be supported on more platforms going forward than what is supported today?
768.
▲
by
jjnoakes
9y ago
Some languages throw exceptions if their iterators are invalidated, right? That seems separate from memory safety to me. Or put another way, having memory safety doesn't guarantee iterator safety.
769.
▲
by
jjnoakes
9y ago
That seems like a white pattern to me.
770.
▲
by
jjnoakes
9y ago
This is why you might consider maintaining a white list or white pattern instead.
771.
▲
by
jjnoakes
9y ago
Which complexity in Rust is due to the lack of GC, and not due to, say, the desire for thread safety?
772.
▲
by
jjnoakes
9y ago
The article talked about representing 3 states, and you suggested encoding those 3 states in a way that has the same split-brain issue that the article discussed. You can tell that 4 states doesn't match up with the article based on ho
773.
▲
by
jjnoakes
9y ago
This doesn't avoid the split brain concern completely though: your suggestion has 4 states, and one of them is invalid (picturesLoading: true, pictures: non-empty). If a refactoring or some other edit of the source leads to that state,
774.
▲
by
jjnoakes
9y ago
Are you sure awkward is the worst that can happen? http://www.openwall.com/lists/oss-security/2017/05/01/13 http://www.securityfocus.com/bid/6940/
775.
▲
by
jjnoakes
9y ago
I mean AIX on Power (BE).
776.
▲
by
jjnoakes
9y ago
Of all the architectures I contract for, I think AIX is the one furthest behind as far as LLVM and Rust support goes.
777.
▲
by
jjnoakes
9y ago
I agree, and this is the only thing stopping me from putting rust into production. I have high hopes for something like https://github.com/thepowersgang/mrustc
778.
▲
by
jjnoakes
9y ago
But it reveals part of what was typed in the e2e chat to the third party... tls or not is irrelevant to that point.
779.
▲
by
jjnoakes
9y ago
When both e's in e2e are the parties of the conversation, and the TLS connection is too a third party, then yes it is a violation of their claim.
780.
▲
by
jjnoakes
9y ago
A static analyzer with sufficient inter-procedural analysis (i.e. across the user/kernel boundary) could certainly see the type of the allocated structure in userspace, and flag the kernel read of a larger type.
More ›