Live data from Hacker News

Bubble Tea: fun, functional and stateful way to build terminal apps

github.com

91–100 of 116 posts

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#91

Earlier quoted context omitted.

I'm only really interested in learning a language if it excites me, or if I'm getting paid to do it. I don't hate Go, and would be fine to learn it on company time for company projects, but there is no spark that would lead me to learn the language on my own. I've written some basic Go, but if I'm using it in personal projects, I'd would have to invest time to understand the ecosystem, runtime, standard lib, best pra…

This is roughly my take. Between Nim and Rust, I have no purpose for Go that isn't covered by a language that's flat-out better.

They’re not better.

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#92
post #60

Earlier quoted context omitted.

> for no good reason When a language has some property that surprises you, consider whether it might have been designed that way on purpose, not simply because the creators were ignorant/lazy/negligent/drunk/lost a bet/etc.

I did. Rob Pike said that Go was purposefully made similar to C (and by extension other languages similar to C), in order to be familiar and get new engineers who are already familiar with C or C-like languages to become productive without having to learn too much. And while I can totally understand how that makes sense in the intended setting, I don't consider that pleasing at all. "Pleasing" for me implies that I l…

I think your critique, if you examine it closely and deeply, is fundamentally an arrogant one. Sorry for the harsh claim, but I truly do believe this.

You are a new developer too. Everyone is. When it’s easy to learn something, it’s easy to relearn it, and it’s easy to learn things around it (because you don’t devote as much brain to the language).

All languages should target new, dumb devs, because all devs (including Rob pike) are new and dumb.

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#93
post #59

Earlier quoted context omitted.

> for no good reason When a language has some property that surprises you, consider whether it might have been designed that way on purpose, not simply because the creators were ignorant/lazy/negligent/drunk/lost a bet/etc.

> creators were ignorant/lazy/negligent/drunk/lost a bet/etc. This is not a well-intended comment, but then why didn't they add generics at the start? It's not like it was a surprise to anyone even remotely familiar with PLs that they will have to retrofit it sooner or later. Also, function-scoped defers instead of surrounding braces-based one? Come on...

Not adding generics, if you dig through the archives, was a pragmatic choice. Partly it was to help the process of language design, partly it was project management, and partly it was due to technical constraints. Generics is a big, complex feature. The team was prioritizing getting the most immediately valuable features shipped first, and didn’t want the introduction of generics to hit their limited resources too hard or distract from getting the fundamentals right. Generics implementations in existing languages at the time also made trade offs/interactions that weren’t appropriate for go.

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#94
post #31

Earlier quoted context omitted.

Why not? There's a lot to hate about every language, but one advantage about Go is that it's fairly easy to context switch in/out of, which makes it great for side projects, because it's cognitive load while using it is really low. Unlike say, Rust. I do love Rust though.

I just can't get past the fact that Go doesn't have sum types. As someone who dabbles in category theory, it makes no sense to me that so many popular languages have product types but not their categorical dual. The lack of sum types leads to so many hacks and weird design patterns in the language, like returning two values when you only want the caller to read one of them (that is actually Go's error handling strate…

> but exactly what you'd expect from programmers who spent the majority of their careers writing C

Writing C is an understatement given that Go and C were created by the same person (with help, of course).

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#96

Earlier quoted context omitted.

Some terminals have custom protocols for displaying images. The real achilles heel is they're not accessible. There is no terminal protocol for denoting actual objects being drawn in the window such that they can be exposed to accessibility APIs. Standard CLI tools are usable, but TUIs are not. I have previously seen someone state that for this reason, every TUI program should have an optional CLI mode. Also, if ever…

I feel like I've seen TUI's from a completely different angle, including full use of modifier keys , full mouse support, etc. Its amazing how one persons perspective can completely disagree with anothers. What did you mean by the "OS task switcher becomes useless" ?

TUIs cannot have full use of modifier keys as the full set of modifiers is not sent to processes running in a terminal.

As for the OS task switcher, if everything is a TUI then you only have one app, which is your terminal, and so your OS task switcher cannot help you switch between apps anymore. You have to switch between windows belonging to the same process. It’s the same problem that you run into by doing everything inside a browser.

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#97

I spent a good chunk of time last week looking for a solid cross-platform GUI toolkit. I came to the conclusion that the terminal is the most portable GUI platform available. You can create an app that has windows, buttons, mouse support, etc, statically compile it for Windows, Linux, and Mac, and run it over SSH. The closest you can get to that with real graphics is using a toolkit built on OpenGL, and you'll be for…

I've settled in the last few years on using JUCE for all my apps. It has everything I need, and provides more than ample features for adding new GUI elements. I strongly encourage anyone looking for a cross-platform GUI solution to consider JUCE very carefully - it says "for Audio plugins" on the box, but in fact it is perfectly cromulant way of doing 'normal apps' too ..

http://juce.com/

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#98

Earlier quoted context omitted.

Game engines (at least the lightweight ones) seem good for cross-platform graphical apps in general but the idea of redrawing a static GUI at 30 FPS just sounds too inefficient to me.

You're absolutely right. So I do without 30 FPS. We're all up this tree where we want all the features we're used to and we're willing to put up with software bloat and insecure software and sprawling supply chains to get it. I'm not. So I start with something minimalist and do what I can within it. One of my inspirations is http://akkartik.name/illich.pdf

Does this mean that you're rendering at 1fps, 10fps or something?

Is it an artificial limit you put on rendering?

Do you have button animations at 30 FPS?

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#99
post #98

Earlier quoted context omitted.

You're absolutely right. So I do without 30 FPS. We're all up this tree where we want all the features we're used to and we're willing to put up with software bloat and insecure software and sprawling supply chains to get it. I'm not. So I start with something minimalist and do what I can within it. One of my inspirations is http://akkartik.name/illich.pdf

Does this mean that you're rendering at 1fps, 10fps or something? Is it an artificial limit you put on rendering? Do you have button animations at 30 FPS?

You can lower the frame rate when the window is not focused, or entirely avoid drawing if it's not visible.

Re: Bubble Tea: fun, functional and stateful way to build terminal apps

#100

This looks like a really cool project, however I have to say that the Go language seems like a terrible match for the Elm architecture.

I’m not overly familiar with Go and would be curious to hear more details about this.

Some of the features that make Elm and Elm architecture work so well together:

- Light-weight lambda syntax

- Sum types and records

- Global type inference

- Exhaustive match expressions

- Powerful generics

- Immutability by default

- Partial application / currying

- Modules

- Ecosystem of packages built around pure functions

Post reply on HN