231–240 of 363 posts
Earlier quoted context omitted.
My biggest problem with it is implicit interface. I genuinely despise that about it.
Why don't you like implicit interfaces, it's the feature I love the most actually?
Earlier quoted context omitted.
The problem with "too clever" isn't just about cleverness that is actually in the code. It's also very much about cleverness that could potentially lurk behind any particular syntactical expression. When you look at a line of code, what can you tell about its semantics without considering non-local information? What is invariant and what could potentially be redefined? I think the answer to this question is extremely…
That's a great call out, though I see this in most languages, Haskell and go equally have implicit non local behaviours, but I find the functional paradigm tend to have less, because of side effect free functions.
I totally agree with you about pure functions. They can be a real simplification, but only if any deviation from purity requires special syntax at the call site. Otherwise you're back in the guessing game.
> GHC’s garbage collector is designed for throughput, not latency. It is a generational copying collector, which means that pause times are proportional to the amount of live data in the heap. To make matters worse, it’s also stop-the-world. This is pretty much unacceptable in today's world of low-latency (web) apps. How active is GHC's development? Would it be possible to efficiently run Haskell using Go's runtime e…
Haskell always makes me sad. In real-world apps you always need hacks. I do anyway. In an imperative language I can be proud when my code only has a couple hacks in it. With Haskell I just end up feeling nasty about my code if there's even one hack there, and it makes me like coding less. (For toy apps with no deadline Haskell is great; the above regards Haskell-at-work, as a freelancer).
For me it’s quite the opposite: Haskell allows me to have local hacky sections that I can then hide in a module that exposes a safe API. Since refactoring is fairly easy with compiler assistance, I don’t even have to break up my 100-line-long work-in-progress algorithm with temporary names until it works – and once I have a working solution, converting it to something readable is mostly manually extracting definition…
Earlier quoted context omitted.
To interface via an FFI with a game engine, which uses a custom allocator, and you need to pass datatypes between it and your own code? (As I’ve done in Java!) To replace existing implementations with your own, because you want a LinkedArrayList (a linked list of blocks)? Or because you want a TreeMap instead of a HashMap, or a Set with different implementation? Because you want to implement your own Either type to b…
This is an interesting point actually. Because it gets raised every time and I actually thought the same before starting with Go. Thing is, in practice you usually don't need special generic containers. And when I actually need it, I'll just code up a non-generic implementation. When I need a complex type system I'll use Scala.
This allows me to have fully reactive collections in Java, lazy reactive collections, and more.
I can just connect to a socket transmitting updates with netty, write a transformer, apply those to a lazy reactive collection, and have the changes directly appear in the list in the UI, fully threadsafe.
Writing those things again, and again, every time, would be far more work, and increase the time I need to write code massively.
I’ve actually used go a bit, and tried reimplementing several of my projects in go, but either it wasn’t easily possible, or I had to translate dozens of generic classes into hundreds of non-generic versions, with lots of duplicated code.
And then I had found a bug, fixed it at one point, and had to copy it to hundreds of files.
Earlier quoted context omitted.
From Paul Graham, and one of the best essays on the subject ever written: http://www.paulgraham.com/avg.html As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power con…
So when you say a language is "powerful" you are talking about its level of abstraction? Because then we should probably try to call it something else so as not to confuse "power" for technical ability to deliver performance or productivity.
It does not necessarily mean that any dev can code faster – or even similarily fast. But it means that much of refactoring usually is easier (as you’ll have less duplicated code), that you get more guarantees, that you have less boilerplate, etc.
Earlier quoted context omitted.
I feel like the tooling is really impressive, considering the age of the language. Remember that Haskell is something like 25+ years old. Go has done quite a bit in short time - I can only hope it will get better too. That's like hiring a toddler who can do sums for an accounting position. Showing promise is good, but not the same as being good right now.
When a decent software engineer builds a project, you not only take into consideration the status quo of the technology, but also its promise, momentum and community development speed. You don't want to pick a stack with weaning manpower because you'll soon be left with legacy software in your hands. Hence, I do think that, for most serverside projects, the "promise" (as you call it) is very relevant and a true facto…
I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Sigh I hate to say this I really do. But here goes... So have you checked out rust?