t8sr

9 ms·

61.
by t8sr 3y ago
I think there are a few differences. One is call-site flexibility - if I have a function that takes an interface, I can call it without an explicit cast with either an interface or a concrete value. If it returns a concrete value, I can ass
62.
by t8sr 3y ago
>Make it work, make it pretty, make it fast, in that order. And don't optimize without measuring, another trap that many people (present company included) fall into. This view is common nowadays, but I think people need to dial that
63.
by t8sr 3y ago
The article gives some examples about Go, and lists interfaces as something you should use, because the performance cost is tiny. As someone who was formerly involved with the canonical Go style, I wanna clear up the reason why we said you
64.
by t8sr 3y ago
Mantras like these are always a response to something. Someone in charge of technical culture at $PLACE diagnosed specific anti-patterns in their Java code, came up with a set of rules for the noobs and a catchy acronym. Things got better.
65.
by t8sr 3y ago
I’m not sure I agree encouraging inversion of control, more indirection and behavior inheritance is an improvement. In the recommended style of most languages, these are probably big anti-patterns. On the other hand, I never spent that much
66.
by t8sr 3y ago
It’s well known in a specific setting, possibly? I’ve managed to never hear of it in 18 years. If asking “well known to some people” stuff is kosher, should I be able to quiz candidates on FFP design principles in Haskell, or maybe how to i
67.
by t8sr 3y ago
I had to look up what SOLID is, and it kinda goes against most of what we’ve learned about software development since the 90s. When people say they don’t want algorithmic “leetcode” interviews, I wonder if this is the alternative they want?
68.
by t8sr 3y ago
This blog is very much not “media”. The author a pro-Russian Marxist blogger - hardly representative of mainstream news.
69.
by t8sr 3y ago
Not only is this uninformed*, the author’s views are fairly extremist: https://www.nakedcapitalism.com/author/nick-corbishley I don’t think HN should be a platform for this kind of commentary. *As others point out, e.g
70.
by t8sr 3y ago
Interesting - I would be really interested in an apples-to-apples comparison between the two of them, but such a thing must be hard to do. I'd fully expect the amount of investment in JVM to have produced a way better result, but I can
71.
by t8sr 3y ago
As you point out, the use of ARC is correlated with languages used in high-performance code. You think it's because ARC is a better way of managing memory, but that's false. Rust is not fast because it uses ARC, it uses ARC becaus
72.
by t8sr 3y ago
Sorry, but it really sounds to me like you're repeating something from documentation or CS 101. Have you ever actually worked on a garbage collector? * ARC is not deterministic outside of toy examples * The runtime overhead of modern G
73.
by t8sr 3y ago
I think the amount of code you need to maintain and simplicity are orthogonal things. When we say go is simple, what we usually mean is that by looking at a bit of code, it's obvious what it does. There's no way that `x + y` can b
74.
by t8sr 3y ago
In addition to what the other post said, Go also favors simplicity for the programmer. So stack and heap are "unified", a lot of dispatch is virtual and you rely on the compiler optimizing away all the dynamisms and checks. As you
75.
by t8sr 3y ago
You can profile your Go programs and see how much time they spend in the garbage collector. If it's over 20% you probably have a bug. And of course Rust and C also spend time on memory management, it just has the effect of making every
76.
by t8sr 3y ago
I'm still not completely sure who or what ReactOS is supposed to be for. If you want to run Windows applications, Wine on Linux works better. In fact, Wine and ReactOS exchange a lot of code in the user layer anyway, IIRC. Meanwhile, L
77.
by t8sr 3y ago
This is one of the most accomplished people in software development talking to a class of CS students. It’s not entertainment. Have we reached a point where lecturers need to post “hot takes” on Twitter as a prerequisite to keeping people’s
78.
by t8sr 3y ago
You're thinking of Waymo :) Waze is a crowdsourced traffic & maps thing. It's vaguely, if you squint, adjacent. I don't think it would be completely crazy, for example, for Waze to introduce a line of dash cams.
79.
by t8sr 3y ago
Right, that’s another one. I get that the trademark space is pretty dense, but still - trademarks exist to stop consumers getting confused, and this naming really is confusing? Waze could come out with a line of dash cams, and then you&#x27
80.
by t8sr 3y ago
Well, not to split hairs, but it depends on what you mean by complexity. I would describe Python as possibly the most complex programming language in existence - it’s built in terms of a high number of abstractions, many of which are leaky,
81.
by t8sr 3y ago
A little off topic, but how is it possible that a tech startup named itself “Wyze” and didn’t get sued by Google over the “Waze” trademark? In some accents it sounds exactly the same, and they’re sort of in an adjacent product space.
82.
by t8sr 3y ago
I don’t think so - I’ve been in promotion committees to L7 and I feel fairly confident those are examples of L7 impact. Not by themselves sufficient maybe, but they’re the kind of stuff L7 SWEs do with their time. I suppose I have heard tha
83.
by t8sr 3y ago
I have worked on security, databases, some distributed systems, a couple of video games, AR/VR and some ML systems, mostly connected to database and data pipelines. Knowing what the kernel is likely doing underneath has been useful in
84.
by t8sr 3y ago
The expectation that everyone should reach these career levels is easily dispelled by basic math. L6 and EM can by definition exist at a ratio of, at best, 1:6 to the people at more junior levels. Most engineers might be “stuck” at L5, but
85.
by t8sr 3y ago
You're missing the point - importing a module in other languages takes ~100x fewer system calls. It's a rare example of Python doing something that's mostly written in pure Python, rather than invoked via an FFI, and it shows
86.
by t8sr 3y ago
Ah right, I tend to think the tech bubble is the default context for stuff posted on HN, but of course that's just my bias. I think staff engineers are slightly more common than first level EMs, but senior EMs are slightly more common
87.
by t8sr 3y ago
There were slightly more L7 EMs than L7 SWEs every time I looked, but there's nuance to that. If the company decides it needs an L7 EM and nobody is available to promote, they'll hire externally. Your chances of being promoted int
88.
by t8sr 3y ago
There are many different ways to grow beyond staff engineer: - Become an expert in something hard. Fix bugs nobody else can. This requires sticking around for longer than most people, maybe 10 years or more. - Have impact across the industr
89.
by t8sr 3y ago
I have been a manager four times, twice at FAANGs. I disagree with a lot that the author says: - The ladder isn’t really taller. Most EMs end up clustered at the equivalent of L6/staff engineer. Promotions to senior manager and beyond
90.
by t8sr 3y ago
Numpy is fine. But people write a lot of complicated code to pull JSON from somewhere, transform it in Python, and write it to parquet somewhere else, for example. JSON, the dict type and parquet are all implemented in C, but a comprehensio

More ›