Hacker Newsnew | past | comments | ask | show | jobs | submit | vyskocilm's commentslogin

JEP 504: Remove the Applet API

Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?


Note that the the Java plugin and webstart was removed a long time ago.

I personally regret that the API was removed as it's a few classes and they are still used. Just search JApplet on Github. It's also possible to run applets in the modern browsers with WASM or in Java IDE's as plugin.


Remember IcedTea Web? Oh boy, I still have environments that use it.


I made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.


Yeah XMLHttpRequest and activex thing IE6 had. That was Javascript style that days.


At this moment ReactOS guys should consider distributing their apps separatelly from their bundle.

https://github.com/reactos/reactos/tree/master/base/applicat...


This would be really interesting, actually.

Maybe someone should submit a feature request for it.


We have been banned from using Ami Pro for writing a technical reports on my highschool in late 90s and required to write them by hand as an attempt to combat copy&pasting. We "shared" all the calculations in the class anyway, so it haven't worked well.


> I don’t feel like a consumer, but a janitor. I don’t want this.

I think it was Jorge Castro, the creator of Universal Blue, who called it the sysadmin culture. Most Linux distros are made by sysadmins for sysadmins, and you're expected to change and configure your system. I was a sysadmin myself for a long time. I used Slackware; switched from the 2.4 kernel to 2.6; tweaked CFLAGS on Gentoo; replaced SysV init with systemd; used PipeWire from the earliest versions - you name it, I did it.

Nowadays I use https://aeondesktop.github.io/ - an immutable system with Btrfs snapshots. Everything is installed from Flathub. The major roadblock is that much of the Linux world expects you to modify the system one way or another, so your mileage may vary. I replaced my printer because I did not wanted to install binary blobs from HP/Samsung.

> Perhaps I haven’t found «the right distro»

I’d look at immutable or image-based offerings, which aims at low or no maintenance: Aeon Desktop, Universal Blue, Endless OS. There are reviews on sites like LWN.net


It really depends. I learned Lua in order to contribute to kulala plugin for neovim and found the language nice and easy to learn.

Of course it has its warts, but given the topic, almost everything is better than a vimscript imho.


https://github.com/mistweaverco/kulala.nvim is an another restish (it can do gRPC to) plugin for neovim. It is intended to be compatible with a Jetbrains as much as possible.


Shameless plug. I had experimented with Go iterators a while ago and did a https://github.com/gomoni/it

It was updated to 1.23, so it is as idiomatic as I can get. And yes it has a map method between two types. Just a single simple trick used.


Nice rewrite for 1.23. Btw, just sent you a PR for a typo in the readme.



Why bother with Varlink IPC, and why now?

The Varlink IPC has been around for a while, but recently we started using it heavily in systemd. In this talk I'd like to explain what Varlink IPC is, and why we are now adopting it so heavily. And I also want to explain why I think that Varlink is a good candidate as IPC of choice for any Linux software, both low-level and higher-level. We'll compare it with D-Bus in particular, and highlight where it shines (and where it doesn't shine so much).


Well written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.


Wow. I haven't followed Go for a while, thanks for that note.

Iterators are very nice addition, even with typical Go fashion of quite ugly syntax.


Just last week I've implemented an iterator for my C++ type and lol to your comment. It was fucking nightmare compared to how you (will) implement an iterator in Go.

I didn't study the reason why Go chose this way over others. I do know they've considered other ways of doing it and concluded this one is best, based on complex criteria.

People who make value judgements like this typically ignore those complex consideration, of which playing well with all the past Go design decisions is the most important.

Frankly, you didn't even bother to say which language does it better or provide a concrete example of the supposedly non-ugly alternative.


C#, python - here are the most mainstream examples of syntax that doesn’t look alien.


They don't have any syntax that differs from the previous Go versions.


Iterators and generics go against the original goals of Go - simplicity and productivity. They complicated Go language specification too much without giving back significant benefits. Iterators and generics also encourage writing unnecessarily complicated code, which makes Go less pleasant to work with. I tried explaining this at https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...


This argument is brought up again and again, but it is just wrong.

Go had both generics and iterators from the get go. Just not user defined ones.

Thus it is obvious that the creators of the language always saw their need for a simple and productive language


Not obvious to me. We just implemented a streaming solution using the iterator interfaces. They are just functions so reading the code its easy to understand. Adding special language support only serves to obfuscate the actual code.


Go provides generic types since v1.0 - maps, slices and channels. Go also provides generic functions and operators for working with these types - append, copy, clear, delete. This allows writing clear and efficient code.

There is close to zero practical need in user-defined generic types and generic functions. Go 1.18 opened Pandora box of unnecessary complexity of Go specification and Go type system because of generics. Users started writing overcomplicated generic code instead of writing simple code solving the given concrete task.


tell me, how often do you find yourself writing `interface{}`?


Very rarely


I do agree with his point that the implicit mutation of the loop body for an iterative will be difficult to debug.


I'm not sure I can agree about generics. In many cases Go code is already fast enough, so other things come to play, especially type safety. Prior to generics I often had to write some quite complicated (and buggy) reflection code to do something I wanted (e.g. allow to pass functions that take a struct and return a struct+err to the web URL handlers, which would then get auto-JSONed). Generics allow to write similar code much easier and safer.

Generics also allow to write some data structures that would be useful e.g. to speed up AST parsing: writing a custom allocator that would allocate a large chunk of structs of a certain type previously required to copy this code for each type of AST node, which is a nightmare.


> Prior to generics I often had to write some quite complicated (and buggy) reflection code to do something I wanted (e.g. allow to pass functions that take a struct and return a struct+err to the web URL handlers, which would then get auto-JSONed).

This sounds like a good application for Go interfaces (non-empty interfaces). The majority of generics Go code I've seen could be simplified by using non-empty interfaces without the need of generics.


Totally agree, as far as I know Rob Pike no longer develop Go, that's why. Came corporate people instead who think they do their work, asking community (who said that it should be asked?) what new cocojamba feature should be added (like js)

But what can we do against of this? This what I think: - stuck to use Go 1.16 - fork Go 1.16 and continue develop lang from there - learn OCaml... - give up and consume what these people decide to add to lang next and everytime feel disgust


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: