24 ms·

CodePerfect 95 – A fast IDE for Go

205 points by brhsagain 5y ago

q845712 5y ago
This is a compelling product pitch to me - I alternate between using vim but not having everything memorized, and using GoLand for its autocomplete and various correction/detection/auto-import-fixing conveniences but wishing it were faster. I'd be willing to pay $5/month for a beta version, if I were using windows. Or alternatively, if someone is watching, I'd be willing to pay $5 for a trial of a mac version :) Respect it's quite a bit of work to support a second OS and window manager and you have to start somewhere - Hope it goes well and makes its way over to Mac soon!
geodel 5y ago
No electron based editor sounds so good to me. However at this point I feel there is no satisfying the mob of "Why would I use this instead of VSCode?"
- itake 5y ago
  VSCode (or more specifically, the VSCode Go extension) can't handle a mono-repo of golang microservices. My CPU/fans go crazy opening the darn thing. With the extension disabled, VSCode is fine, but it lacks all of the "necessary" features offered in the extension.
  - disposedtrolley 5y ago
    I wonder if these performance issues apply to all language extensions that rely on a language server (implemented in VSCode or otherwise). From what I understand, since JSON [0] is used over the wire between the editor and the language server process, there's a lot of serialisation/deserialisation overhead. Microsoft used to maintain a log inspector [1] which you could use to see the chatter between the server and client, and there was a _lot_ of chatter with a _lot_ of JSON. [0] https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie... [1] https://github.com/microsoft/language-server-protocol-inspector https://github.com/microsoft/language-server-protocol-inspec...
    - qbasic_forever 5y ago
      LSP stuff is done asynchronously in VS code (and other editors). This doesn't slow down the main editing UI at all. It just means when you start typing and expect to see linter warnings, autocomplete suggestions, etc. it can take a bit longer if the LSP server is slow to respond. If someone has all their CPU fans, etc. spinning up when opening a big monorepo it's probably just aggressive indexing inside the LSP server they're using. Almost certainly it's an optimization trade-off made by the LSP server author, trying to balance the common case of people typically opening smaller repos and assuming they immediately want search, etc. to be fast and ready. There's nothing inherent to the LSP protocol or design that causes this problem--someone could build a better LSP server designed to handle large monorepos by deferring indexing, etc. until absolutely needed (but potentially with some tradeoffs like searching inside a subunit being delayed until its used). It's the same basic problem git faced with enormous repos over time slowing down and all the hacks/workarounds people have bolted on to try to limit how much of the monorepo state needs to be available at any moment.
      - disposedtrolley 5y ago
        > There's nothing inherent to the LSP protocol or design that causes this problem Even though most of the indexing and intellisense features are done within the language server itself, there'd still be significant overhead in JSON parsing and serialisation right? The response example for the `textDocument/definition` request [0] shows a very large snippet of JSON considering the information it conveys: { "jsonrpc": "2.0", "id": 1, "result": { "uri": "file:///p%3A/mseng/VSCode/Playgrounds/cpp/provide.cpp", "range": { "start": { "line": 0, "character": 4 }, "end": { "line": 0, "character": 11 } } } } [0] https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie...
        hnlmorg 5y ago
        One of the benefits of the JSON standard being pretty simple is that it makes JSON is pretty efficient to parse. We're not talking ProtoBuf efficient here, but I've easily parsed files containing gigabytes of JSON.
- rodgerd 5y ago
  > the mob Ah yes, such a winning way of referring to people who like a different text editor to you. Way to up the quality of discourse.
  - geodel 5y ago
    I am sure once you hear of "Gang of Four" design patterns [1] your immediate response would be to rage about why is one bringing an organized group of criminals to the subject of software design pattern discussion. 1. https://springframework.guru/gang-of-four-design-patterns/ https://springframework.guru/gang-of-four-design-patterns/
    - loopz 5y ago
      We could point out why would you need design patterns when the language directly supports them natively, but can't since this is a Go thread ;)
      - philosopher1234 5y ago
        It’s better this way.
int_19h 5y ago
I would have expected a product with "95" in the name to use native look & feel, as was the norm back in the day.
fermentation 5y ago
The page says the editor is "designed to run at 144hz". That's actually a pretty cool feature, as vscode seems locked to 60hz. I have to wonder, what is stopping it from going further? I have a 240hz monitor, are there any IDEs or text editors that can render that fast?
- qxga 5y ago
  Nothing is stopping it from going faster, unless the framerate is forcibly capped by the developer. It renders the same way a framerate-independent 3D game does.
Kubuxu 5y ago
I was hoping they were going to take my money (when I saw the "Join Beta"), unfortunately it is Windows only. Personally I know only one person working in Go on Windows, I know 40+ either on Linux or MacOS. I hope for Linux version soon.
- PuerkitoBio 5y ago
  I had my credit card out at "Vim Keybindings", only to be slightly disappointed by the Windows-only limitation (for now). Looking forward to try this out on Linux soon. Although I'm pretty happy with Vim, I'm curious to see if I'm missing out on a significantly better experience. That being said, not a fan of a monthly subscription for a native desktop application.
  - Kubuxu 5y ago
    For desktop applications I just translate the monthly subscriptions into yearly. Most software right now is sold as either yearly subscription or "year of upgrades" so it is one and the same.
    - PuerkitoBio 5y ago
      If I can't use the software without an active subscription, it is definitely not one and the same. I like Sublime Text's license of 3 years of upgrade with a purchase, no limitation on usage of the software. Unclear (AFAICT from the FAQ) how it would work for CodePerfect 95.
    - FpUser 5y ago
      I have some applications that are years old without upgrading to current version. Reason - the old version works fine and does everything I need. However if that's the case I sometimes decide to upgrade at some point to feed the developer.
- intricatedetail 5y ago
  Both Windows and macOS do dodgy telemetry and who knows what data they harvest. I don't know anyone doing programming seriously who doesn't use Linux.
yjftsjthsd-h 5y ago
There's something funny about proudly proclaiming no GC and written in C++ for a golang IDE. It's not wrong; different tradeoffs for different uses. Just funny.
- bob1029 5y ago
  Modern GC doesn't even preclude the possibility of developing a no-lag UI. You just have to be very careful with how you manage your data so that you don't get hit with more heavy-handed collection mechanisms (i.e. large gen2 cleanups in .NET). Small and short-lived class instances (more ideally structs) are the key to success with low-latency applications in most GC'd languages. If you are only touching gen0/1 in a .NET5 app, you will probably find the GC impact to UI latency to be negligible. In .NET, avoiding gen2 allocations is pretty easy. The biggest thing is replacing every byte[] with Stream as feasible, so you don't send objects directly to LOH (gen2). I believe the LOH threshold for byte[] is lower than the published limit of 85k, but I cannot recall the specifics (might be closer to 10k). Regardless, you really shouldn't be holding onto chunks of memory that large if you can ever avoid it. In some cases you can cheat. Pass around the path/id to a file and then stream it from disk at the very last possible moment (i.e. copy a FileStream direct to the HttpContext.Response.Body stream). If you absolutely must allocate large objects, try to reuse them as much as possible. Act as if anything entering gen2 is in memory forever, because with enough LOH fragmentation, it might as well be. UI is one thing, but real-time process control is a wholly different animal. If you want to write a PID in a GC language, you better be prepared to eschew any notion of allocation in the process under collection. Even if you don't allocate, there are runtime components that still will, so you will almost always have some minimum amount of noise to contend with. That said, if you only need to run a PID loop at ~10khz (100uS loop delay), you probably wont have any issues. Just make sure you put the PID loop on a high-priority thread and care for its surroundings gingerly. A Raspi4+ is actually an amazing platform for this sort of thing.
  - throwaway894345 5y ago
    I suspect Go's GC would be particularly well-fit for this kind of application considering it typically runs in <1ms with no exceptionally large pauses (except perhaps in pathological cases). Like C#, Go has value types, so controlling allocations should be pretty straightforward.
jmrm 5y ago
I would like an IDE like this but for Rust. Some day I will get angry enough and I'll have to make it myself.
- mathgladiator 5y ago
  Check out https://makepad.dev/ https://makepad.dev/ and then hold down left alt key.
  - zeroxfe 5y ago
    > and then hold down left alt key. okay, that was just plain cool!
  - jmrm 5y ago
    That is totally awesome! Thank you :)
- sodality2 5y ago
  I desperately want this. I find text editors w/ basic linting to be too limited but full IDE's like Idea or even VSCode too heavy for some devices. Something in between :(. I've given up laptop development and am forced to work with my desktop until I can afford a better laptop because Idea/VSCode runs so slowly. FWIW, I use lite (https://github.com/rxi/lite https://github.com/rxi/lite) if I need a very lightweight text editor that has rust linting (https://github.com/liquidev/lintplus https://github.com/liquidev/lintplus) and Idea if I'm at my desktop.
  - sli 5y ago
    I bought Sublime Text last year after using it off and on since 2009 or so and I don't think I'll switch again for a long time. I figured I'd gotten $80 of use out of it over the years, anyway. The difference in performance between ST and Atom/VSCode is unreal (but expected). It doesn't have nearly as big a community behind it, so adjusting your tooling can take time, but I'm doing mostly Rust these days and it does a fine job for me. That all might be a dealbreaker for some, though. I do know Elm support was way better in Atom, but I'm not writing that very much these days.
momonga 5y ago
I wonder how much CPU this uses. An immediate mode GUI (ImGUI, which CodePerfect 95 uses) constructs the entire GUI on every frame by default.
- mananaysiempre 5y ago
  It does run through every node in the would-be scene graph by default, but IIRC the Dear ImGUI library caches the actual expensive toolkit, graphics, and/or window system calls for each subtree. The API is immediate-mode, but its implementation does not have to be stateless. (Cf. React.)
hulug 5y ago
Not to be a prick but I doubt Go users will like this, they tend to prefer simple things to more complex things. Maybe retargeting this for Java/C++ users would be better. Jokes (not really) aside, why does an IDE need to be designed for a language anyway?
- qxga 5y ago
  It's a self-contained application using the Dear ImGUI library rather than a bloated framework, and is designed for a single language. It's not simple compared to the likes of vi, sure, but it's almost certainly many less lines of code and much more architecturally simple than just about any other (popular, in-use) IDE out there.
- mananaysiempre 5y ago
  Because so far noöne has figured out the set of extensibility points needed for a language-agnostic one that doesn’t result in horrible bloat and sprawling API surfaces. The original language-agnostic IDE—Emacs—is probably the simplest, and it’s still quite complex. Acme[2] is interesting, but Spartan when it comes to actual IDE-ish features, and its UI always rubbed me the wrong way. I feel this is somewhat related to the fact that noöne has figured out how to do extensible widget toolkits or scene graphs either. (Yes, Electron does in fact solve an actual problem, if in a profoundly unsatisfying way.) Actually, just a text input box that could handle the complexities of the world’s writing systems (RTL, complex font shaping, arbitrary input methods, autocorrect, all that with at least one cursor or selection) and was capable of supporting the facts vs rumors approach from FRP[1] would be a significant advancement re toolkits. As for scene graphs, I don’t actually know of any viable general approaches to assembling an interface out of independent parts (that doesn’t work by presupposing a large substrate of features in the host “shell” and providing a separate extension point for each of shortcut, menu item, toolbar button, sidebar, dialog, ...). Actually, now that I’ve written all of that out, it seems that another way to put my second point is that the language-agnostic IDE problem is a proper superset of the composable GUIs problem, and nobody knows how to solve that one. Composable CLIs are easy—they’re called “[textual] programming”; but then composable GUIs (or TUIs, the graphics/text distinction is immaterial here) would seem to correspond to visual programming, and last I checked the latter still sucked. [1]: https://apfelmus.nfshost.com/blog/2012/03/29-frp-three-principles-bidirectional-gui.html https://apfelmus.nfshost.com/blog/2012/03/29-frp-three-princ... [2]: http://acme.cat-v.org/ http://acme.cat-v.org/
Yoofie 5y ago
As soon as I saw the screenshot, I instantly knew it was using Dear Imgui library [1] under the hood because of the familiar Imgui design cues. Dear Imgui is originally meant to be used in combination with game & graphics engines which support hardware acceleration. Thus, you get high framerates. [1]: https://github.com/ocornut/imgui https://github.com/ocornut/imgui
- deleted 5y ago
  [deleted]
- syspec 5y ago
  It's also in the gif on the primary page: https://codeperfect95.com/static/media/60fps.01d0b31c.gif https://codeperfect95.com/static/media/60fps.01d0b31c.gif
munificent 5y ago
> I know how an IDE works. All an IDE really needs to do is (a) let you edit a text buffer, (b) parse your source files, and (c) build an understanding of your code and provide you with intellisense. What's hard about that? Why is my IDE slow? ... > The IDE is very much unfinished. ... it freezes when opening super huge directories. So here's what's likely to happen: 1. To fix that freeze, you realize that you need to do file loading asynchronously in the background. 2. That in turn means you need to have your parsing/analysis run asynchronously so that it can analyze files as they come in. 3. But the UI that is reading analysis results is still running on the main thread. So now you need to add locking and other concurrency stuff everywhere. This takes a year of your life. At the end, your IDE is now twice as slow. 4. Also, the user still wants to be able to edit code while all this asynchrony is going on. (Otherwise, you'd just freeze like you were before.) So now your analysis engine needs to handle both concurrent reads and writes while also doing file IO. 5. At this point (especially with all that locking and other concurrency stuff), it's so complex that "re-analyze the entire program from scratch every time" is too slow. You need to be able to maintain a persistent analysis state and incrementally update as the user changes code or files get reloaded. You build a complex dependency graph system so that you can determine which analysis state must be invalidated when a line of code in one file is changed. This is another year of your life. 6. Now your analysis engine is so complex that the limiting factor for making your IDE better is developer productivity. It is incredibly hard to touch this giant ball of mutable concurrent incrementally updated state without breaking something and/or losing your sanity. 7. You eventually realize you need to architect it at a higher level. Instead of low-level threading and locking and carefully hand-authored incremental updating code (which few humans can maintain), you replace it all with a bunch of more coarse-grained persistent data structures. This takes a couple more years of your life. At the end, you get an analysis engine that you can maintain, which is good, because in the meantime, three new major versions of Go have come out and users asking you to support 17 other programming languages. But your new coarse-grained analysis engine is five times slower than the old ball of spaghetti... 8. A user files a bug saying that the IDE crashes when they try to open their 20-million line Go program. It turns out your implementation assumed you could always fit the full AST for every source file in memory. OK, time to start working on a compressed code representation.... 9. Meanwhile, another user files an innocuous little bug asking why the editor doesn't support full-width characters, right-to-left languages, or emoji. You open up your beautiful, 200-line hand-written fixed-width text renderer in one tab. Then you open the Unicode spec in the other and start reading about "extended grapheme clusters", "combining characters", etc. In a third, you start reading about OpenType "multi-colored glyphs"... I agree that IDEs could be faster than they are. There is a lot of cruft. But it's very hard to fix that by starting with OpenGL Notepad and hacking your way to IntelliJ one Git commit at a time without ever monotonically regressing perf. That's like trying to solve climate change by taking a tricycle and incrementally welding your way to a carbon-neutral container ship. Writing a real-time code analysis engine for large-scale programs is hard. It's a big complex piece of code. Comparing it to a text editor is like comparing Tetris to World of Warcraft because they're both "games". That being said, I completely applaud the author for making a go at it. It's hard, but not impossible, and history is written by people who had the courage to do hard things.
ojosilva 5y ago
> What does CodePerfect 95 mean? It's a retro name. It hearkens back to a time when software was fast and started up instantly, despite running on hardware orders of magnitude slower than we have now. WordPerfect was a huge monster, probably one of the largest (15+ diskettes) and sluggishiest DOS apps I had back in the day. Windows 95 was cool, but also a significant step back on snappiness compared to 3.11 or even OS/2 Warp. There are probably much better retro-snappy names, like, don't know, CodeKick 1-2-3?
- jagger27 5y ago
  Office 95 was pretty snappy, from what I remember.
- starik36 5y ago
  > WordPerfect was a huge monster, ... sluggishiest DOS apps Hmmm, I don't remember it being sluggish. I worked at the university computer lab at the time and remember WP being of of the snappiest programs. It was mostly written in assembly till the later versions.
maxdo 5y ago
Author is trying to solve a problem that is not exist , ui Is not a problem for any programming language for the last 10 years unless you’re doing scala or something heavy that kills your machine
nexuist 5y ago
Why would I use this instead of VSCode?
donatj 5y ago
$5 a month, $60 a year. It's not horrible pricing, but it's competing with GoLand at that price point, and GoLand is fully featured in a way I don't see this ever being. You're also competing with the LiteIDE. It's free, light as hell, and as far as I can tell does everything this does probably as lightly as this does. Beyond that, I'm sure for the thousandth time you've heard it "why does everything need to be a service these days?" Har har, but seriously why not give this a reasonable 1995 pricing model if you're playing up the 95 angle for Christ's sake.
- ianlevesque 5y ago
  It's really a reasonable cost. They're probably a solo developer or at best a small team and any subscription model will make that vastly more sustainable.
  - donatj 5y ago
    To my point, it is reasonable, but they've already been out priced by more capable products. It's not a good place to start.
    - LanceH 5y ago
      Except speed apparently. Goland and VS Code both have slow response times to clicks.
  - Barrin92 5y ago
    the problem is that price isn't justified by the size or character of the team but by value added for the consumer, compared to other products in the same space. 60 bucks per year for a language specific IDE which has multiple competitors with more features just doesn't seem like that good of a deal. Others have pointed out LiteIDE, which is open source and doesn't cost anything.
- intricatedetail 5y ago
  Goland is slow. It's such a drag when you accidentally open it. So many times I abandoned trying something because of the thought of opening goland. Thankfully I got sublime. I'll give this one a try too.
bouncycastle 5y ago
Cool name! However, I never had a situation with Goland where speed was an issue. In most cases, I'm waiting for the code to compile. Page rendering speed is an issue in things like web browsers. Besides, my main 4k monitor has a refresh rate of 30hz, so scrolling will always be janky... For me, the killer feature of any IDE has always been integrated debugging and able to inspect the data. Integrated testing has also been another feature I cannot live without today.
- reader_mode 5y ago
  > my main 4k monitor has a refresh rate of 30hz I had to run a 4k screen through an adapter that could only do 30hz@4k and it was a horrible experience - I could notice the lag even when I was typing and scrolling anything was stuttering. I feel like my eyes got tired faster working on that screen. Why would you use that as a main display ?
  - hu3 5y ago
    I have 60hz and 144hz monitors side by side and the difference in eye comfort is noticeable. 30hz is on the realms of possible unnecessary eye damage in the long run.
    - bouncycastle 5y ago
      Eyes damage with age. I also grew up on CRT monitors, they probably did the most damage...
      - hu3 5y ago
        Other factors contribute to eye damage too. Slow refresh rate is one of them. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4170366/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4170366/
        bouncycastle 5y ago
        I think that this article might be referring to the CRT displays (when the CRT gun would pulsate and cause visible flicker especially when the monitor was not interlaced). I do not notice any flickering with the LCD display. In fact, the text appears sharper when compared to another 4k monitor I have with a higher refresh rate... It's not the best though, but compared to what was 10-20 years ago it's amazing. That said, it's certainly not for watching video or playing games.
anthk 5y ago
> software was fast and started up instantly, No, it was dog slow to start because rotary I/O was slower than a snail, but once the sw got loaded, the input and feedback was instantaneous.
smoldesu 5y ago
> We charge a monthly subscription fee for you to use the IDE. Right now that fee is $5/mo. Why should I pay $5/month for this instead of just coughing up the cash for CLIon? Or, better yet, why wouldn't I just save that money for a year or two and buy a GPU for smoother scrolling? I love lightweight software, but this seems like putting the cart before the horse on so many levels...
- DenverCode 5y ago
  JetBrains also has GoLand.
mappu 5y ago
If this is the kind of thing you are interested in, I would strongly recommend LiteIDE: http://liteide.org/en/ http://liteide.org/en/ https://github.com/visualfc/liteide/releases https://github.com/visualfc/liteide/releases It's actively developed, FOSS (LGPL), native C++ (Qt), runs on Windows/macOS/Linux, supports go.mod, and uses gocode/gotools for intellisense instead of gopls. It has integrated debugging, go to definition/usages, and some refactoring support.
- fithisux 5y ago
  Used it a lot for development. Very good.
- deleted 5y ago
  [deleted]
- psanford 5y ago
  Gocode is no longer maintained.
  - mappu 5y ago
    LiteIDE maintain their own fork: https://github.com/visualfc/gocode https://github.com/visualfc/gocode
    - psanford 5y ago
      Weird.
- ricardobeat 5y ago
  LiteIDE struggles with scrolling on a top-of-the-line MacBook, even for short files. I guess it's using QT or some other non-native UI toolkit which is not ideal.
cutler 5y ago
I'm wondering why Windows was chosen as the primary platform given that Go comes from Google and the average Go dev probably isn't using Windows.
arthurcolle 5y ago
why isn't it implemented in Go though
shrumm 5y ago
Maybe I'm reading too much into this - but I found it significant that the beta is starting as Windows only. This was obviously the norm in the 90s and 2000s. Then the Mac started gaining mindshare after OS X with the dev community. Today, I just assume a beta launch will work on a Mac. In the last few years, it seems Microsoft has done a great job with features like WSL on Windows. So is this a sign that Windows is regaining mindshare? Yeah... probably reading too much into this...
- dankwizard 5y ago
  Perhaps the developer of this project does not have much experience outside of Windows?
the__alchemist 5y ago
> A Blazing Fast IDE for Go My pattern matching brain: This usually means missing functionality present in competitors, or a comparison to things not reputed for their speed.
- mappu 5y ago
  I call this pattern "This cereal contains no arsenic".
  - sli 5y ago
    There are these things called Grice's Maxims of Conversation, and this one is called the "Maxim of Quantity." The extra unneeded information is strange because it would normally be assumed. Tom Scott's example[0] is "vegan tomato." Felt like sharing because it's kinda neat to see it described by someone in the wild. [0]: https://www.youtube.com/watch?v=IJEaMtNN_dM https://www.youtube.com/watch?v=IJEaMtNN_dM
luke2m 5y ago
>It basically feels like real Vim. Use real Vim if you want it? It requires a subscription of $0.00 a month!
- deleted 5y ago
  [deleted]
hsn915 5y ago
The pitch is very appealing to me, and I really to join the beta. However, I'm on a mac. I understand that it's not done yet, but an option to subscribe to a mailing list or a news letter so that I'm informed when the mac version comes out would be nice.
yumraj 5y ago
Dear application developer, unless you have market power or a real justification for charging a monthly fee, please do not price as a subscription. You will lose a lot of potential customers, which can kill your product especially if you're a very small entity.
- tonyedgecombe 5y ago
  >You will lose a lot of potential customers, which can kill your product especially if you're a very small entity. Subscriptions are working for Adobe. As much as I dislike subscriptions the writing is on the wall. I wouldn't create a new non-subscription product now.
  - yumraj 5y ago
    A startup with few customers is not Adobe. Adobe has a virtual monopoly in its space with few alternatives, the above is yet another IDE in a space dominated by free products. Anyway, to each their own..
sneak 5y ago
I love the design philosophy and I'm the target market. I'll never add nonfree tools to my edit/build/run toolchain, however. Every single piece must be fully and freely user-modifiable. These are my work tools. They talk about vim support being first-class in their app. Well, vim is free software, so if you're not, you're not really vim-compatible.
noisy_boy 5y ago
When I'm coding, the frame-rate of the IDE is the least of my concerns - I'm busy thinking about what to type. Even if my IDE takes a while to start up, I'm ok with it because I don't really restart it/reboot my machine that often. In terms of ergonomics, both VSCode and Jetbrains IDEs support vi mode and work well enough to not be a show-stopper. Anyway, we definitely can do with more solutions to ensure diversity of choices so good luck to the project.
deleted 5y ago
[deleted]
konart 5y ago
>No more language server madness Madness? gopls in particular works great now. With all respect - I don't really see why would you you need a separate IDE when you can have nvim with native lsp + gopls. Or vscode\goland if you'd rather have an out-of-the-box solution. Goland can be slow and laggy at times but this is the price for all those things baked into it (if you need them).
InvOfSmallC 5y ago
I mean, given the current features, I would not call it an IDE. Also the price is too much compared with GoLand (also only Windows, I don't think anyone I know uses Windows for go)
g_b 5y ago
The demo doesn't even have auto-complete for function/variable names? It's fast at doing what, typing everything by hand? Looking at 27:41 [1] I can hear maybe 12 key strokes to add some closing parentheses. It adds an extra newline that the programmer has to delete by hand. [1] https://youtu.be/9Q0YFHHLG-g?t=1661 https://youtu.be/9Q0YFHHLG-g?t=1661
johnisgood 5y ago
Coding in Go using VSCodium is a really good experience, IMO.
cies 5y ago
I was under the impressions Go is only intended for networked apps. Also it lacks concurrency strategies found in most general purpose languages. But that does not stop people using it for desktop apps. (same with PHP and JS) But is that really a good idea?
- mikojan 5y ago
  > CodePerfect 95 is written in C++
  - cies 5y ago
    That explains (misread "for" as "in" I guess), thanks.
fefe23 5y ago
So, uh, it's competing with vim, which is free, but they want me to pay a monthly subscription fee? It's actually copying vim's keyboard mappings, so you know it'll be strictly worse than vim, which, again, is free. Also I can't take its "zero lag" claim seriously if it says vim is fast. Try opening a 10 MB XML file in vim with syntax highlighting on and see if you can spot the lag. I'm not convinced why I should even spend time investigating this.
ricardobeat 5y ago
The goal of 144fps is laudable, but unfortunately pointless here. Keyboard latency is rarely under 20ms so 60fps is enough for smooth animations on everything. Anything beyond that will simply be wasting cycles, especially using immediate mode rendering.
ddavidson85 5y ago
> We're big Vim users ourselves, and designed CodePerfect 95 with first-class Vim support from the beginning. It basically feels like real Vim. I mean - why not just use Vim then? What am I missing? Also the fact that they are selling "auto format" as a feature for a go IDE is... puzzling.

205 points by brhsagain 5y ago

This is a compelling product pitch to me - I alternate between using vim but not having everything memorized, and using GoLand for its autocomplete and various correction/detection/auto-import-fixing conveniences but wishing it were faster. I'd be willing to pay $5/month for a beta version, if I were using windows. Or alternatively, if someone is watching, I'd be willing to pay $5 for a trial of a mac version :) Respect it's quite a bit of work to support a second OS and window manager and you have to start somewhere - Hope it goes well and makes its way over to Mac soon!

geodel 5y ago

No electron based editor sounds so good to me. However at this point I feel there is no satisfying the mob of "Why would I use this instead of VSCode?"

itake 5y ago
VSCode (or more specifically, the VSCode Go extension) can't handle a mono-repo of golang microservices. My CPU/fans go crazy opening the darn thing. With the extension disabled, VSCode is fine, but it lacks all of the "necessary" features offered in the extension.
- disposedtrolley 5y ago
  I wonder if these performance issues apply to all language extensions that rely on a language server (implemented in VSCode or otherwise). From what I understand, since JSON [0] is used over the wire between the editor and the language server process, there's a lot of serialisation/deserialisation overhead. Microsoft used to maintain a log inspector [1] which you could use to see the chatter between the server and client, and there was a _lot_ of chatter with a _lot_ of JSON. [0] https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie... [1] https://github.com/microsoft/language-server-protocol-inspector https://github.com/microsoft/language-server-protocol-inspec...
  - qbasic_forever 5y ago
    LSP stuff is done asynchronously in VS code (and other editors). This doesn't slow down the main editing UI at all. It just means when you start typing and expect to see linter warnings, autocomplete suggestions, etc. it can take a bit longer if the LSP server is slow to respond. If someone has all their CPU fans, etc. spinning up when opening a big monorepo it's probably just aggressive indexing inside the LSP server they're using. Almost certainly it's an optimization trade-off made by the LSP server author, trying to balance the common case of people typically opening smaller repos and assuming they immediately want search, etc. to be fast and ready. There's nothing inherent to the LSP protocol or design that causes this problem--someone could build a better LSP server designed to handle large monorepos by deferring indexing, etc. until absolutely needed (but potentially with some tradeoffs like searching inside a subunit being delayed until its used). It's the same basic problem git faced with enormous repos over time slowing down and all the hacks/workarounds people have bolted on to try to limit how much of the monorepo state needs to be available at any moment.
    - disposedtrolley 5y ago
      > There's nothing inherent to the LSP protocol or design that causes this problem Even though most of the indexing and intellisense features are done within the language server itself, there'd still be significant overhead in JSON parsing and serialisation right? The response example for the `textDocument/definition` request [0] shows a very large snippet of JSON considering the information it conveys: { "jsonrpc": "2.0", "id": 1, "result": { "uri": "file:///p%3A/mseng/VSCode/Playgrounds/cpp/provide.cpp", "range": { "start": { "line": 0, "character": 4 }, "end": { "line": 0, "character": 11 } } } } [0] https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie...
      - hnlmorg 5y ago
        One of the benefits of the JSON standard being pretty simple is that it makes JSON is pretty efficient to parse. We're not talking ProtoBuf efficient here, but I've easily parsed files containing gigabytes of JSON.
rodgerd 5y ago
> the mob Ah yes, such a winning way of referring to people who like a different text editor to you. Way to up the quality of discourse.
- geodel 5y ago
  I am sure once you hear of "Gang of Four" design patterns [1] your immediate response would be to rage about why is one bringing an organized group of criminals to the subject of software design pattern discussion. 1. https://springframework.guru/gang-of-four-design-patterns/ https://springframework.guru/gang-of-four-design-patterns/
  - loopz 5y ago
    We could point out why would you need design patterns when the language directly supports them natively, but can't since this is a Go thread ;)
    - philosopher1234 5y ago
      It’s better this way.

int_19h 5y ago

I would have expected a product with "95" in the name to use native look & feel, as was the norm back in the day.

fermentation 5y ago

The page says the editor is "designed to run at 144hz". That's actually a pretty cool feature, as vscode seems locked to 60hz. I have to wonder, what is stopping it from going further? I have a 240hz monitor, are there any IDEs or text editors that can render that fast?

qxga 5y ago
Nothing is stopping it from going faster, unless the framerate is forcibly capped by the developer. It renders the same way a framerate-independent 3D game does.

Kubuxu 5y ago

I was hoping they were going to take my money (when I saw the "Join Beta"), unfortunately it is Windows only. Personally I know only one person working in Go on Windows, I know 40+ either on Linux or MacOS. I hope for Linux version soon.

PuerkitoBio 5y ago
I had my credit card out at "Vim Keybindings", only to be slightly disappointed by the Windows-only limitation (for now). Looking forward to try this out on Linux soon. Although I'm pretty happy with Vim, I'm curious to see if I'm missing out on a significantly better experience. That being said, not a fan of a monthly subscription for a native desktop application.
- Kubuxu 5y ago
  For desktop applications I just translate the monthly subscriptions into yearly. Most software right now is sold as either yearly subscription or "year of upgrades" so it is one and the same.
  - PuerkitoBio 5y ago
    If I can't use the software without an active subscription, it is definitely not one and the same. I like Sublime Text's license of 3 years of upgrade with a purchase, no limitation on usage of the software. Unclear (AFAICT from the FAQ) how it would work for CodePerfect 95.
  - FpUser 5y ago
    I have some applications that are years old without upgrading to current version. Reason - the old version works fine and does everything I need. However if that's the case I sometimes decide to upgrade at some point to feed the developer.
intricatedetail 5y ago
Both Windows and macOS do dodgy telemetry and who knows what data they harvest. I don't know anyone doing programming seriously who doesn't use Linux.

yjftsjthsd-h 5y ago

There's something funny about proudly proclaiming no GC and written in C++ for a golang IDE. It's not wrong; different tradeoffs for different uses. Just funny.

bob1029 5y ago
Modern GC doesn't even preclude the possibility of developing a no-lag UI. You just have to be very careful with how you manage your data so that you don't get hit with more heavy-handed collection mechanisms (i.e. large gen2 cleanups in .NET). Small and short-lived class instances (more ideally structs) are the key to success with low-latency applications in most GC'd languages. If you are only touching gen0/1 in a .NET5 app, you will probably find the GC impact to UI latency to be negligible. In .NET, avoiding gen2 allocations is pretty easy. The biggest thing is replacing every byte[] with Stream as feasible, so you don't send objects directly to LOH (gen2). I believe the LOH threshold for byte[] is lower than the published limit of 85k, but I cannot recall the specifics (might be closer to 10k). Regardless, you really shouldn't be holding onto chunks of memory that large if you can ever avoid it. In some cases you can cheat. Pass around the path/id to a file and then stream it from disk at the very last possible moment (i.e. copy a FileStream direct to the HttpContext.Response.Body stream). If you absolutely must allocate large objects, try to reuse them as much as possible. Act as if anything entering gen2 is in memory forever, because with enough LOH fragmentation, it might as well be. UI is one thing, but real-time process control is a wholly different animal. If you want to write a PID in a GC language, you better be prepared to eschew any notion of allocation in the process under collection. Even if you don't allocate, there are runtime components that still will, so you will almost always have some minimum amount of noise to contend with. That said, if you only need to run a PID loop at ~10khz (100uS loop delay), you probably wont have any issues. Just make sure you put the PID loop on a high-priority thread and care for its surroundings gingerly. A Raspi4+ is actually an amazing platform for this sort of thing.
- throwaway894345 5y ago
  I suspect Go's GC would be particularly well-fit for this kind of application considering it typically runs in <1ms with no exceptionally large pauses (except perhaps in pathological cases). Like C#, Go has value types, so controlling allocations should be pretty straightforward.

jmrm 5y ago

I would like an IDE like this but for Rust. Some day I will get angry enough and I'll have to make it myself.

mathgladiator 5y ago
Check out https://makepad.dev/ https://makepad.dev/ and then hold down left alt key.
- zeroxfe 5y ago
  > and then hold down left alt key. okay, that was just plain cool!
- jmrm 5y ago
  That is totally awesome! Thank you :)
sodality2 5y ago
I desperately want this. I find text editors w/ basic linting to be too limited but full IDE's like Idea or even VSCode too heavy for some devices. Something in between :(. I've given up laptop development and am forced to work with my desktop until I can afford a better laptop because Idea/VSCode runs so slowly. FWIW, I use lite (https://github.com/rxi/lite https://github.com/rxi/lite) if I need a very lightweight text editor that has rust linting (https://github.com/liquidev/lintplus https://github.com/liquidev/lintplus) and Idea if I'm at my desktop.
- sli 5y ago
  I bought Sublime Text last year after using it off and on since 2009 or so and I don't think I'll switch again for a long time. I figured I'd gotten $80 of use out of it over the years, anyway. The difference in performance between ST and Atom/VSCode is unreal (but expected). It doesn't have nearly as big a community behind it, so adjusting your tooling can take time, but I'm doing mostly Rust these days and it does a fine job for me. That all might be a dealbreaker for some, though. I do know Elm support was way better in Atom, but I'm not writing that very much these days.

momonga 5y ago

I wonder how much CPU this uses. An immediate mode GUI (ImGUI, which CodePerfect 95 uses) constructs the entire GUI on every frame by default.

mananaysiempre 5y ago
It does run through every node in the would-be scene graph by default, but IIRC the Dear ImGUI library caches the actual expensive toolkit, graphics, and/or window system calls for each subtree. The API is immediate-mode, but its implementation does not have to be stateless. (Cf. React.)

hulug 5y ago

Not to be a prick but I doubt Go users will like this, they tend to prefer simple things to more complex things. Maybe retargeting this for Java/C++ users would be better. Jokes (not really) aside, why does an IDE need to be designed for a language anyway?

qxga 5y ago
It's a self-contained application using the Dear ImGUI library rather than a bloated framework, and is designed for a single language. It's not simple compared to the likes of vi, sure, but it's almost certainly many less lines of code and much more architecturally simple than just about any other (popular, in-use) IDE out there.
mananaysiempre 5y ago
Because so far noöne has figured out the set of extensibility points needed for a language-agnostic one that doesn’t result in horrible bloat and sprawling API surfaces. The original language-agnostic IDE—Emacs—is probably the simplest, and it’s still quite complex. Acme[2] is interesting, but Spartan when it comes to actual IDE-ish features, and its UI always rubbed me the wrong way. I feel this is somewhat related to the fact that noöne has figured out how to do extensible widget toolkits or scene graphs either. (Yes, Electron does in fact solve an actual problem, if in a profoundly unsatisfying way.) Actually, just a text input box that could handle the complexities of the world’s writing systems (RTL, complex font shaping, arbitrary input methods, autocorrect, all that with at least one cursor or selection) and was capable of supporting the facts vs rumors approach from FRP[1] would be a significant advancement re toolkits. As for scene graphs, I don’t actually know of any viable general approaches to assembling an interface out of independent parts (that doesn’t work by presupposing a large substrate of features in the host “shell” and providing a separate extension point for each of shortcut, menu item, toolbar button, sidebar, dialog, ...). Actually, now that I’ve written all of that out, it seems that another way to put my second point is that the language-agnostic IDE problem is a proper superset of the composable GUIs problem, and nobody knows how to solve that one. Composable CLIs are easy—they’re called “[textual] programming”; but then composable GUIs (or TUIs, the graphics/text distinction is immaterial here) would seem to correspond to visual programming, and last I checked the latter still sucked. [1]: https://apfelmus.nfshost.com/blog/2012/03/29-frp-three-principles-bidirectional-gui.html https://apfelmus.nfshost.com/blog/2012/03/29-frp-three-princ... [2]: http://acme.cat-v.org/ http://acme.cat-v.org/

Yoofie 5y ago

As soon as I saw the screenshot, I instantly knew it was using Dear Imgui library [1] under the hood because of the familiar Imgui design cues. Dear Imgui is originally meant to be used in combination with game & graphics engines which support hardware acceleration. Thus, you get high framerates. [1]: https://github.com/ocornut/imgui https://github.com/ocornut/imgui

deleted 5y ago
[deleted]
syspec 5y ago
It's also in the gif on the primary page: https://codeperfect95.com/static/media/60fps.01d0b31c.gif https://codeperfect95.com/static/media/60fps.01d0b31c.gif

munificent 5y ago

> I know how an IDE works. All an IDE really needs to do is (a) let you edit a text buffer, (b) parse your source files, and (c) build an understanding of your code and provide you with intellisense. What's hard about that? Why is my IDE slow? ... > The IDE is very much unfinished. ... it freezes when opening super huge directories. So here's what's likely to happen: 1. To fix that freeze, you realize that you need to do file loading asynchronously in the background. 2. That in turn means you need to have your parsing/analysis run asynchronously so that it can analyze files as they come in. 3. But the UI that is reading analysis results is still running on the main thread. So now you need to add locking and other concurrency stuff everywhere. This takes a year of your life. At the end, your IDE is now twice as slow. 4. Also, the user still wants to be able to edit code while all this asynchrony is going on. (Otherwise, you'd just freeze like you were before.) So now your analysis engine needs to handle both concurrent reads and writes while also doing file IO. 5. At this point (especially with all that locking and other concurrency stuff), it's so complex that "re-analyze the entire program from scratch every time" is too slow. You need to be able to maintain a persistent analysis state and incrementally update as the user changes code or files get reloaded. You build a complex dependency graph system so that you can determine which analysis state must be invalidated when a line of code in one file is changed. This is another year of your life. 6. Now your analysis engine is so complex that the limiting factor for making your IDE better is developer productivity. It is incredibly hard to touch this giant ball of mutable concurrent incrementally updated state without breaking something and/or losing your sanity. 7. You eventually realize you need to architect it at a higher level. Instead of low-level threading and locking and carefully hand-authored incremental updating code (which few humans can maintain), you replace it all with a bunch of more coarse-grained persistent data structures. This takes a couple more years of your life. At the end, you get an analysis engine that you can maintain, which is good, because in the meantime, three new major versions of Go have come out and users asking you to support 17 other programming languages. But your new coarse-grained analysis engine is five times slower than the old ball of spaghetti... 8. A user files a bug saying that the IDE crashes when they try to open their 20-million line Go program. It turns out your implementation assumed you could always fit the full AST for every source file in memory. OK, time to start working on a compressed code representation.... 9. Meanwhile, another user files an innocuous little bug asking why the editor doesn't support full-width characters, right-to-left languages, or emoji. You open up your beautiful, 200-line hand-written fixed-width text renderer in one tab. Then you open the Unicode spec in the other and start reading about "extended grapheme clusters", "combining characters", etc. In a third, you start reading about OpenType "multi-colored glyphs"... I agree that IDEs could be faster than they are. There is a lot of cruft. But it's very hard to fix that by starting with OpenGL Notepad and hacking your way to IntelliJ one Git commit at a time without ever monotonically regressing perf. That's like trying to solve climate change by taking a tricycle and incrementally welding your way to a carbon-neutral container ship. Writing a real-time code analysis engine for large-scale programs is hard. It's a big complex piece of code. Comparing it to a text editor is like comparing Tetris to World of Warcraft because they're both "games". That being said, I completely applaud the author for making a go at it. It's hard, but not impossible, and history is written by people who had the courage to do hard things.

ojosilva 5y ago

> What does CodePerfect 95 mean? It's a retro name. It hearkens back to a time when software was fast and started up instantly, despite running on hardware orders of magnitude slower than we have now. WordPerfect was a huge monster, probably one of the largest (15+ diskettes) and sluggishiest DOS apps I had back in the day. Windows 95 was cool, but also a significant step back on snappiness compared to 3.11 or even OS/2 Warp. There are probably much better retro-snappy names, like, don't know, CodeKick 1-2-3?

jagger27 5y ago
Office 95 was pretty snappy, from what I remember.
starik36 5y ago
> WordPerfect was a huge monster, ... sluggishiest DOS apps Hmmm, I don't remember it being sluggish. I worked at the university computer lab at the time and remember WP being of of the snappiest programs. It was mostly written in assembly till the later versions.

maxdo 5y ago

Author is trying to solve a problem that is not exist , ui Is not a problem for any programming language for the last 10 years unless you’re doing scala or something heavy that kills your machine

nexuist 5y ago

Why would I use this instead of VSCode?

donatj 5y ago

$5 a month, $60 a year. It's not horrible pricing, but it's competing with GoLand at that price point, and GoLand is fully featured in a way I don't see this ever being. You're also competing with the LiteIDE. It's free, light as hell, and as far as I can tell does everything this does probably as lightly as this does. Beyond that, I'm sure for the thousandth time you've heard it "why does everything need to be a service these days?" Har har, but seriously why not give this a reasonable 1995 pricing model if you're playing up the 95 angle for Christ's sake.

ianlevesque 5y ago
It's really a reasonable cost. They're probably a solo developer or at best a small team and any subscription model will make that vastly more sustainable.
- donatj 5y ago
  To my point, it is reasonable, but they've already been out priced by more capable products. It's not a good place to start.
  - LanceH 5y ago
    Except speed apparently. Goland and VS Code both have slow response times to clicks.
- Barrin92 5y ago
  the problem is that price isn't justified by the size or character of the team but by value added for the consumer, compared to other products in the same space. 60 bucks per year for a language specific IDE which has multiple competitors with more features just doesn't seem like that good of a deal. Others have pointed out LiteIDE, which is open source and doesn't cost anything.
intricatedetail 5y ago
Goland is slow. It's such a drag when you accidentally open it. So many times I abandoned trying something because of the thought of opening goland. Thankfully I got sublime. I'll give this one a try too.

bouncycastle 5y ago

Cool name! However, I never had a situation with Goland where speed was an issue. In most cases, I'm waiting for the code to compile. Page rendering speed is an issue in things like web browsers. Besides, my main 4k monitor has a refresh rate of 30hz, so scrolling will always be janky... For me, the killer feature of any IDE has always been integrated debugging and able to inspect the data. Integrated testing has also been another feature I cannot live without today.

reader_mode 5y ago
> my main 4k monitor has a refresh rate of 30hz I had to run a 4k screen through an adapter that could only do 30hz@4k and it was a horrible experience - I could notice the lag even when I was typing and scrolling anything was stuttering. I feel like my eyes got tired faster working on that screen. Why would you use that as a main display ?
- hu3 5y ago
  I have 60hz and 144hz monitors side by side and the difference in eye comfort is noticeable. 30hz is on the realms of possible unnecessary eye damage in the long run.
  - bouncycastle 5y ago
    Eyes damage with age. I also grew up on CRT monitors, they probably did the most damage...
    - hu3 5y ago
      Other factors contribute to eye damage too. Slow refresh rate is one of them. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4170366/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4170366/
      - bouncycastle 5y ago
        I think that this article might be referring to the CRT displays (when the CRT gun would pulsate and cause visible flicker especially when the monitor was not interlaced). I do not notice any flickering with the LCD display. In fact, the text appears sharper when compared to another 4k monitor I have with a higher refresh rate... It's not the best though, but compared to what was 10-20 years ago it's amazing. That said, it's certainly not for watching video or playing games.

anthk 5y ago

> software was fast and started up instantly, No, it was dog slow to start because rotary I/O was slower than a snail, but once the sw got loaded, the input and feedback was instantaneous.

smoldesu 5y ago

> We charge a monthly subscription fee for you to use the IDE. Right now that fee is $5/mo. Why should I pay $5/month for this instead of just coughing up the cash for CLIon? Or, better yet, why wouldn't I just save that money for a year or two and buy a GPU for smoother scrolling? I love lightweight software, but this seems like putting the cart before the horse on so many levels...

DenverCode 5y ago
JetBrains also has GoLand.

mappu 5y ago

If this is the kind of thing you are interested in, I would strongly recommend LiteIDE: http://liteide.org/en/ http://liteide.org/en/ https://github.com/visualfc/liteide/releases https://github.com/visualfc/liteide/releases It's actively developed, FOSS (LGPL), native C++ (Qt), runs on Windows/macOS/Linux, supports go.mod, and uses gocode/gotools for intellisense instead of gopls. It has integrated debugging, go to definition/usages, and some refactoring support.

fithisux 5y ago
Used it a lot for development. Very good.
deleted 5y ago
[deleted]
psanford 5y ago
Gocode is no longer maintained.
- mappu 5y ago
  LiteIDE maintain their own fork: https://github.com/visualfc/gocode https://github.com/visualfc/gocode
  - psanford 5y ago
    Weird.
ricardobeat 5y ago
LiteIDE struggles with scrolling on a top-of-the-line MacBook, even for short files. I guess it's using QT or some other non-native UI toolkit which is not ideal.

cutler 5y ago

I'm wondering why Windows was chosen as the primary platform given that Go comes from Google and the average Go dev probably isn't using Windows.

arthurcolle 5y ago

why isn't it implemented in Go though

shrumm 5y ago

Maybe I'm reading too much into this - but I found it significant that the beta is starting as Windows only. This was obviously the norm in the 90s and 2000s. Then the Mac started gaining mindshare after OS X with the dev community. Today, I just assume a beta launch will work on a Mac. In the last few years, it seems Microsoft has done a great job with features like WSL on Windows. So is this a sign that Windows is regaining mindshare? Yeah... probably reading too much into this...

dankwizard 5y ago
Perhaps the developer of this project does not have much experience outside of Windows?

the__alchemist 5y ago

> A Blazing Fast IDE for Go My pattern matching brain: This usually means missing functionality present in competitors, or a comparison to things not reputed for their speed.

mappu 5y ago
I call this pattern "This cereal contains no arsenic".
- sli 5y ago
  There are these things called Grice's Maxims of Conversation, and this one is called the "Maxim of Quantity." The extra unneeded information is strange because it would normally be assumed. Tom Scott's example[0] is "vegan tomato." Felt like sharing because it's kinda neat to see it described by someone in the wild. [0]: https://www.youtube.com/watch?v=IJEaMtNN_dM https://www.youtube.com/watch?v=IJEaMtNN_dM

luke2m 5y ago

>It basically feels like real Vim. Use real Vim if you want it? It requires a subscription of $0.00 a month!

deleted 5y ago
[deleted]

hsn915 5y ago

The pitch is very appealing to me, and I really to join the beta. However, I'm on a mac. I understand that it's not done yet, but an option to subscribe to a mailing list or a news letter so that I'm informed when the mac version comes out would be nice.

yumraj 5y ago

Dear application developer, unless you have market power or a real justification for charging a monthly fee, please do not price as a subscription. You will lose a lot of potential customers, which can kill your product especially if you're a very small entity.

tonyedgecombe 5y ago
>You will lose a lot of potential customers, which can kill your product especially if you're a very small entity. Subscriptions are working for Adobe. As much as I dislike subscriptions the writing is on the wall. I wouldn't create a new non-subscription product now.
- yumraj 5y ago
  A startup with few customers is not Adobe. Adobe has a virtual monopoly in its space with few alternatives, the above is yet another IDE in a space dominated by free products. Anyway, to each their own..

sneak 5y ago

I love the design philosophy and I'm the target market. I'll never add nonfree tools to my edit/build/run toolchain, however. Every single piece must be fully and freely user-modifiable. These are my work tools. They talk about vim support being first-class in their app. Well, vim is free software, so if you're not, you're not really vim-compatible.

noisy_boy 5y ago

When I'm coding, the frame-rate of the IDE is the least of my concerns - I'm busy thinking about what to type. Even if my IDE takes a while to start up, I'm ok with it because I don't really restart it/reboot my machine that often. In terms of ergonomics, both VSCode and Jetbrains IDEs support vi mode and work well enough to not be a show-stopper. Anyway, we definitely can do with more solutions to ensure diversity of choices so good luck to the project.

deleted 5y ago

[deleted]

konart 5y ago

>No more language server madness Madness? gopls in particular works great now. With all respect - I don't really see why would you you need a separate IDE when you can have nvim with native lsp + gopls. Or vscode\goland if you'd rather have an out-of-the-box solution. Goland can be slow and laggy at times but this is the price for all those things baked into it (if you need them).

InvOfSmallC 5y ago

I mean, given the current features, I would not call it an IDE. Also the price is too much compared with GoLand (also only Windows, I don't think anyone I know uses Windows for go)

g_b 5y ago

The demo doesn't even have auto-complete for function/variable names? It's fast at doing what, typing everything by hand? Looking at 27:41 [1] I can hear maybe 12 key strokes to add some closing parentheses. It adds an extra newline that the programmer has to delete by hand. [1] https://youtu.be/9Q0YFHHLG-g?t=1661 https://youtu.be/9Q0YFHHLG-g?t=1661

johnisgood 5y ago

Coding in Go using VSCodium is a really good experience, IMO.

cies 5y ago

I was under the impressions Go is only intended for networked apps. Also it lacks concurrency strategies found in most general purpose languages. But that does not stop people using it for desktop apps. (same with PHP and JS) But is that really a good idea?

mikojan 5y ago
> CodePerfect 95 is written in C++
- cies 5y ago
  That explains (misread "for" as "in" I guess), thanks.

fefe23 5y ago

So, uh, it's competing with vim, which is free, but they want me to pay a monthly subscription fee? It's actually copying vim's keyboard mappings, so you know it'll be strictly worse than vim, which, again, is free. Also I can't take its "zero lag" claim seriously if it says vim is fast. Try opening a 10 MB XML file in vim with syntax highlighting on and see if you can spot the lag. I'm not convinced why I should even spend time investigating this.

ricardobeat 5y ago

The goal of 144fps is laudable, but unfortunately pointless here. Keyboard latency is rarely under 20ms so 60fps is enough for smooth animations on everything. Anything beyond that will simply be wasting cycles, especially using immediate mode rendering.

ddavidson85 5y ago

> We're big Vim users ourselves, and designed CodePerfect 95 with first-class Vim support from the beginning. It basically feels like real Vim. I mean - why not just use Vim then? What am I missing? Also the fact that they are selling "auto format" as a feature for a go IDE is... puzzling.