Hacker News Reader

> Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS.

I think Ruby is much better than Python for building large applications.

Ruby is essentially Smalltalk with a neat Algol-like syntax and some Perl-isms. Its OO system is a joy to work with.

Python got so popular in data-oriented applications because it's a really simple procedural language.

More importantly, it had the right libraries (NumPy, SciPy and Matplotlib) when Torch (implemented in Lua) was no longer viable (due to LuaJIT limitations).

That's sort of outdated. Python now has type hints, protocol oriented programming support, and is quite fast (for what it is). This wasn't the case back in the day but it's all there now.

Python might have nice features, but it also has terrible features. Like using dicts for everything. It's not enough to allow good practices, you have to prevent (or at least reduce) bad practices.

You can use dataclasses instead of dict now.

Unless you use __slots__, aren't all class-based objects [specifically python2 new style `class MyClass(object): pass` or all python3 classes] dicts in Python?

I was talking about the dataclasses.dataclass annotation in 3.10/3.11. You can use slots with it.

You’re right, they’re dicts unless slots are used. I read the parent comment and saying you can define types easily. But you can with dataclasses

Can you elaborate? What exactly is wrong with dicts?

>Like using dicts for everything

Sorry what? This is absolutely not true.

I think they meant that the underlying representation for most stuff is a dict.

Global variables are stored in a dict (`vars()`). Unless you use slots, an object is essentially a dict

Doesn't really disturb me because they're not used like a dict in practice though

Rubys biggest downfall was the stupid "fancy" syntax stuff in the language, like not requiring parenthesis or return statements, insert operators, BEGIN/END blocks, e.t.c. All of those make the code base harder to read.

Also I remember the dependency management system was a pain in the ass to deal with, especially with modules with native libraries.

Python had some issues with 2, but when 3 came around and fixed all that, it became the language of choice specifically because of its consistency.

> Haskell and Idris are beautiful and powerful, but inaccessible to most software engineers.

I don't see any fundamental reason why that should be the case. It seems to me that while it's true that most engineers would have a hard time navigating these languages today, it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently: their experience stands in the way.

Imo, one "fundamental" reason is that Haskell has a much smaller, nicer core than most languages, so it builds everything out of that core. For example, most languages have variable update statements in their core. Haskell defines at least two data types of "programs that have stateful variables" (ST and State). The result is that people want to see how everything is broken down into pure functions under the hood, and that means it takes more time to learn the language.

I do see fundamental reasons. Haskell was designed from conception to be a platform for research and education. I’d say it was a wild success at those two things. Certain decisions that made it successful as a platform for research and education make it less suitable for use writing applications in industry.

The main decision I am thinking about is lazy evaluation. Lazy evaluation forces authors to write pure code, which drove Haskell’s community to build libraries that expressed effects in the type system, which made things like STM possible. If I wanted to design a Haskell-like for industry use, I would give it non-lazy evaluation (I’m not gonna say “strict” because I think the compiler should be free to omit the evaluation of any expression, but it sure would be convenient if we had more predictable performance characteristics).

I’m also not saying that you can’t use Haskell in industry. Obviously, people do that.

Having used Haskell in industry, I can say it's actually _surprisingly_ good at boring run-of-the-mill software. The strong focus on correctness and the ecosystem-wide consistency of it's core design patterns means you spend a lot less time debugging things, and a lot more time writing the thing you actually want to write.

That said, the type system _does_ stand in the way of learning it - though it's very powerful once you get your head around it - and lazy evaluation means you do spend more time than you'd generally like hunting down space leaks if you're writing the sort of code that's capable of getting space leaks.

...which is as easy as using foldl instead of foldl' instead of foldr, which to a beginner is... mildly confusing.

OCaml uses eager, not lazy evaluation but it is even less popular than Haskell. BTW, I like Haskell, but I feel like a novice, still learning, even though I wrote a Haskell book (you can read it online for free https://leanpub.com/haskell-cookbook/read).

I believe that to be mostly true for Lisp or ML-family (OCaml, ...) languages, but not for Haskell. Reasons would be: - lazy evaluation can be tricky if you work with files, you have to profile and force strict evaluation at key points to avoid memory explosion. - refactoring something to work with the IO monad is hard - typing some higher-order functions is hard

It may be subjective, but even for the syntax I felt a much stronger cognitive load working with Haskell.

> it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently

I beg to differ. I studied compsci BSC at an eastern european university. The professors decided to test that theory and decided to introduce programing to everyone in our program through Haskell. Every year about 500 new students were thaught Haskell. I don’t know a single one of us who stuck with it. Probably there are a few odd ones, but if it were only a question of familiarity you would expect that more people from there would keep programing in it.

That's a response to a slightly different question. Your answer makes it clear that exposing students to a language isn't enough to make them take up a language. The original point was that Haskell isn't per se inaccessible.

It's inaccessible because it's difficult and arcane compared to languages like Python, especially at the beginner levels when you are still trying to figure out how a for-loop works, and what are variables, and so on.

OK, but now we're back full circle, and you're disagreeing with both epgui https://news.ycombinator.com/item?id=34542953 and krisoft https://news.ycombinator.com/item?id=34544130

Yeah, of course, I am. I don't see what that has to do with anything. So my point is only valid if I support someone else?

A lot of us here have read "Learn You A Haskell for a Great Good". We've used it.

It's not a socio-historical incident, and it's not just beginners who struggle with the language either.

> Yeah, of course, I am. I don't see what that has to do with anything. So my point is only valid if I support someone else?

Your point is perfectly valid. I'm just saying the thread has just become a sequence of assertions and not particularly enlightening.

If it was accessible, then exposing students to it would be enough to make them take it up, no?

No? It may not be suited to their applications (wrong tooling / libraries ), or their collaborators may not use it, or they might simply not like it

I have a similar experience at Oxford. However, the introduction course doesn't even cover IO monad and all of our code are run in repl. No wonder the students regard Haskell as impractical as they did not even write a full program in it.

Still, if they'd found that Haskell was much easier or more productive to use than other programming languages for simple computational tasks, you'd think a few of them might have googled 'how do do IO in Haskell' and gone from there.

That seems to be getting things backwards. How could they find it easier or more productive if they haven't even done IO yet?

I would say the productivity gains of Haskell are actually most transparently obvious in the case of the sort of toy algorithmic code you're likely to be writing in a compsci class.

OK. And I would say the productivity gains of Haskell are most transparently obvious in the case of the sort of highly complex, stateful, I/O-interacting code you're likely to be writing for a successful tech company.

This doesn’t match my personal experience (having worked on a Haskell web app professionally for a couple of years). GHC does have some cool features like STM, but typical stateful code tends not to be radially more concise or easier to write in Haskell than in other high level languages (compared to, say, code for traversing a binary tree, or implementing a parser combinator library). Others may have different experiences.

Our uni taught us Haskell, Prolog, C and Java. All very intensive. First it was C, then Haskell & Prolog and then Java. When I came out of uni, I wanted to use Prolog & Haskell for everything, but jobs were only in Java and C. Don’t think it’s a matter or liking them or being more productive in them; you need to earn a living.

> It's not because the languages are particularly difficult or arcane, it's mainly because people don't already know it, and people don't like to learn to do things differently: their experience stands in the way.

I'm somewhat of a fan of Haskell (though its standard library is awful) and very much a fan of Idris (at the very least it's a better-Haskell, at best, dependent types!), but hard disagree.

These languages are difficult and arcane, compared to eg Python. A beginner to programming can get started with Python immediately, it reads like pseudocode.

Get started with Haskell or Idris, you quickly hit higher kinded types, monad transformers, free monads, final tagless. It's a different universe.

>Get started with Haskell or Idris, you quickly hit higher kinded types, monad transformers, free monads, final tagless. It's a different universe.

How is any new developer hitting any of these "quickly"? I'm working on a mature production codebase with plenty of advanced Haskell, and we barely have any tagless final code - much less free monads. Even HKDs and monad transformers are relatively recent additions to our toolbox that we reach for when appropriate - most of the code uses plain old datatypes and one or two concrete monad types.

My experience of learning Haskell is that many production codebases use advanced features because they are big boons to productivity, but few learning resources make reference to them. In fact, Haskell's biggest problem is probably the gap in knowledge between simple, low-productivity code written by newer developers, and the kind of code that actually goes into production with all the optional advanced features. A budding developer can easily write a whole application that never goes beyond `IO` without issue.

Alternatively, getting started with Java you quickly hit polymorphism, inheritance, getters-and-setters, and null object handling.

And yet everyone in my intro to CS class in uni managed to pick up Java within a week or two. Haskell is a bit more involved than Python, but not more involved than most languages.

Yes, Java is kind of the worst of both worlds. You have to learn new concepts and they aren't even very useful concepts.

> the cargo index download is glacial

Cargo has been working to resolve this, it's been testing a new feature that lazily fetches fine-grained index info over HTTP rather than the legacy approach, which is to clone the entire index stored as a git repo (which worked fine when crates.io was young and small, but hasn't scaled well). You can enable it on nightly Rust via the sparse-registry config flag, and it was recently accepted for the 1.68 release in March (which means you can try it out on the beta channel right now). In the future, it will become the default behavior.

https://doc.rust-lang.org/nightly/cargo/reference/registries...

You missed TypeScript, which has advanced generics with union support and the JS ecosystem is getting better each day and it’s ubiquitous.

TypeScript is fantastic —- such a flexible type system.

It was introduced 18 years after JavaScript but feels like a perfectly natural evolution of JavaScript. TypeScript _should_ feel like a wonky bolt on but it’s wonderful. A testament to the folks who built it

To be honest early TypeScript was quite bad with class dependence (functional style was an afterthought) and "namespaces" (That was still used in the mainline TS compiler until recently iirc, behaved like nested objects in JS, kind-of useful but totally missed the NodeJS file-based-module-separation) felt a lot like they wanted _Java_ or C#.

Sometimes during the late 2.x series TypeScript really came into stride with ability to express more "dynamic" types, using a functional style and having arrays-behaving-like-tuples,etc and the 3.x and 4.x series has really made it polished.

TL;DR; It's quite great now, but don't dismiss sceptical people because early versions of it kinda DID suck.

“Felt like they wanted C#” makes sense because Anders Hejlsberg was involved with TypeScript. Glad they stopped forcing C# into it and let it be its own thing. Not that C# is bad though!

> Tag structs are laborious... Rust should rebase its type system to have union types, i.e., foo: i32 | f32.

Rust has ADTs, so I'm not sure what you're saying here. Can you expand on how you think unions would make code nicer than disjoint unions? They definitely make generics much harder to think about for me.

Perhaps they mean anonymous (discriminated) unions of some kind with that syntax?

ADTs = discriminated unions + tuples. They likely mean undiscriminated unions, as in typescript.

But since rust is compiled, in practice that would be like C unions, right? A pain to work with

I mean typescript has those because the underlying runtime is Javascript, which tracks the types of stuff and handles some kind of polymorphism, so you can get away with undiscriminated unions because the runtime is doing the job of discriminating them

approaches C++-level eyebleed

Have you ever hit F12 on any C++ std function or data structure? Every time I do it genuinely feels like I'm back at day 1 freshman year of an undergrad CS degree.

Post a pic

A random file in the standard library:

https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0109...

Honestly I don't think it's that bad if you can look past all the underscores. I looked around for something worse but maybe I'm just accustomed to the eyebleed that C++ has to offer. To me, Rust is uglier, but that's because it's been around a quarter of the time that I've been using C++ and I don't know what all the symbols do without looking up a cheatsheet.

If you want ugly look at the MSVC std.

Party pooper. Don't you know we are just here to bitch and moan?

Look, I'll admit, it looks terrible from the view that gdb gives... but when you see the whole file, it's just not so bad.

The C++ library is algorithmically and data structure feature complete for most purposes. It doesn't have what boost and other libraries have, but that's okay. Ideally, a platform should ship without a standard library and use package management for all but built in types.

The problem with C++ template metaprogramming style is symbol length, the notation ordering (insane levels of nesting), and diagnostics generated from those that easily turn into absurdity.

Another issue is static languages lack universal diagnostics, introspection, and symbolic evaluation capabilities of dynamic languages with REPLs and remote debuggers.

Dynamic languages are often missing "compile" (deployment)- or at-boot-runtime type checking, data race condition borrow/mutability/concurrency analysis, and monkeypatch protections.

> Rust makes enormous binaries

But it DOES make binaries. Such a breath of fresh air after years of Java/Scala.

Java also makes binaries with GraalVM.

I never really understood this, especially in the age of small docker containers? You just yeet your jar into the container and deploy. Ok, so rust and go don't need a jvm. Why does it matter? Disk space is dirt cheap. It's not like statically linked binaries are small by any measure anyway.

Because I run binaries.

Like docker, for instance. If I had to write "java -jar docker.jar -cp ..." and fuck around for a week trying to figure out where the env vars, JVM flags, and arguments to the actual program go, I would not use docker. Let alone piping input through grep, less and tail.

    > Rust makes enormous binaries

Rust binaries are optimized to be fast (by default, fast != small), this [0] explains pretty well why, and min-sized also has many optimizations [1].

    > and compiles slow

You can have a very slow compiler with all the optimizations and safety checks, or a fast one which doesn't. This however doesn't mean there is no room for improvement.

One thing that can definitely improved on is how cargo manages dependencies, I am tired of each of my project's /target directory using >2GB of disk space, there at least should be some kind of opt-in global cache.

I am also worried about dependencies going in the same direction as the JS ecosystem, many of my projects only have 3-5 top level dependencies, but I end up downloading hundreds. A few are only compile-time, but this makes auditing very difficult and does make compile times a lot longer.

[0]: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... [1]: https://github.com/johnthagen/min-sized-rust

At the time I'm writng this, there's a separate thread on Rust's "ugly" syntax. The issue with complex trait constraints, specialization etc. is that they impact forward compatibility: it is possible that a new version of some external dependency will add trait implementations in a way that ends up breaking your existing code. It's understandable that Rust devs would want to avoid this.

Type arguments, union types, and a sound type system: pick any two.

For example, imagine the following in an imaginary version of Rust with union types:

    #[derive(PartialEq)]
    struct Option<T> {
        value: T | (),
    }
    impl<T> Option<T> {
        fn some(value: T) -> Self {
            Self { value }
        }
        fn none() -> Self {
            Self { value: () }
        }
        fn is_none(&self) -> bool {
            match self.value {
                _: () => true,
                _: T => false,
            }
        }
    }

What does `Option::some(()).is_none()` return? Is `Option::some(()) == Option::none()`?

> Uglier than Python and approaches C++-level eyebleed.

It's quite verbose, as well, or was the last time I looked at it.

I don't demand a Perl level of terseness (that's going too far the other way), but neither is reinventing the verbosity of COBOL a good idea.

I totally agree with your take (at least for the languages I know, out of the ones you mention). For me that right balance of beauty, productivity, and so on came with Clojure. I now find it painful to use any other language, tbh.

> Go is easy to learn but then the capability of it plateaus.

Given that almost every cloud native project is written in Go I'd say this is entirely not true.

That was the past, helped by Kubernetes and Docker respective decisions to migrate from Java and Python into Go.

Plenty of them are still Java and .NET based, as the ecosystems counter reacted to Go's adoption hype, and Rust is the new kid on the block specially for cloud native Webassembly projects and eBPF.

Like Helm creators nowadays doing mostly Rust, https://deislabs.io/posts/

cloud native web assembly...

...x86_64? ;)

https://krustlet.dev/

https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...

https://www.docker.com/blog/docker-wasm-technical-preview/

https://www.fermyon.com/platform

Gotta respect the grift I guess! Like MLM crypto schemes maybe I just Don't Get It, or I'm not the mark...

WASM is architecture-independent (ARM servers are becoming a thing, for better or worse) and has a lot of investment into sandboxing it performantly (since it also has to run in browsers).